From patchwork Sat Jun 27 03:33:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 222994 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=-4.0 required=3.0 tests=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 B1A17C433DF for ; Sat, 27 Jun 2020 03:33:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 882B02084C for ; Sat, 27 Jun 2020 03:33:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593228830; bh=9aCY+fs856WbCobIwLtg6Sdo5vaEx5w2kdSz5ZqKKaI=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=kR2HTx2r6HYXYLe70Jy5MJ/IYTysw0h1ajhb6aWbZQo04OkCFsfcuGYo6pXQoqjYX V0NpLtyAhNrvLCCJGJb9hyReChAQW8X+G7KE7Ke1+/rxFpSh/s7t72fdcXwRpGeCdR pDcUfyzDJy1nWyRs3YeAEdvw36sLG0M0GESOQE+E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726008AbgF0Ddu (ORCPT ); Fri, 26 Jun 2020 23:33:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:45402 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725913AbgF0Ddu (ORCPT ); Fri, 26 Jun 2020 23:33:50 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 8546920857; Sat, 27 Jun 2020 03:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593228829; bh=9aCY+fs856WbCobIwLtg6Sdo5vaEx5w2kdSz5ZqKKaI=; h=Date:From:To:Subject:In-Reply-To:From; b=Q5Q/6CvnXTfgEOkWScDUEMhRfkuibLVchJYnUFWPVkE98b85nIVXIVq0jEAVf0Whv CCJePwEmu6QCSbVG0eNeguPy5lRcbNSwB0Oa5KPDSK1RrCKqTqqMPrbTOqaN840YhL rl88slw/zsQW3n40ORSyJZsn55D0h0mlHcu8iE+k= Date: Fri, 26 Jun 2020 20:33:49 -0700 From: Andrew Morton To: cai@lca.pw, guro@fb.com, hannes@cmpxchg.org, mhocko@suse.com, mm-commits@vger.kernel.org, songmuchun@bytedance.com, stable@vger.kernel.org, vdavydov.dev@gmail.com Subject: [merged] mm-memcontrol-fix-do-not-put-the-css-reference.patch removed from -mm tree Message-ID: <20200627033349.GJZiEpfqJ%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@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/memcontrol.c: add missed css_put() has been removed from the -mm tree. Its filename was mm-memcontrol-fix-do-not-put-the-css-reference.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Muchun Song Subject: mm/memcontrol.c: add missed css_put() We should put the css reference when memory allocation failed. Link: http://lkml.kernel.org/r/20200614122653.98829-1-songmuchun@bytedance.com Fixes: f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management") Signed-off-by: Muchun Song Acked-by: Roman Gushchin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Qian Cai Cc: Signed-off-by: Andrew Morton --- mm/memcontrol.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/memcontrol.c~mm-memcontrol-fix-do-not-put-the-css-reference +++ a/mm/memcontrol.c @@ -2772,8 +2772,10 @@ static void memcg_schedule_kmem_cache_cr return; cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN); - if (!cw) + if (!cw) { + css_put(&memcg->css); return; + } cw->memcg = memcg; cw->cachep = cachep; From patchwork Fri Jun 26 03:29:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 223005 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=-4.0 required=3.0 tests=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 6B07EC433DF for ; Fri, 26 Jun 2020 03:29:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 449322081A for ; Fri, 26 Jun 2020 03:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142167; bh=BOOtNScon/F8RSvOC5TUchukW1Vi8hVtCQbXchQ1dOQ=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=KVCjF3qvMONXlrXKBNHJhcrkaXfoXO8SAxgvVHcVJzlWytAK251NfrFc0TZ1BWQNX GDjAGEWXJVXlAGgobVm/Rpd7FxALdAZGZTKgsAS5x2MLSVHyFUjl8Fy7rnPCe4fDeV DX8yjIybK/IJB2ujpdb1Yc5KPoIpTXajq1qufyyI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728331AbgFZD3Z (ORCPT ); Thu, 25 Jun 2020 23:29:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:47838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728259AbgFZD3Z (ORCPT ); Thu, 25 Jun 2020 23:29:25 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 E41342084D; Fri, 26 Jun 2020 03:29:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142165; bh=BOOtNScon/F8RSvOC5TUchukW1Vi8hVtCQbXchQ1dOQ=; h=Date:From:To:Subject:In-Reply-To:From; b=sRprRrBw/9EDVnMNdWctQPhoi3O8zHvwTGASoW5AT5SJhIWFPBirb3Wgu6g48S58v 0EqwezipKb4zBuKLVJyruPUyxkt0O6f4NxZD8U91ZD4+CkICaR/Iu4bYUaXHUMqzNc Gcr7S2riV8pzpWxhT6IwA57626zHpuNEOVAcYNAA= Date: Thu, 25 Jun 2020 20:29:24 -0700 From: Andrew Morton To: akpm@linux-foundation.org, alex.shi@linux.alibaba.com, hughd@google.com, liwang@redhat.com, mgorman@techsingularity.net, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, vbabka@suse.cz Subject: [patch 03/32] mm, compaction: make capture control handling safe wrt interrupts Message-ID: <20200626032924.PiPdcjulX%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@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: Vlastimil Babka Subject: mm, compaction: make capture control handling safe wrt interrupts Hugh reports: : While stressing compaction, one run oopsed on NULL capc->cc in : __free_one_page()'s task_capc(zone): compact_zone_order() had been : interrupted, and a page was being freed in the return from interrupt. : : Though you would not expect it from the source, both gccs I was using (a : 4.8.1 and a 7.5.0) had chosen to compile compact_zone_order() with the : ".cc = &cc" implemented by mov %rbx,-0xb0(%rbp) immediately before callq : compact_zone - long after the "current->capture_control = &capc". An : interrupt in between those finds capc->cc NULL (zeroed by an earlier rep : stos). : : This could presumably be fixed by a barrier() before setting : current->capture_control in compact_zone_order(); but would also need more : care on return from compact_zone(), in order not to risk leaking a page : captured by interrupt just before capture_control is reset. : : Maybe that is the preferable fix, but I felt safer for task_capc() to : exclude the rather surprising possibility of capture at interrupt time. I have checked that gcc10 also behaves the same. The advantage of fix in compact_zone_order() is that we don't add another test in the page freeing hot path, and that it might prevent future problems if we stop exposing pointers to uninitialized structures in current task. So this patch implements the suggestion for compact_zone_order() with barrier() (and WRITE_ONCE() to prevent store tearing) for setting current->capture_control, and prevents page leaking with WRITE_ONCE/READ_ONCE in the proper order. Link: http://lkml.kernel.org/r/20200616082649.27173-1-vbabka@suse.cz Fixes: 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction") Signed-off-by: Vlastimil Babka Reported-by: Hugh Dickins Suggested-by: Hugh Dickins Acked-by: Hugh Dickins Cc: Alex Shi Cc: Li Wang Cc: Mel Gorman Cc: [5.1+] Signed-off-by: Andrew Morton --- mm/compaction.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) --- a/mm/compaction.c~mm-compaction-make-capture-control-handling-safe-wrt-interrupts +++ a/mm/compaction.c @@ -2316,15 +2316,26 @@ static enum compact_result compact_zone_ .page = NULL, }; - current->capture_control = &capc; + /* + * Make sure the structs are really initialized before we expose the + * capture control, in case we are interrupted and the interrupt handler + * frees a page. + */ + barrier(); + WRITE_ONCE(current->capture_control, &capc); ret = compact_zone(&cc, &capc); VM_BUG_ON(!list_empty(&cc.freepages)); VM_BUG_ON(!list_empty(&cc.migratepages)); - *capture = capc.page; - current->capture_control = NULL; + /* + * Make sure we hide capture control first before we read the captured + * page pointer, otherwise an interrupt could free and capture a page + * and we would leak it. + */ + WRITE_ONCE(current->capture_control, NULL); + *capture = READ_ONCE(capc.page); return ret; } From patchwork Fri Jun 26 03:29:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 223004 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=-4.0 required=3.0 tests=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 D851DC433E1 for ; Fri, 26 Jun 2020 03:29:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B085C20899 for ; Fri, 26 Jun 2020 03:29:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142175; bh=xzW7GcU3Xkn2ECJdEx9naFOYj6dCoOw6fUqm/J6zLHk=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=w2p3jOv9cjmCm2j4SXueSJP4EdcCqVDCz0m/AUcCz5LJF+ckzkzXIK6FONJoO20Tp SuHBHmZS1ObX6RPJhMSTmLTlGQZirI5Xs2Ldk4T/nLQ5ZDIk2yUsPfEtyNjfQz2LrV 6oTIKIpbNUXZlEM3yB1DQGQCCu18TKIuqr6D0c2A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728343AbgFZD3f (ORCPT ); Thu, 25 Jun 2020 23:29:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:47976 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728333AbgFZD3e (ORCPT ); Thu, 25 Jun 2020 23:29:34 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 3AC722089D; Fri, 26 Jun 2020 03:29:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142174; bh=xzW7GcU3Xkn2ECJdEx9naFOYj6dCoOw6fUqm/J6zLHk=; h=Date:From:To:Subject:In-Reply-To:From; b=sCTh870syYZyIx7JXE4r5j3iiae3O/+VKbJ8544Z4tvPd9BMtBS8XiWisSDoYt0En cDodmtNKdCK2zgO89T7OXQcGtPxnR3W7xWXzU/zZdyOKv2p/uACOL3cnEyhFJdEDJw eVBhKD01Vxs6Uoj94BNyRxPzNfO7vVP20x8Fp904= Date: Thu, 25 Jun 2020 20:29:33 -0700 From: Andrew Morton To: akpm@linux-foundation.org, gechangwei@live.cn, ghe@suse.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, junxiao.bi@oracle.com, mark@fasheh.com, mm-commits@vger.kernel.org, piaojun@huawei.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 06/32] ocfs2: load global_inode_alloc Message-ID: <20200626032933.GT-b1mIKo%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@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: Junxiao Bi Subject: ocfs2: load global_inode_alloc Set global_inode_alloc as OCFS2_FIRST_ONLINE_SYSTEM_INODE, that will make it load during mount. It can be used to test whether some global/system inodes are valid. One use case is that nfsd will test whether root inode is valid. Link: http://lkml.kernel.org/r/20200616183829.87211-3-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton --- fs/ocfs2/ocfs2_fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ocfs2/ocfs2_fs.h~ocfs2-load-global_inode_alloc +++ a/fs/ocfs2/ocfs2_fs.h @@ -326,8 +326,8 @@ struct ocfs2_system_inode_info { enum { BAD_BLOCK_SYSTEM_INODE = 0, GLOBAL_INODE_ALLOC_SYSTEM_INODE, +#define OCFS2_FIRST_ONLINE_SYSTEM_INODE GLOBAL_INODE_ALLOC_SYSTEM_INODE SLOT_MAP_SYSTEM_INODE, -#define OCFS2_FIRST_ONLINE_SYSTEM_INODE SLOT_MAP_SYSTEM_INODE HEARTBEAT_SYSTEM_INODE, GLOBAL_BITMAP_SYSTEM_INODE, USER_QUOTA_SYSTEM_INODE, From patchwork Fri Jun 26 03:29:40 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 223003 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=-4.0 required=3.0 tests=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 54D05C433DF for ; Fri, 26 Jun 2020 03:29:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 297FD208C9 for ; Fri, 26 Jun 2020 03:29:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142182; bh=c9dYFhRT3mVmYx9tNYP7+Af3F0aNcfc8rcYBPx0okFg=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=X6t2D1ItGIeCuYJjnFqRBWqh6jzEVohd5pRrOsPMul3lULQYxgCC7Bpdv5lPFQAEV dLYnb6AUkmG6JGiFc/mCLQsjZMs8kThISp5JYfLo13dIjvAmqdp2PIbk911Oys9kuo 7MZElEAMYRFpaZ6CTXQv5UGfwUp4FysNnr2WaSPk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728318AbgFZD3l (ORCPT ); Thu, 25 Jun 2020 23:29:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:48064 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728333AbgFZD3l (ORCPT ); Thu, 25 Jun 2020 23:29:41 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 7C48420899; Fri, 26 Jun 2020 03:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142180; bh=c9dYFhRT3mVmYx9tNYP7+Af3F0aNcfc8rcYBPx0okFg=; h=Date:From:To:Subject:In-Reply-To:From; b=hrlipQaRLn+SbSE5HcYLV0f7oOb1NHIjIRQjZ6oINMCGQWo43nPKyR9FOu13gJGa/ HRiBn7zPJwxuvMyA5DyNP5oGgHHKTWJrn+HsuYA//OP5xEYJmnVTaxIMPWvTnfFXX/ eCRCVU9cKy4wusC2Cq16xJ+aE/TgJrlsdLOeuZLA= Date: Thu, 25 Jun 2020 20:29:40 -0700 From: Andrew Morton To: akpm@linux-foundation.org, gechangwei@live.cn, ghe@suse.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, junxiao.bi@oracle.com, mark@fasheh.com, mm-commits@vger.kernel.org, piaojun@huawei.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 08/32] ocfs2: fix value of OCFS2_INVALID_SLOT Message-ID: <20200626032940.e1Dlt7Co6%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@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: Junxiao Bi Subject: ocfs2: fix value of OCFS2_INVALID_SLOT In the ocfs2 disk layout, slot number is 16 bits, but in ocfs2 implementation, slot number is 32 bits. Usually this will not cause any issue, because slot number is converted from u16 to u32, but OCFS2_INVALID_SLOT was defined as -1, when an invalid slot number from disk was obtained, its value was (u16)-1, and it was converted to u32. Then the following checking in get_local_system_inode will be always skipped: static struct inode **get_local_system_inode(struct ocfs2_super *osb, int type, u32 slot) { BUG_ON(slot == OCFS2_INVALID_SLOT); ... } Link: http://lkml.kernel.org/r/20200616183829.87211-5-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton --- fs/ocfs2/ocfs2_fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ocfs2/ocfs2_fs.h~ocfs2-fix-value-of-ocfs2_invalid_slot +++ a/fs/ocfs2/ocfs2_fs.h @@ -290,7 +290,7 @@ #define OCFS2_MAX_SLOTS 255 /* Slot map indicator for an empty slot */ -#define OCFS2_INVALID_SLOT -1 +#define OCFS2_INVALID_SLOT ((u16)-1) #define OCFS2_VOL_UUID_LEN 16 #define OCFS2_MAX_VOL_LABEL_LEN 64 From patchwork Fri Jun 26 03:29:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 223002 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=-4.0 required=3.0 tests=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 B0A66C433E0 for ; Fri, 26 Jun 2020 03:29:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 86E692088E for ; Fri, 26 Jun 2020 03:29:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142194; bh=0gKfvJL/ltoFdRty5G+wwUVc8XVDPFe5FXXxW25f8X4=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=Vy0gRVQwf3xI8tAFeClM9IkwoRsDGKruXprRl7uDNp1l7DuDA3aKgo6NgUR9lKY84 5tl9Fsr5sxb4/sKmguhMdyGjDkIz/5EANN3Jejc5yukRUxMfHXQeSJXt+1LR0Km6UN AMAdgwYxW2FqWd4I2m8moo3NQQt78tJbE5ECsiwE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728353AbgFZD3y (ORCPT ); Thu, 25 Jun 2020 23:29:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:48224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728333AbgFZD3x (ORCPT ); Thu, 25 Jun 2020 23:29:53 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 EE32D20885; Fri, 26 Jun 2020 03:29:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142193; bh=0gKfvJL/ltoFdRty5G+wwUVc8XVDPFe5FXXxW25f8X4=; h=Date:From:To:Subject:In-Reply-To:From; b=TS5e91FM3EaM3K6FBnxqeE+lbn43ypDZ9Ft384qy4WMcC4do2gxBTrxBGgyqWFUNo 76u+XiJnq2Fzii2WFEqfDoeiH5wHvhtH94IJgRokw7x8YIs1YzKbcxuo5ZaA7clBzQ VUXB3MiQUgTw1mhx627zkZKZT3ipdFrTIrbEG+tQ= Date: Thu, 25 Jun 2020 20:29:52 -0700 From: Andrew Morton To: akpm@linux-foundation.org, dan.carpenter@oracle.com, dhowells@redhat.com, hannes@cmpxchg.org, jarkko.sakkinen@linux.intel.com, Jason@zx2c4.com, jmorris@namei.org, joe@perches.com, longman@redhat.com, mhocko@suse.com, mm-commits@vger.kernel.org, rientjes@google.com, serge@hallyn.com, stable@vger.kernel.org, torvalds@linux-foundation.org, willy@infradead.org Subject: [patch 12/32] mm/slab: use memzero_explicit() in kzfree() Message-ID: <20200626032952._ed4K7Snx%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@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: Waiman Long Subject: mm/slab: use memzero_explicit() in kzfree() The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for buffer clearing. However unlikely, there is still a non-zero probability that the compiler may choose to optimize away the memory clearing especially if LTO is being used in the future. To make sure that this optimization will never happen, memzero_explicit(), which is introduced in v3.18, is now used in kzfree() to future-proof it. Link: http://lkml.kernel.org/r/20200616154311.12314-2-longman@redhat.com Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()") Signed-off-by: Waiman Long Acked-by: Michal Hocko Cc: David Howells Cc: Jarkko Sakkinen Cc: James Morris Cc: "Serge E. Hallyn" Cc: Joe Perches Cc: Matthew Wilcox Cc: David Rientjes Cc: Johannes Weiner Cc: Dan Carpenter Cc: "Jason A . Donenfeld" Cc: Signed-off-by: Andrew Morton --- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/slab_common.c~mm-slab-use-memzero_explicit-in-kzfree +++ a/mm/slab_common.c @@ -1726,7 +1726,7 @@ void kzfree(const void *p) if (unlikely(ZERO_OR_NULL_PTR(mem))) return; ks = ksize(mem); - memset(mem, 0, ks); + memzero_explicit(mem, ks); kfree(mem); } EXPORT_SYMBOL(kzfree); From patchwork Fri Jun 26 03:30:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 223001 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=-4.0 required=3.0 tests=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 D4B20C433DF for ; Fri, 26 Jun 2020 03:30:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B0E0D2089D for ; Fri, 26 Jun 2020 03:30:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142218; bh=TPo1UrcUMcQLfguhSa0tPlCmgq3675PgjU4unLb12E8=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=hsX/XXVEHxOeEVT7FD+uXl/lzzm1gqN5NFeyQGcL7s1h339VpdebRNIq6/Qj5OidT /HBZJ10rFkTh5hcwDE26b4u0bmq0cSwrXYZJIKCorgc42o9x9YNuIa0OO3j8NR4xrE tGxmVh2vJijDNyL2Y/AdoTtZjWfF38+LyzjWTL38= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728370AbgFZDaS (ORCPT ); Thu, 25 Jun 2020 23:30:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:48536 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728333AbgFZDaR (ORCPT ); Thu, 25 Jun 2020 23:30:17 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 00FD52053B; Fri, 26 Jun 2020 03:30:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142217; bh=TPo1UrcUMcQLfguhSa0tPlCmgq3675PgjU4unLb12E8=; h=Date:From:To:Subject:In-Reply-To:From; b=a0TzQHUxvXv621WwiBagpR+kfSJ9K7omrQxguyL8NqxTGDC/UjZZoIR/59x37Tawb tD0eRpU8n+MXd6kY5RhPRKgWgdCJ7L7yYX7qYVbwHGiElp0MrVsfuWclHKARk3PzxH 0h+qzXDOz4UogLk1kWWwhircHlo4r8sNclacNJQs= Date: Thu, 25 Jun 2020 20:30:16 -0700 From: Andrew Morton To: akpm@linux-foundation.org, chris@chrisdown.name, guro@fb.com, hannes@cmpxchg.org, mhocko@suse.com, mm-commits@vger.kernel.org, stable@vger.kernel.org, tj@kernel.org, torvalds@linux-foundation.org Subject: [patch 20/32] mm: memcontrol: handle div0 crash race condition in memory.low Message-ID: <20200626033016.7z3uIdJCS%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@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: Johannes Weiner Subject: mm: memcontrol: handle div0 crash race condition in memory.low Tejun reports seeing rare div0 crashes in memory.low stress testing: [37228.504582] RIP: 0010:mem_cgroup_calculate_protection+0xed/0x150 [37228.505059] Code: 0f 46 d1 4c 39 d8 72 57 f6 05 16 d6 42 01 40 74 1f 4c 39 d8 76 1a 4c 39 d1 76 15 4c 29 d1 4c 29 d8 4d 29 d9 31 d2 48 0f af c1 <49> f7 f1 49 01 c2 4c 89 96 38 01 00 00 5d c3 48 0f af c7 31 d2 49 [37228.506254] RSP: 0018:ffffa14e01d6fcd0 EFLAGS: 00010246 [37228.506769] RAX: 000000000243e384 RBX: 0000000000000000 RCX: 0000000000008f4b [37228.507319] RDX: 0000000000000000 RSI: ffff8b89bee84000 RDI: 0000000000000000 [37228.507869] RBP: ffffa14e01d6fcd0 R08: ffff8b89ca7d40f8 R09: 0000000000000000 [37228.508376] R10: 0000000000000000 R11: 00000000006422f7 R12: 0000000000000000 [37228.508881] R13: ffff8b89d9617000 R14: ffff8b89bee84000 R15: ffffa14e01d6fdb8 [37228.509397] FS: 0000000000000000(0000) GS:ffff8b8a1f1c0000(0000) knlGS:0000000000000000 [37228.509917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37228.510442] CR2: 00007f93b1fc175b CR3: 000000016100a000 CR4: 0000000000340ea0 [37228.511076] Call Trace: [37228.511561] shrink_node+0x1e5/0x6c0 [37228.512044] balance_pgdat+0x32d/0x5f0 [37228.512521] kswapd+0x1d7/0x3d0 [37228.513346] ? wait_woken+0x80/0x80 [37228.514170] kthread+0x11c/0x160 [37228.514983] ? balance_pgdat+0x5f0/0x5f0 [37228.515797] ? kthread_park+0x90/0x90 [37228.516593] ret_from_fork+0x1f/0x30 This happens when parent_usage == siblings_protected. We check that usage is bigger than protected, which should imply parent_usage being bigger than siblings_protected. However, we don't read (or even update) these values atomically, and they can be out of sync as the memory state changes under us. A bit of fluctuation around the target protection isn't a big deal, but we need to handle the div0 case. Check the parent state explicitly to make sure we have a reasonable positive value for the divisor. Link: http://lkml.kernel.org/r/20200615140658.601684-1-hannes@cmpxchg.org Fixes: 8a931f801340 ("mm: memcontrol: recursive memory.low protection") Signed-off-by: Johannes Weiner Reported-by: Tejun Heo Acked-by: Michal Hocko Acked-by: Chris Down Cc: Roman Gushchin Cc: Signed-off-by: Andrew Morton --- mm/memcontrol.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/mm/memcontrol.c~mm-memcontrol-handle-div0-crash-race-condition-in-memorylow +++ a/mm/memcontrol.c @@ -6360,11 +6360,16 @@ static unsigned long effective_protectio * We're using unprotected memory for the weight so that if * some cgroups DO claim explicit protection, we don't protect * the same bytes twice. + * + * Check both usage and parent_usage against the respective + * protected values. One should imply the other, but they + * aren't read atomically - make sure the division is sane. */ if (!(cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_RECURSIVE_PROT)) return ep; - - if (parent_effective > siblings_protected && usage > protected) { + if (parent_effective > siblings_protected && + parent_usage > siblings_protected && + usage > protected) { unsigned long unclaimed; unclaimed = parent_effective - siblings_protected; From patchwork Fri Jun 26 03:30:51 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 223000 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=-4.0 required=3.0 tests=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 72BE5C433E0 for ; Fri, 26 Jun 2020 03:30:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A618208C9 for ; Fri, 26 Jun 2020 03:30:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142254; bh=wY/slw8X5uR4JH7hoJhll75ZoEYqMJ/DKl6wxY8qtbE=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=b0vlW1UyyiRaYfAZ2FMNcECRRgt3YtCupvRSaO4di4ZQx/rcrns9SN79E/XvXlE// lws8TiNSEpDs/D6xNTcoKMNoQ5oz+dsDJglshzGWOLHJh1D8l1QOdaZc/0Jm/EUnoF yi+TOFQfD7MuhwEOnHtBZTW1EYQBQ5CVBRzY67lc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728381AbgFZDax (ORCPT ); Thu, 25 Jun 2020 23:30:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:48912 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725900AbgFZDax (ORCPT ); Thu, 25 Jun 2020 23:30:53 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (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 99ACD2089D; Fri, 26 Jun 2020 03:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593142252; bh=wY/slw8X5uR4JH7hoJhll75ZoEYqMJ/DKl6wxY8qtbE=; h=Date:From:To:Subject:In-Reply-To:From; b=oFjqOWFWcH/Q758MuQJDJdoYZg6znHqjNUYj0GYTBf8olrFviQvZd9fCqUrmLY7wN FrGp9dwtCca7Se8r4itS45FF4OiUQ5LJDfTMEhFJxURV9+rfnlp6YPDzWLckCcer/G qDGE2cZmqkAiPuWwF8dNVSKCeXQLCnNl1qmzkT8c= Date: Thu, 25 Jun 2020 20:30:51 -0700 From: Andrew Morton To: akpm@linux-foundation.org, ben.widawsky@intel.com, dan.j.williams@intel.com, david@redhat.com, mm-commits@vger.kernel.org, stable@vger.kernel.org, steve.scargall@intel.com, torvalds@linux-foundation.org, vishal.l.verma@intel.com Subject: [patch 31/32] mm/memory_hotplug.c: fix false softlockup during pfn range removal Message-ID: <20200626033051.73wfBW4YT%akpm@linux-foundation.org> In-Reply-To: <20200625202807.b630829d6fa55388148bee7d@linux-foundation.org> User-Agent: s-nail v14.8.16 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ben Widawsky Subject: mm/memory_hotplug.c: fix false softlockup during pfn range removal When working with very large nodes, poisoning the struct pages (for which there will be very many) can take a very long time. If the system is using voluntary preemptions, the software watchdog will not be able to detect forward progress. This patch addresses this issue by offering to give up time like __remove_pages() does. This behavior was introduced in v5.6 with: commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()") Alternately, init_page_poison could do this cond_resched(), but it seems to me that the caller of init_page_poison() is what actually knows whether or not it should relax its own priority. Based on Dan's notes, I think this is perfectly safe: commit f931ab479dd2 ("mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}") Aside from fixing the lockup, it is also a friendlier thing to do on lower core systems that might wipe out large chunks of hotplug memory (probably not a very common case). Fixes this kind of splat: [ 352.142079] watchdog: BUG: soft lockup - CPU#46 stuck for 22s! [daxctl:9922] [ 352.150067] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security rfkill ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_umad vfat fat kmem intel_rapl_msr intel_rapl_common rpcrdma sunrpc rdma_ucm ib_iser isst_if_common rdma_cm skx_edac iw_cm ib_cm x86_pkg_temp_thermal libiscsi intel_powerclamp scsi_transport_iscsi coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i40iw intel_cstate iTCO_wdt ib_uverbs iTCO_vendor_support device_dax ib_core joydev intel_uncore i2c_i801 lpc_ich ipmi_ssif ioatdma dca wmi ipmi_si ipmi_devintf ipmi_msghandler dax_pmem [ 352.150123] dax_pmem_core acpi_pad acpi_power_meter drm ip_tables xfs libcrc32c nd_pmem nd_btt i40e e1000e crc32c_intel nfit [ 352.260774] irq event stamp: 138450 [ 352.264692] hardirqs last enabled at (138449): [] trace_hardirqs_on_thunk+0x1a/0x1c [ 352.275134] hardirqs last disabled at (138450): [] trace_hardirqs_off_thunk+0x1a/0x1c [ 352.285662] softirqs last enabled at (138448): [] __do_softirq+0x347/0x456 [ 352.295233] softirqs last disabled at (138443): [] irq_exit+0x7d/0xb0 [ 352.304210] CPU: 46 PID: 9922 Comm: daxctl Not tainted 5.7.0-BEN-14238-g373c6049b336 #30 [ 352.313283] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS PLYXCRB1.86B.0578.D07.1902280810 02/28/2019 [ 352.324308] RIP: 0010:memset_erms+0x9/0x10 [ 352.328905] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 [ 352.349953] RSP: 0018:ffffc90021b5fd50 EFLAGS: 00010202 ORIG_RAX: ffffffffffffff13 [ 352.358450] RAX: 00000000000000ff RBX: ffff88983ffd5000 RCX: 0000000065df0e40 [ 352.366457] RDX: 00000003a0000000 RSI: 00000000ffffffff RDI: ffffea039b20f1c0 [ 352.374465] RBP: ffff88983ffd6c00 R08: 0000000000000000 R09: ffffea0061000000 [ 352.382473] R10: 0000000000000001 R11: 0000000000000000 R12: ffffea006f808000 [ 352.390480] R13: 0000000001840000 R14: 000000000e800000 R15: ffff8997d7b764e0 [ 352.398487] FS: 00007f724ef81780(0000) GS:ffff8997df100000(0000) knlGS:0000000000000000 [ 352.407562] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 352.414011] CR2: 00007ffcd4070768 CR3: 000001178c722002 CR4: 00000000003606e0 [ 352.422056] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 352.430092] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 352.438115] Call Trace: [ 352.440865] remove_pfn_range_from_zone+0x3a/0x380 [ 352.446244] ? cpumask_next+0x17/0x20 [ 352.450361] memunmap_pages+0x17f/0x280 [ 352.454670] release_nodes+0x22a/0x260 [ 352.458888] __device_release_driver+0x172/0x220 [ 352.464070] device_driver_detach+0x3e/0xa0 [ 352.468753] unbind_store+0x113/0x130 [ 352.472868] kernfs_fop_write+0xdc/0x1c0 [ 352.477273] vfs_write+0xde/0x1d0 [ 352.482218] ksys_write+0x58/0xd0 [ 352.487207] do_syscall_64+0x5a/0x120 [ 352.492529] entry_SYSCALL_64_after_hwframe+0x49/0xb3 [ 352.499446] RIP: 0033:0x7f724f40b5e7 [ 352.504673] Code: Bad RIP value. [ 352.509484] RSP: 002b:00007ffcd40738f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 352.519213] RAX: ffffffffffffffda RBX: 00007f724ef816a8 RCX: 00007f724f40b5e7 [ 352.528410] RDX: 0000000000000007 RSI: 00005617d7cd1277 RDI: 0000000000000003 [ 352.537573] RBP: 0000000000000003 R08: 00000000ffffffff R09: 00007ffcd40737d0 [ 352.546764] R10: 0000000000000000 R11: 0000000000000246 R12: 00005617d7cd1277 [ 352.555929] R13: 0000000000000000 R14: 0000000000000007 R15: 00005617d7cd1230 [ 370.353742] Built 2 zonelists, mobility grouping on. Total pages: 49050381 [ 370.373317] Policy zone: Normal [ 374.948164] Built 3 zonelists, mobility grouping on. Total pages: 49312525 [ 375.017496] Policy zone: Normal David said: "It really only is an issue for devmem. Ordinary hotplugged system memory is not affected (onlined/offlined in memory block granularity)." Link: http://lkml.kernel.org/r/20200619231213.1160351-1-ben.widawsky@intel.com Fixes: commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()") Signed-off-by: Ben Widawsky Reported-by: "Scargall, Steve" Reported-by: Ben Widawsky Acked-by: David Hildenbrand Cc: Dan Williams Cc: Vishal Verma Cc: Signed-off-by: Andrew Morton --- mm/memory_hotplug.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/mm/memory_hotplug.c~mm-fix-false-softlockup-during-pfn-range-removal +++ a/mm/memory_hotplug.c @@ -471,11 +471,20 @@ void __ref remove_pfn_range_from_zone(st unsigned long start_pfn, unsigned long nr_pages) { + const unsigned long end_pfn = start_pfn + nr_pages; struct pglist_data *pgdat = zone->zone_pgdat; - unsigned long flags; + unsigned long pfn, cur_nr_pages, flags; /* Poison struct pages because they are now uninitialized again. */ - page_init_poison(pfn_to_page(start_pfn), sizeof(struct page) * nr_pages); + for (pfn = start_pfn; pfn < end_pfn; pfn += cur_nr_pages) { + cond_resched(); + + /* Select all remaining pages up to the next section boundary */ + cur_nr_pages = + min(end_pfn - pfn, SECTION_ALIGN_UP(pfn + 1) - pfn); + page_init_poison(pfn_to_page(pfn), + sizeof(struct page) * cur_nr_pages); + } #ifdef CONFIG_ZONE_DEVICE /*