From patchwork Fri Nov 22 01:53:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11257135 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E5FA314C0 for ; Fri, 22 Nov 2019 01:53:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A97A22067D for ; Fri, 22 Nov 2019 01:53:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="JMS29L8K" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A97A22067D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E7C586B0494; Thu, 21 Nov 2019 20:53:51 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id E534D6B0495; Thu, 21 Nov 2019 20:53:51 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8FFF6B0496; Thu, 21 Nov 2019 20:53:51 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id C41786B0494 for ; Thu, 21 Nov 2019 20:53:51 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 83104180AD81A for ; Fri, 22 Nov 2019 01:53:51 +0000 (UTC) X-FDA: 76182242262.21.price85_5bdb6ce443f5c X-Spam-Summary: 2,0,0,b2c2db244036b8c9,d41d8cd98f00b204,akpm@linux-foundation.org,:akpm@linux-foundation.org:david@redhat.com::mhocko@suse.com:mm-commits@vger.kernel.org:osalvador@suse.de:pasha.tatashin@soleen.com:torvalds@linux-foundation.org:vincent.whitchurch@axis.com,RULES_HIT:41:355:379:800:960:967:973:988:989:1260:1263:1345:1381:1431:1437:1534:1542:1711:1730:1747:1777:1792:2198:2199:2393:2525:2559:2563:2682:2685:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:5007:6261:6653:7576:7903:8599:8603:8660:9025:9545:10004:10913:11026:11473:11658:11914:12043:12048:12297:12438:12517:12519:12555:12679:12783:12986:13148:13230:13846:13869:14181:14721:14849:21063:21067:21080:21451:21627:21740:21795:21939:30005:30012:30051:30054,0,RBL:error,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules: 0:0:0,LF X-HE-Tag: price85_5bdb6ce443f5c X-Filterd-Recvd-Size: 3342 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Nov 2019 01:53:51 +0000 (UTC) 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 DDAF420692; Fri, 22 Nov 2019 01:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574387630; bh=GUtZ281BGBLSSwvJdttO1ArPz6dJmsly+Xp3hMbIG9M=; h=Date:From:To:Subject:From; b=JMS29L8K+ipPKwiSjUybUJua42qAHJfXl2BzRRxuBlC2r9bHE7Lr19QrWh5Kjw3EW SvqLx5umD7SCg8z0YGPI1R0lcCUvKQhd2u8dCRsi5XtxesuffBgKV9AozcjTS5Th1+ f51j5AGGBNIEb/ZSIywM3Axw0eFvo7qkSsayhx5o= Date: Thu, 21 Nov 2019 17:53:49 -0800 From: akpm@linux-foundation.org To: akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, osalvador@suse.de, pasha.tatashin@soleen.com, torvalds@linux-foundation.org, vincent.whitchurch@axis.com Subject: [patch 1/4] mm/sparse: consistently do not zero memmap Message-ID: <20191122015349.DnuP3a202%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Vincent Whitchurch Subject: mm/sparse: consistently do not zero memmap sparsemem without VMEMMAP has two allocation paths to allocate the memory needed for its memmap (done in sparse_mem_map_populate()). In one allocation path (sparse_buffer_alloc() succeeds), the memory is not zeroed (since it was previously allocated with memblock_alloc_try_nid_raw()). In the other allocation path (sparse_buffer_alloc() fails and sparse_mem_map_populate() falls back to memblock_alloc_try_nid()), the memory is zeroed. AFAICS this difference does not appear to be on purpose. If the code is supposed to work with non-initialized memory (__init_single_page() takes care of zeroing the struct pages which are actually used), we should consistently not zero the memory, to avoid masking bugs. (I noticed this because on my ARM64 platform, with 1 GiB of memory the first [and only] section is allocated from the zeroing path while with 2 GiB of memory the first 1 GiB section is allocated from the non-zeroing path.) Michal: "the main user visible problem is a memory wastage. The overal amount of memory should be small. I wouldn't call it stable material." Link: http://lkml.kernel.org/r/20191030131122.8256-1-vincent.whitchurch@axis.com Signed-off-by: Vincent Whitchurch Acked-by: Michal Hocko Acked-by: David Hildenbrand Reviewed-by: Oscar Salvador Reviewed-by: Pavel Tatashin Signed-off-by: Andrew Morton --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c~mm-sparse-consistently-do-not-zero-memmap +++ a/mm/sparse.c @@ -458,7 +458,7 @@ struct page __init *__populate_section_m if (map) return map; - map = memblock_alloc_try_nid(size, + map = memblock_alloc_try_nid_raw(size, PAGE_SIZE, addr, MEMBLOCK_ALLOC_ACCESSIBLE, nid); if (!map) From patchwork Fri Nov 22 01:53:52 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11257137 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 81C3113A4 for ; Fri, 22 Nov 2019 01:53:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4F0E6206EC for ; Fri, 22 Nov 2019 01:53:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="VYiZ0cUC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F0E6206EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7EC766B0496; Thu, 21 Nov 2019 20:53:55 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 7C3686B0497; Thu, 21 Nov 2019 20:53:55 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 702006B0498; Thu, 21 Nov 2019 20:53:55 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id 5ACCF6B0496 for ; Thu, 21 Nov 2019 20:53:55 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 228D14DD6 for ; Fri, 22 Nov 2019 01:53:55 +0000 (UTC) X-FDA: 76182242430.22.price71_5c597b3d45231 X-Spam-Summary: 2,0,0,0d0002bcec39e54e,d41d8cd98f00b204,akpm@linux-foundation.org,:akpm@linux-foundation.org:baijiaju1990@gmail.com: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:tv@lio96.de,RULES_HIT:41:69:355:379:800:960:967:973:988:989:1260:1263:1345:1381:1431:1437:1534:1543:1711:1730:1747:1777:1792:2393:2525:2553:2559:2563:2682:2685:2693:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3150:3354:3865:3866:3867:3868:3870:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:5007:6261:6653:6737:7514:7576:7903:8603:9025:9391:9545:9592:10004:10913:11026:11658:11914:12043:12048:12291:12296:12297:12438:12517:12519:12555:12679:12683:12783:12986:13221:13229:13255:14096:14181:14721:14849:21080:21433:21451:21627:21819:21939:30054:30064:30090,0,RBL:error,CacheIP:none,Ba yesian:0 X-HE-Tag: price71_5c597b3d45231 X-Filterd-Recvd-Size: 4953 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Nov 2019 01:53:54 +0000 (UTC) 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 317842067D; Fri, 22 Nov 2019 01:53:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574387633; bh=+3cqOrujKJf3R1GhUgUvlHJKs8TUJPMAV+6CuQiVIGA=; h=Date:From:To:Subject:From; b=VYiZ0cUCGkRIlaz1CUi/bWBlTp9kJn+Xg0ig7RiRXV2bPPBJ9DGCcOdiAYhaOUxY6 P9WYqygmZ/pjw8/vXxW8WoVMeFAKADf2BNW7HWBD7em4m+BlohpX9QIWUbF8vYczGF LEXPb5xEiKwZk2AIsQnbz0nD92vHtVkzcceBQif8= Date: Thu, 21 Nov 2019 17:53:52 -0800 From: akpm@linux-foundation.org To: akpm@linux-foundation.org, baijiaju1990@gmail.com, gechangwei@live.cn, ghe@suse.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, junxiao.bi@oracle.com, linux-mm@kvack.org, mark@fasheh.com, mm-commits@vger.kernel.org, piaojun@huawei.com, stable@vger.kernel.org, torvalds@linux-foundation.org, tv@lio96.de Subject: [patch 2/4] Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()" Message-ID: <20191122015352.eq1O0h1iC%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Joseph Qi Subject: Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()" This reverts commit 56e94ea132bb5c2c1d0b60a6aeb34dcb7d71a53d. commit 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") introduces a regression that fail to create directory with mount option user_xattr and acl. Actually the reported NULL pointer dereference case can be correctly handled by loc->xl_ops->xlo_add_entry(), so revert it. Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com Fixes: 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") Signed-off-by: Joseph Qi Reported-by: Thomas Voegtle Acked-by: Changwei Ge Cc: Jia-Ju Bai Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton --- fs/ocfs2/xattr.c | 56 ++++++++++++++++++++++++++------------------- 1 file changed, 33 insertions(+), 23 deletions(-) --- a/fs/ocfs2/xattr.c~revert-fs-ocfs2-fix-possible-null-pointer-dereferences-in-ocfs2_xa_prepare_entry +++ a/fs/ocfs2/xattr.c @@ -1490,6 +1490,18 @@ static int ocfs2_xa_check_space(struct o return loc->xl_ops->xlo_check_space(loc, xi); } +static void ocfs2_xa_add_entry(struct ocfs2_xa_loc *loc, u32 name_hash) +{ + loc->xl_ops->xlo_add_entry(loc, name_hash); + loc->xl_entry->xe_name_hash = cpu_to_le32(name_hash); + /* + * We can't leave the new entry's xe_name_offset at zero or + * add_namevalue() will go nuts. We set it to the size of our + * storage so that it can never be less than any other entry. + */ + loc->xl_entry->xe_name_offset = cpu_to_le16(loc->xl_size); +} + static void ocfs2_xa_add_namevalue(struct ocfs2_xa_loc *loc, struct ocfs2_xattr_info *xi) { @@ -2121,31 +2133,29 @@ static int ocfs2_xa_prepare_entry(struct if (rc) goto out; - if (!loc->xl_entry) { - rc = -EINVAL; - goto out; - } - - if (ocfs2_xa_can_reuse_entry(loc, xi)) { - orig_value_size = loc->xl_entry->xe_value_size; - rc = ocfs2_xa_reuse_entry(loc, xi, ctxt); - if (rc) - goto out; - goto alloc_value; - } + if (loc->xl_entry) { + if (ocfs2_xa_can_reuse_entry(loc, xi)) { + orig_value_size = loc->xl_entry->xe_value_size; + rc = ocfs2_xa_reuse_entry(loc, xi, ctxt); + if (rc) + goto out; + goto alloc_value; + } - if (!ocfs2_xattr_is_local(loc->xl_entry)) { - orig_clusters = ocfs2_xa_value_clusters(loc); - rc = ocfs2_xa_value_truncate(loc, 0, ctxt); - if (rc) { - mlog_errno(rc); - ocfs2_xa_cleanup_value_truncate(loc, - "overwriting", - orig_clusters); - goto out; + if (!ocfs2_xattr_is_local(loc->xl_entry)) { + orig_clusters = ocfs2_xa_value_clusters(loc); + rc = ocfs2_xa_value_truncate(loc, 0, ctxt); + if (rc) { + mlog_errno(rc); + ocfs2_xa_cleanup_value_truncate(loc, + "overwriting", + orig_clusters); + goto out; + } } - } - ocfs2_xa_wipe_namevalue(loc); + ocfs2_xa_wipe_namevalue(loc); + } else + ocfs2_xa_add_entry(loc, name_hash); /* * If we get here, we have a blank entry. Fill it. We grow our From patchwork Fri Nov 22 01:53:56 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11257139 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9A79F14C0 for ; Fri, 22 Nov 2019 01:54:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4DC85206F4 for ; Fri, 22 Nov 2019 01:54:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="2rAKCHA3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DC85206F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 52C2F6B0498; Thu, 21 Nov 2019 20:54:01 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 4DC926B0499; Thu, 21 Nov 2019 20:54:01 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41AB96B049A; Thu, 21 Nov 2019 20:54:01 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 2C43C6B0498 for ; Thu, 21 Nov 2019 20:54:01 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id EFC6F583E for ; Fri, 22 Nov 2019 01:54:00 +0000 (UTC) X-FDA: 76182242640.27.love56_5d34a614c7e14 X-Spam-Summary: 50, X-HE-Tag: love56_5d34a614c7e14 X-Filterd-Recvd-Size: 11591 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Nov 2019 01:54:00 +0000 (UTC) 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 5D2C5206CB; Fri, 22 Nov 2019 01:53:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574387639; bh=yHVJsaehfNsBrMdK3lMb7ajJ1qLyQpOg5+UQ+MYBYoI=; h=Date:From:To:Subject:From; b=2rAKCHA3kDsuhlBvQxM+3fLAi9z/pdWbJxYemgWj7BLRqgDHyLZQoJyb9TNDoLZnJ a7eMCms8jNt4/dEjavivnk/PaK+INJs9gzixlUSEGoJRsBTrIjhRM1xVG+vJ4DVDGK 4eQ0MmopmcFzBSlK5tMTsO0SA5FVI3dfvE0kr6Kc= Date: Thu, 21 Nov 2019 17:53:56 -0800 From: akpm@linux-foundation.org To: akpm@linux-foundation.org, alexander.h.duyck@linux.intel.com, aneesh.kumar@linux.ibm.com, anshuman.khandual@arm.com, benh@kernel.crashing.org, borntraeger@de.ibm.com, bp@alien8.de, cai@lca.pw, catalin.marinas@arm.com, christophe.leroy@c-s.fr, dalias@libc.org, damian.tometzki@gmail.com, dan.j.williams@intel.com, dave.hansen@linux.intel.com, david@redhat.com, fenghua.yu@intel.com, gerald.schaefer@de.ibm.com, glider@google.com, gor@linux.ibm.com, gregkh@linuxfoundation.org, heiko.carstens@de.ibm.com, hpa@zytor.com, ira.weiny@intel.com, jgg@ziepe.ca, linux-mm@kvack.org, logang@deltatee.com, luto@kernel.org, mark.rutland@arm.com, mgorman@techsingularity.net, mhocko@suse.com, mingo@redhat.com, mm-commits@vger.kernel.org, mpe@ellerman.id.au, osalvador@suse.de, pagupta@redhat.com, pasha.tatashin@soleen.com, pasic@linux.ibm.com, paulus@samba.org, pavel.tatashin@microsoft.com, peterz@infradead.org, richard.weiyang@gmail.com, richardw.yang@linux.intel.com, robin.murphy@arm.com, rppt@linux.ibm.com, stable@vger.kernel.org, steve.capper@arm.com, t-fukasawa@vx.jp.nec.com, tglx@linutronix.de, thomas.lendacky@amd.com, tony.luck@intel.com, torvalds@linux-foundation.org, vbabka@suse.cz, will@kernel.org, willy@infradead.org, yamada.masahiro@socionext.com, yaojun8558363@gmail.com, ysato@users.sourceforge.jp, yuzhao@google.com Subject: [patch 3/4] mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span() Message-ID: <20191122015356.2g-fSbCJ0%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: David Hildenbrand Subject: mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span() Let's limit shrinking to !ZONE_DEVICE so we can fix the current code. We should never try to touch the memmap of offline sections where we could have uninitialized memmaps and could trigger BUGs when calling page_to_nid() on poisoned pages. There is no reliable way to distinguish an uninitialized memmap from an initialized memmap that belongs to ZONE_DEVICE, as we don't have anything like SECTION_IS_ONLINE we can use similar to pfn_to_online_section() for !ZONE_DEVICE memory. E.g., set_zone_contiguous() similarly relies on pfn_to_online_section() and will therefore never set a ZONE_DEVICE zone consecutive. Stopping to shrink the ZONE_DEVICE therefore results in no observable changes, besides /proc/zoneinfo indicating different boundaries - something we can totally live with. Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug"), the memmap was initialized with 0 and the node with the right value. So the zone might be wrong but not garbage. After that commit, both the zone and the node will be garbage when touching uninitialized memmaps. Toshiki reported a BUG (race between delayed initialization of ZONE_DEVICE memmaps without holding the memory hotplug lock and concurrent zone shrinking). https://lkml.org/lkml/2019/11/14/1040 "Iteration of create and destroy namespace causes the panic as below: [ 41.207694] kernel BUG at mm/page_alloc.c:535! [ 41.208109] invalid opcode: 0000 [#1] SMP PTI [ 41.208508] CPU: 7 PID: 2766 Comm: ndctl Not tainted 5.4.0-rc4 #6 [ 41.209064] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 [ 41.210175] RIP: 0010:set_pfnblock_flags_mask+0x95/0xf0 [ 41.210643] Code: 04 41 83 e2 3c 48 8d 04 a8 48 c1 e0 07 48 03 04 dd e0 59 55 bb 48 8b 58 68 48 39 da 73 0e 48 c7 c6 70 ac 11 bb e8 1b b2 fd ff <0f> 0b 48 03 58 78 48 39 da 73 e9 49 01 ca b9 3f 00 00 00 4f 8d 0c [ 41.212354] RSP: 0018:ffffac0d41557c80 EFLAGS: 00010246 [ 41.212821] RAX: 000000000000004a RBX: 0000000000244a00 RCX: 0000000000000000 [ 41.213459] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffbb1197dc [ 41.214100] RBP: 000000000000000c R08: 0000000000000439 R09: 0000000000000059 [ 41.214736] R10: 0000000000000000 R11: ffffac0d41557b08 R12: ffff8be475ea72b0 [ 41.215376] R13: 000000000000fa00 R14: 0000000000250000 R15: 00000000fffc0bb5 [ 41.216008] FS: 00007f30862ab600(0000) GS:ffff8be57bc40000(0000) knlGS:0000000000000000 [ 41.216771] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.217299] CR2: 000055e824d0d508 CR3: 0000000231dac000 CR4: 00000000000006e0 [ 41.217934] Call Trace: [ 41.218225] memmap_init_zone_device+0x165/0x17c [ 41.218642] memremap_pages+0x4c1/0x540 [ 41.218989] devm_memremap_pages+0x1d/0x60 [ 41.219367] pmem_attach_disk+0x16b/0x600 [nd_pmem] [ 41.219804] ? devm_nsio_enable+0xb8/0xe0 [ 41.220172] nvdimm_bus_probe+0x69/0x1c0 [ 41.220526] really_probe+0x1c2/0x3e0 [ 41.220856] driver_probe_device+0xb4/0x100 [ 41.221238] device_driver_attach+0x4f/0x60 [ 41.221611] bind_store+0xc9/0x110 [ 41.221919] kernfs_fop_write+0x116/0x190 [ 41.222326] vfs_write+0xa5/0x1a0 [ 41.222626] ksys_write+0x59/0xd0 [ 41.222927] do_syscall_64+0x5b/0x180 [ 41.223264] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 41.223714] RIP: 0033:0x7f30865d0ed8 [ 41.224037] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 45 78 0d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 41.225920] RSP: 002b:00007fffe5d30a78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 41.226608] RAX: ffffffffffffffda RBX: 000055e824d07f40 RCX: 00007f30865d0ed8 [ 41.227242] RDX: 0000000000000007 RSI: 000055e824d07f40 RDI: 0000000000000004 [ 41.227870] RBP: 0000000000000007 R08: 0000000000000007 R09: 0000000000000006 [ 41.228753] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004 [ 41.229419] R13: 00007f30862ab528 R14: 0000000000000001 R15: 000055e824d07f40 While creating a namespace and initializing memmap, if you destroy the namespace and shrink the zone, it will initialize the memmap outside the zone and trigger VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page) in set_pfnblock_flags_mask()." This BUG is also mitigated by this commit, where we for now stop to shrink the ZONE_DEVICE zone until we can do it in a safe and clean way. Link: http://lkml.kernel.org/r/20191006085646.5768-5-david@redhat.com Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319] Signed-off-by: David Hildenbrand Reported-by: Aneesh Kumar K.V Reported-by: Toshiki Fukasawa Cc: Oscar Salvador Cc: David Hildenbrand Cc: Michal Hocko Cc: Pavel Tatashin Cc: Dan Williams Cc: Alexander Duyck Cc: Alexander Potapenko Cc: Andy Lutomirski Cc: Anshuman Khandual Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Damian Tometzki Cc: Dave Hansen Cc: Fenghua Yu Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Halil Pasic Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jun Yao Cc: Logan Gunthorpe Cc: Mark Rutland Cc: Masahiro Yamada Cc: "Matthew Wilcox (Oracle)" Cc: Mel Gorman Cc: Michael Ellerman Cc: Mike Rapoport Cc: Pankaj Gupta Cc: Paul Mackerras Cc: Pavel Tatashin Cc: Peter Zijlstra Cc: Qian Cai Cc: Rich Felker Cc: Robin Murphy Cc: Steve Capper Cc: Thomas Gleixner Cc: Tom Lendacky Cc: Tony Luck Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: Wei Yang Cc: Wei Yang Cc: Will Deacon Cc: Yoshinori Sato Cc: Yu Zhao Cc: [4.13+] Signed-off-by: Andrew Morton --- mm/memory_hotplug.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) --- a/mm/memory_hotplug.c~mm-memory_hotplug-dont-access-uninitialized-memmaps-in-shrink_zone_span +++ a/mm/memory_hotplug.c @@ -331,7 +331,7 @@ static unsigned long find_smallest_secti unsigned long end_pfn) { for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SUBSECTION) { - if (unlikely(!pfn_valid(start_pfn))) + if (unlikely(!pfn_to_online_page(start_pfn))) continue; if (unlikely(pfn_to_nid(start_pfn) != nid)) @@ -356,7 +356,7 @@ static unsigned long find_biggest_sectio /* pfn is the end pfn of a memory section. */ pfn = end_pfn - 1; for (; pfn >= start_pfn; pfn -= PAGES_PER_SUBSECTION) { - if (unlikely(!pfn_valid(pfn))) + if (unlikely(!pfn_to_online_page(pfn))) continue; if (unlikely(pfn_to_nid(pfn) != nid)) @@ -415,7 +415,7 @@ static void shrink_zone_span(struct zone */ pfn = zone_start_pfn; for (; pfn < zone_end_pfn; pfn += PAGES_PER_SUBSECTION) { - if (unlikely(!pfn_valid(pfn))) + if (unlikely(!pfn_to_online_page(pfn))) continue; if (page_zone(pfn_to_page(pfn)) != zone) @@ -471,6 +471,16 @@ static void __remove_zone(struct zone *z struct pglist_data *pgdat = zone->zone_pgdat; unsigned long flags; +#ifdef CONFIG_ZONE_DEVICE + /* + * Zone shrinking code cannot properly deal with ZONE_DEVICE. So + * we will not try to shrink the zones - which is okay as + * set_zone_contiguous() cannot deal with ZONE_DEVICE either way. + */ + if (zone_idx(zone) == ZONE_DEVICE) + return; +#endif + pgdat_resize_lock(zone->zone_pgdat, &flags); shrink_zone_span(zone, start_pfn, start_pfn + nr_pages); update_pgdat_span(pgdat); From patchwork Fri Nov 22 01:54:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11257141 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DA4DF14C0 for ; Fri, 22 Nov 2019 01:54:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A7307206D7 for ; Fri, 22 Nov 2019 01:54:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="HAehkxSo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7307206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 79E5D6B049A; Thu, 21 Nov 2019 20:54:04 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 751326B049B; Thu, 21 Nov 2019 20:54:04 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6904B6B049C; Thu, 21 Nov 2019 20:54:04 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 53AD26B049A for ; Thu, 21 Nov 2019 20:54:04 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id DE181824999B for ; Fri, 22 Nov 2019 01:54:03 +0000 (UTC) X-FDA: 76182242766.15.neck88_5da6537e0c61a X-Spam-Summary: 2,0,0,53eab2aaa7ff07c7,d41d8cd98f00b204,akpm@linux-foundation.org,:aarcange@redhat.com:akpm@linux-foundation.org:aryabinin@virtuozzo.com:hughd@google.com::mm-commits@vger.kernel.org:stable@vger.kernel.org:torvalds@linux-foundation.org,RULES_HIT:41:355:379:800:960:967:968:973:988:989:1260:1263:1345:1381:1431:1437:1534:1541:1711:1730:1747:1777:1792:2393:2525:2559:2563:2682:2685:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4419:5007:6119:6261:6653:7576:7875:7903:8599:8660:9025:9545:10004:10913:11026:11473:11658:11914:12043:12048:12114:12297:12438:12517:12519:12555:12679:12783:12986:13069:13148:13230:13255:13311:13357:13846:14093:14096:14181:14384:14721:14849:21063:21080:21451:21627:21939:30054,0,RBL:error,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtim e:40,LUA X-HE-Tag: neck88_5da6537e0c61a X-Filterd-Recvd-Size: 3241 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Nov 2019 01:54:03 +0000 (UTC) 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 49931206DA; Fri, 22 Nov 2019 01:54:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574387642; bh=EsdBhVEjhAGhB+ttu3hBaGhwQ4Q0+rsLVS9kMNRTn2E=; h=Date:From:To:Subject:From; b=HAehkxSoZY5pr1Salw1CWfgkBZD2HyyKxDaJsY7IfQlTsEHUI7XJHh2rll1BaZrrp CLQuQ6jJa9ZfnqzOjmiqL/1dukNN7WTMWN20dRYf20YgSamjrYHiOU47npfgOfZwAu erAsaQI2pkTeUFiJtAy+fSi3nQLr6IddVAqVB2h0= Date: Thu, 21 Nov 2019 17:54:01 -0800 From: akpm@linux-foundation.org To: aarcange@redhat.com, akpm@linux-foundation.org, aryabinin@virtuozzo.com, hughd@google.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 4/4] mm/ksm.c: don't WARN if page is still mapped in remove_stable_node() Message-ID: <20191122015401.XFgHUZogP%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Andrey Ryabinin Subject: mm/ksm.c: don't WARN if page is still mapped in remove_stable_node() It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in remove_stable_node() when it races with __mmput() and squeezes in between ksm_exit() and exit_mmap(). WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150 Call Trace: remove_all_stable_nodes+0x12b/0x330 run_store+0x4ef/0x7b0 kernfs_fop_write+0x200/0x420 vfs_write+0x154/0x450 ksys_write+0xf9/0x1d0 do_syscall_64+0x99/0x510 entry_SYSCALL_64_after_hwframe+0x49/0xbe Remove the warning as there is nothing scary going on. Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com Fixes: cbf86cfe04a6 ("ksm: remove old stable nodes more thoroughly") Signed-off-by: Andrey Ryabinin Acked-by: Hugh Dickins Cc: Andrea Arcangeli Cc: Signed-off-by: Andrew Morton --- mm/ksm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/mm/ksm.c~mm-ksm-dont-warn-if-page-is-still-mapped-in-remove_stable_node +++ a/mm/ksm.c @@ -885,13 +885,13 @@ static int remove_stable_node(struct sta return 0; } - if (WARN_ON_ONCE(page_mapped(page))) { - /* - * This should not happen: but if it does, just refuse to let - * merge_across_nodes be switched - there is no need to panic. - */ - err = -EBUSY; - } else { + /* + * Page could be still mapped if this races with __mmput() running in + * between ksm_exit() and exit_mmap(). Just refuse to let + * merge_across_nodes/max_page_sharing be switched. + */ + err = -EBUSY; + if (!page_mapped(page)) { /* * The stable node did not yet appear stale to get_ksm_page(), * since that allows for an unmapped ksm page to be recognized