From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 405FDC636CC for ; Tue, 31 Jan 2023 15:14:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F7676B0074; Tue, 31 Jan 2023 10:14:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A64E6B0075; Tue, 31 Jan 2023 10:14:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86D216B0078; Tue, 31 Jan 2023 10:14:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 784086B0074 for ; Tue, 31 Jan 2023 10:14:27 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 420F21C640B for ; Tue, 31 Jan 2023 15:14:27 +0000 (UTC) X-FDA: 80415440574.29.03CC3E9 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf15.hostedemail.com (Postfix) with ESMTP id 4B337A0006 for ; Tue, 31 Jan 2023 15:14:24 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=SXoFGUs2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675178064; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OV/OJTpgobZKCQPy9XYs86MI0Im29Efzc4mHl7jHYoU=; b=PxUpFqHjwDfJMeXdarxGYGMWPrbBZqZfVubymM5k8QDxNurZmh1JkfAudzZyAdzTIeL9iG qM5HJZ5F5AQ3tMnTRXC/NaStB8gMJJTiZYptdirvaLN5whxhtUqQtcnCMwmYbmNMYwdfRI HF92uGh5ThArcgSk04Tj4lhs2r06vDQ= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=SXoFGUs2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675178064; a=rsa-sha256; cv=none; b=g0Tjm/zSk2nXsCC2zTZRNCGMUSJhSW/WRhigBYdiVceuCF6o5qlD/noSUANZx7Q5vhQmc3 Wbu75TdgWTcZBCoOPdsiiGJsZPHKW9AlW7f2rTQR1t6qMf+C7q/uc7ec8396dJnyyXFpHv iUg2XfqMXtB4fFV3iF2WnuU6Ld3iyaQ= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B0F9E20861; Tue, 31 Jan 2023 15:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1675178062; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OV/OJTpgobZKCQPy9XYs86MI0Im29Efzc4mHl7jHYoU=; b=SXoFGUs2SXaKyexc5VzLHQNpRZuibBtgk63O5h7IrYQ+oKuQA4LFWOSPdAtnSCnLvdDXQh MN1ogCJweEH0Br/8YGQIY3uTuZUcjN89m4uFs5HDrN773Qp4XM/hfawX93R5QDKsNmMrgq BXepfIX2xJlKcTwVrPwI//VQoSf+4to= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 918D813585; Tue, 31 Jan 2023 15:14:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 9kdvIk4w2WN7WwAAMHmgww (envelope-from ); Tue, 31 Jan 2023 15:14:22 +0000 Date: Tue, 31 Jan 2023 16:14:21 +0100 From: Michal Hocko To: Alexander Potapenko Cc: Arnd Bergmann , Andrew Morton , Alexander Duyck , Pavel Tatashin , Arnd Bergmann , "Matthew Wilcox (Oracle)" , David Hildenbrand , "Liam R. Howlett" , John Hubbard , Naoya Horiguchi , Hugh Dickins , Suren Baghdasaryan , Alex Sierra , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: extend max struct page size for kmsan Message-ID: References: <20230130130739.563628-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4B337A0006 X-Stat-Signature: 9jb4u1qsmtoe7w6ms5381xm8mbgdby8f X-HE-Tag: 1675178064-207647 X-HE-Meta: U2FsdGVkX1+4KTw9viEpoinobLohDQejOqpBjAIrBB0B3rf30rE421//NjJd02zXr1TIrnyPdjyyDu78L90vPR8b+iIcp5EmN3HwneIvmpliDOOB4Yxrrplk0I1UYxX8TBogOUfoFq0lHA7L3Fq+Skq6PR1Bxi0V6dgQbv8SU4KPSVLm5VZJP3Ej1xQV5Shsvb4IPy4mv6v7SzIRTEACOonzBeLNOM8ckq9z4PmuMvfX6gQUvBaY5595IR2ui0lWSMiGqSORqxXbttByxi1mIXGzcOty8zmFfwwb0Dh0CmhkVFwN9OdfWIyCRTw9+IoJrL0OnLWB/mRFiQyozlqImTGT5uHgET9zhMLVRwWTSK8cs5XbmfJeQk/UgXveKeUcxmc1bjN/2S7YCLlRtnqqwuFx2q1nRRNWmzX7BYYrGZXhDANVRvmrAxv0UhmDBo/3iDfa1rXFOHix3KDc3/orijoBWpZ2Xf+C6ZzgJudIXh7b0iTGlz6ha2SyMXPERyfId40rD6NAaaTILCYiHVlsQW9JaBBDAZqwzltdbvP0NYLQjp+WU6PL+9qN7omZO3pz5Ca+bVKgqiIAr6sZZjio1CqxnsJ33D3KXUy+TwSzWx0iKAgRWAl9fipux56ZHkeYjOTolSEclD7cs69Jk0KHXkcnDSMUIC9dcWbuOWZqzulRprNFS7tLupIigna72NpUlrF4ur063ZFiv4KHSyKGCOyANOv2EgPkD6cTs3B4paBFb9N6ZGCacNrDn+AJIjMIIHx+tULtfYgF+lFfJAbqAggCpaWUaAmloEFYkiNfNwo14VPo0+A/rxI8zBCXk1UOiZDFJmFhGJdye5T218f22059jXYhwzflzKDXC7qL3+omr5s4029SUsXDwU6hio3Omq7ImfXb9OlIxf/s1V4+Gpr/U0DxDV8SDMn+945ADJ2mVxKRaVl4hGS/yyM9jX7ce6k9rFZ2wI6rCIp5GnI REpUwn9a 4RYSVNs4ccfvYfyUop3/lW5z8I+XuX/A6Z9/AduQoOfX2NwytS0lZNrcOpI6c1h2nAOAlWKvw/kJyVyQILkZ4UyC7xq2f0U/dZIqDbGLsYTuBTXyC1W0amEEGlbHBl96s/a5Hj5mk7xmUgU6lfUIW46k/vPn7xbvIMHRQnZPnyRvgSwcHnn/Ml33gZOleBzep+yR9NhIkooIHQRX2CEmJVBdCoFKuMRq+bOhd 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: On Mon 30-01-23 18:59:45, Alexander Potapenko wrote: > On Mon, Jan 30, 2023 at 2:38 PM Michal Hocko wrote: > > > > On Mon 30-01-23 14:07:26, Arnd Bergmann wrote: > > > From: Arnd Bergmann > > > > > > After x86 has enabled support for KMSAN, it has become possible > > > to have larger 'struct page' than was expected when commit > > > 5470dea49f53 ("mm: use mm_zero_struct_page from SPARC on all 64b > > > architectures") was merged: > > > > > > include/linux/mm.h:156:10: warning: no case matching constant switch condition '96' > > > switch (sizeof(struct page)) { > > > > > > Extend the maximum accordingly. > > > > > > Fixes: 5470dea49f53 ("mm: use mm_zero_struct_page from SPARC on all 64b architectures") > > > Fixes: 4ca8cc8d1bbe ("x86: kmsan: enable KMSAN builds for x86") > > > Signed-off-by: Arnd Bergmann > > > > Acked-by: Michal Hocko > > > > I haven't really followed KMSAN development but I would have expected > > that it would, like other debugging tools, add its metadata to page_ext > > rather than page directly. > > Thanks for the comment! > I was considering page_ext at some point, but managed to convince > myself it didn't suit the purpose well enough. > > Right now KMSAN allocates its metadata at boot time, when tearing down memblock. > At that point only a handful of memory ranges exist, and it is pretty > easy to carve out some unused pages for the metadata for those ranges, > then divide the rest evenly and return 1/3 to the system, spending 2/3 > to keep the metadata for the returned pages. > I tried allocating the memory lazily (at page_alloc(), for example), > and it turned out to be very tricky because of fragmentation: for an > allocation of a given order, one needs shadow and origin allocations > of the same order [1], and alloc_pages() simply started with ripping > apart the biggest chunk of memory available. page_ext allocation happens quite early as well. There shouldn't be any real fragmentation that early during the boot. > IIRC if we choose to allocate metadata via page_ext, the memory will > be already too fragmented to easily handle it, because it will only > happen once alloc_pages() is available. > We also can't get rid of the shadow/origin pointers in struct page_ext > (storing two 4K-sized arrays in that struct would defeat all the > possible alignments), so we won't save any memory by switching to > page_ext. With page_ext you would allow to compile the feature in disabled by default and allow to boot time enable it. > [1] - I can go into more details, but the TLDR is that contiguous > pages within the same allocations better have contiguous shadow/origin > pages, otherwise unaligned accesses will corrupt other pages. -- Michal Hocko SUSE Labs