From patchwork Fri Aug 14 03:00:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 266554 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E79C7C433DF for ; Fri, 14 Aug 2020 03:00:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C5B9D20716 for ; Fri, 14 Aug 2020 03:00:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597374016; bh=egEDfFWEsu8u2ioZb3d3d9OXAZsoL+GxKHwv/9cwC+Q=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=IAqGuWezmS7OyCzNC/57DF/8tFa63EkiCwogy9Bzl9mtrgn4AwVzxCeZJ6bMb604t ZOgV60rQKsJaLMa51Ko/O6X1pkbA/mT2csR11AgLu9P+D5W08GEZxtsAv3E5zKn9oT 7Hw5doNx3hB8+J4xTrsurEQcQCANAXcNPiS9wiJU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726564AbgHNDAQ (ORCPT ); Thu, 13 Aug 2020 23:00:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:38648 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726567AbgHNDAP (ORCPT ); Thu, 13 Aug 2020 23:00:15 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C07AC2078B; Fri, 14 Aug 2020 03:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597374015; bh=egEDfFWEsu8u2ioZb3d3d9OXAZsoL+GxKHwv/9cwC+Q=; h=Date:From:To:Subject:In-Reply-To:From; b=lP/NWdO/1n7E+7QOlzd7kpMCZTQaQ8a7Dw/+BjRSmFI0AChD7jPmmEVKrKv5jTPvM keU5T3zkrXbExU9+GjvIKvCAMUMQiXWJJ7+A+YMurhgsMXh/hPm+bbILv+QasgOKDi U28WDNBJKWqy4BIs7nV8UQ4HqjL3r7tGST8K4VCY= Date: Thu, 13 Aug 2020 20:00:14 -0700 From: Andrew Morton To: charante@codeaurora.org, david@redhat.com, mhocko@suse.com, mm-commits@vger.kernel.org, rientjes@google.com, stable@vger.kernel.org, vbabka@suse.cz, vinmenon@codeaurora.org Subject: + mm-page_alloc-fix-core-hung-in-free_pcppages_bulk.patch added to -mm tree Message-ID: <20200814030014.ODl4NLbRv%akpm@linux-foundation.org> In-Reply-To: <20200811182949.e12ae9a472e3b5e27e16ad6c@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: mm, page_alloc: fix core hung in free_pcppages_bulk() has been added to the -mm tree. Its filename is mm-page_alloc-fix-core-hung-in-free_pcppages_bulk.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-fix-core-hung-in-free_pcppages_bulk.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-page_alloc-fix-core-hung-in-free_pcppages_bulk.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Charan Teja Reddy Subject: mm, page_alloc: fix core hung in free_pcppages_bulk() The following race is observed with the repeated online, offline and a delay between two successive online of memory blocks of movable zone. P1 P2 Online the first memory block in the movable zone. The pcp struct values are initialized to default values,i.e., pcp->high = 0 & pcp->batch = 1. Allocate the pages from the movable zone. Try to Online the second memory block in the movable zone thus it entered the online_pages() but yet to call zone_pcp_update(). This process is entered into the exit path thus it tries to release the order-0 pages to pcp lists through free_unref_page_commit(). As pcp->high = 0, pcp->count = 1 proceed to call the function free_pcppages_bulk(). Update the pcp values thus the new pcp values are like, say, pcp->high = 378, pcp->batch = 63. Read the pcp's batch value using READ_ONCE() and pass the same to free_pcppages_bulk(), pcp values passed here are, batch = 63, count = 1. Since num of pages in the pcp lists are less than ->batch, then it will stuck in while(list_empty(list)) loop with interrupts disabled thus a core hung. Avoid this by ensuring free_pcppages_bulk() is called with proper count of pcp list pages. The mentioned race is some what easily reproducible without [1] because pcp's are not updated for the first memory block online and thus there is a enough race window for P2 between alloc+free and pcp struct values update through onlining of second memory block. With [1], the race still exists but it is very narrow as we update the pcp struct values for the first memory block online itself. This is not limited to the movable zone, it could also happen in cases with the normal zone (e.g., hotplug to a node that only has DMA memory, or no other memory yet). [1]: https://patchwork.kernel.org/patch/11696389/ Link: http://lkml.kernel.org/r/1597150703-19003-1-git-send-email-charante@codeaurora.org Fixes: 5f8dcc21211a ("page-allocator: split per-cpu list into one-list-per-migrate-type") Signed-off-by: Charan Teja Reddy Acked-by: David Hildenbrand Acked-by: David Rientjes Cc: Michal Hocko Cc: Vlastimil Babka Cc: Vinayak Menon Cc: [2.6+] Signed-off-by: Andrew Morton --- mm/page_alloc.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/mm/page_alloc.c~mm-page_alloc-fix-core-hung-in-free_pcppages_bulk +++ a/mm/page_alloc.c @@ -1301,6 +1301,11 @@ static void free_pcppages_bulk(struct zo struct page *page, *tmp; LIST_HEAD(head); + /* + * Ensure proper count is passed which otherwise would stuck in the + * below while (list_empty(list)) loop. + */ + count = min(pcp->count, count); while (count) { struct list_head *list; From patchwork Wed Aug 12 01:32:03 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 266585 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27C57C433E1 for ; Wed, 12 Aug 2020 01:32:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0898D2080C for ; Wed, 12 Aug 2020 01:32:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597195927; bh=gFsJfQTsHVBklo2noIvAaivjZuyl2sPhMLKPktO/beU=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=mYDkt+w1XpkanRaOfp9iN37r3Jkh8V/Lo6vnzfcJdn1t81awr/Cb6g70GrklWtmIX CEAs5fSesfu4ke2dhfMVGso9otLVBfyARqn04ciFkrycB2QF7dqcX/AmITm6GZATqX SUv68fLBiboQeYd2h3QAxgbCh79RGs5oHvxizYGY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726235AbgHLBcF (ORCPT ); Tue, 11 Aug 2020 21:32:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:60144 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726531AbgHLBcF (ORCPT ); Tue, 11 Aug 2020 21:32:05 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EBD55206B2; Wed, 12 Aug 2020 01:32:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597195924; bh=gFsJfQTsHVBklo2noIvAaivjZuyl2sPhMLKPktO/beU=; h=Date:From:To:Subject:In-Reply-To:From; b=LG0fqlfHHccdBcury3qaI4W3jNZ5qXea8dJ5ZB1KdrdePvP9eMnRAvdLeDva6vi6s 4Gv9JINo4vwQqAHFfpG40X3oASTn93VZ5B3wXqQ9MA3UiV3SCO64CLAdOmwywsp79A Xu2fIZH75/strLlTyTt1SFjnCRXVKusWdBHqzCH8= Date: Tue, 11 Aug 2020 18:32:03 -0700 From: Andrew Morton To: akpm@linux-foundation.org, guro@fb.com, iamjoonsoo.kim@lge.com, kyungmin.park@samsung.com, linux-mm@kvack.org, m.szyprowski@samsung.com, mike.kravetz@oracle.com, mina86@mina86.com, mm-commits@vger.kernel.org, song.bao.hua@hisilicon.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 034/165] cma: don't quit at first error when activating reserved areas Message-ID: <20200812013203.Dh6_amkhG%akpm@linux-foundation.org> In-Reply-To: <20200811182949.e12ae9a472e3b5e27e16ad6c@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Kravetz Subject: cma: don't quit at first error when activating reserved areas The routine cma_init_reserved_areas is designed to activate all reserved cma areas. It quits when it first encounters an error. This can leave some areas in a state where they are reserved but not activated. There is no feedback to code which performed the reservation. Attempting to allocate memory from areas in such a state will result in a BUG. Modify cma_init_reserved_areas to always attempt to activate all areas. The called routine, cma_activate_area is responsible for leaving the area in a valid state. No one is making active use of returned error codes, so change the routine to void. How to reproduce: This example uses kernelcore, hugetlb and cma as an easy way to reproduce. However, this is a more general cma issue. Two node x86 VM 16GB total, 8GB per node Kernel command line parameters, kernelcore=4G hugetlb_cma=8G Related boot time messages, hugetlb_cma: reserve 8192 MiB, up to 4096 MiB per node cma: Reserved 4096 MiB at 0x0000000100000000 hugetlb_cma: reserved 4096 MiB on node 0 cma: Reserved 4096 MiB at 0x0000000300000000 hugetlb_cma: reserved 4096 MiB on node 1 cma: CMA area hugetlb could not be activated # echo 8 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI ... Call Trace: bitmap_find_next_zero_area_off+0x51/0x90 cma_alloc+0x1a5/0x310 alloc_fresh_huge_page+0x78/0x1a0 alloc_pool_huge_page+0x6f/0xf0 set_max_huge_pages+0x10c/0x250 nr_hugepages_store_common+0x92/0x120 ? __kmalloc+0x171/0x270 kernfs_fop_write+0xc1/0x1a0 vfs_write+0xc7/0x1f0 ksys_write+0x5f/0xe0 do_syscall_64+0x4d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Link: http://lkml.kernel.org/r/20200730163123.6451-1-mike.kravetz@oracle.com Fixes: c64be2bb1c6e ("drivers: add Contiguous Memory Allocator") Signed-off-by: Mike Kravetz Reviewed-by: Roman Gushchin Acked-by: Barry Song Cc: Marek Szyprowski Cc: Michal Nazarewicz Cc: Kyungmin Park Cc: Joonsoo Kim Cc: Signed-off-by: Andrew Morton --- mm/cma.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) --- a/mm/cma.c~cma-dont-quit-at-first-error-when-activating-reserved-areas +++ a/mm/cma.c @@ -93,17 +93,15 @@ static void cma_clear_bitmap(struct cma mutex_unlock(&cma->lock); } -static int __init cma_activate_area(struct cma *cma) +static void __init cma_activate_area(struct cma *cma) { unsigned long base_pfn = cma->base_pfn, pfn = base_pfn; unsigned i = cma->count >> pageblock_order; struct zone *zone; cma->bitmap = bitmap_zalloc(cma_bitmap_maxno(cma), GFP_KERNEL); - if (!cma->bitmap) { - cma->count = 0; - return -ENOMEM; - } + if (!cma->bitmap) + goto out_error; WARN_ON_ONCE(!pfn_valid(pfn)); zone = page_zone(pfn_to_page(pfn)); @@ -133,25 +131,22 @@ static int __init cma_activate_area(stru spin_lock_init(&cma->mem_head_lock); #endif - return 0; + return; not_in_zone: - pr_err("CMA area %s could not be activated\n", cma->name); bitmap_free(cma->bitmap); +out_error: cma->count = 0; - return -EINVAL; + pr_err("CMA area %s could not be activated\n", cma->name); + return; } static int __init cma_init_reserved_areas(void) { int i; - for (i = 0; i < cma_area_count; i++) { - int ret = cma_activate_area(&cma_areas[i]); - - if (ret) - return ret; - } + for (i = 0; i < cma_area_count; i++) + cma_activate_area(&cma_areas[i]); return 0; } From patchwork Wed Aug 12 01:35:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 266584 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8D21C433DF for ; Wed, 12 Aug 2020 01:35:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A816720855 for ; Wed, 12 Aug 2020 01:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597196129; bh=XRaUsfOfArlLCj6aQQTjDLCujMRU5oNoOzT3ATLhLIA=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=AgWU6mSiTgTwnE1wRrYOexvLto+5aJBINpl2qSBa7FiB9Fun0kdjGZf6esa9QSb1A OcnIGO9mLwH9jZB7bbccoVn97c7IzcYDQeCqJCB3lhYQOWeTtTSht4XUUord+NSpGQ 0ADycNgcKK+6kPx+XeszwEwHe2dY6nh2KsiDCI3s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726485AbgHLBf3 (ORCPT ); Tue, 11 Aug 2020 21:35:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:36438 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726430AbgHLBf3 (ORCPT ); Tue, 11 Aug 2020 21:35:29 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 437DC20658; Wed, 12 Aug 2020 01:35:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597196128; bh=XRaUsfOfArlLCj6aQQTjDLCujMRU5oNoOzT3ATLhLIA=; h=Date:From:To:Subject:In-Reply-To:From; b=RnZjaG5VRX1vT7BFV68Dk5/ldXtxSTX6Gf2cXZ7Ri/2dubG8EQq8L/RntlIrUAHjU LrogpH3/xpx9zb3Kcc4DBEKJfnf8zcNoqzxBi2zwllRC3ZziI1Bsv1eYUFNfcQ7zkE cknEXJ9zwBIxhDG8V4VM0x14WZ20aV9mm3VEn1/4= Date: Tue, 11 Aug 2020 18:35:27 -0700 From: Andrew Morton To: akpm@linux-foundation.org, anenbupt@gmail.com, ebiggers@google.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk Subject: [patch 099/165] fs/minix: don't allow getting deleted inodes Message-ID: <20200812013527.F8o9sw3XQ%akpm@linux-foundation.org> In-Reply-To: <20200811182949.e12ae9a472e3b5e27e16ad6c@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Eric Biggers Subject: fs/minix: don't allow getting deleted inodes If an inode has no links, we need to mark it bad rather than allowing it to be accessed. This avoids WARNINGs in inc_nlink() and drop_nlink() when doing directory operations on a fuzzed filesystem. Link: http://lkml.kernel.org/r/20200628060846.682158-3-ebiggers@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+a9ac3de1b5de5fb10efc@syzkaller.appspotmail.com Reported-by: syzbot+df958cf5688a96ad3287@syzkaller.appspotmail.com Signed-off-by: Eric Biggers Cc: Alexander Viro Cc: Qiujun Huang Cc: Signed-off-by: Andrew Morton --- fs/minix/inode.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/fs/minix/inode.c~fs-minix-dont-allow-getting-deleted-inodes +++ a/fs/minix/inode.c @@ -468,6 +468,13 @@ static struct inode *V1_minix_iget(struc iget_failed(inode); return ERR_PTR(-EIO); } + if (raw_inode->i_nlinks == 0) { + printk("MINIX-fs: deleted inode referenced: %lu\n", + inode->i_ino); + brelse(bh); + iget_failed(inode); + return ERR_PTR(-ESTALE); + } inode->i_mode = raw_inode->i_mode; i_uid_write(inode, raw_inode->i_uid); i_gid_write(inode, raw_inode->i_gid); @@ -501,6 +508,13 @@ static struct inode *V2_minix_iget(struc iget_failed(inode); return ERR_PTR(-EIO); } + if (raw_inode->i_nlinks == 0) { + printk("MINIX-fs: deleted inode referenced: %lu\n", + inode->i_ino); + brelse(bh); + iget_failed(inode); + return ERR_PTR(-ESTALE); + } inode->i_mode = raw_inode->i_mode; i_uid_write(inode, raw_inode->i_uid); i_gid_write(inode, raw_inode->i_gid);