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 9B462C54EAA for ; Mon, 30 Jan 2023 18:00:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FE1D6B0071; Mon, 30 Jan 2023 13:00:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AEA06B0072; Mon, 30 Jan 2023 13:00:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1766B6B0073; Mon, 30 Jan 2023 13:00:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0999C6B0071 for ; Mon, 30 Jan 2023 13:00:26 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D7A52140B3B for ; Mon, 30 Jan 2023 18:00:25 +0000 (UTC) X-FDA: 80412230010.15.DE2302C Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf14.hostedemail.com (Postfix) with ESMTP id 043AD10001C for ; Mon, 30 Jan 2023 18:00:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=V6GP4VfZ; spf=pass (imf14.hostedemail.com: domain of glider@google.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675101623; 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=qeeO0muJc63AtgyRY2bnkkH6u3phpiwZmrClVwHeBEo=; b=mV8Gmq+i3bsSJhF0FbjgcaG2F1rKRNl5JwTacJwF05yN4Bnb5/6VkYfztSlhwUn7eXrEV7 k2hBWo8HPgLXYMBAgjklHac/83GJirSNuTW27O3+jCWaPTBiVA6dvoxtxWwB6R4G/g15vR /b2nhixQ9p25vaygr/1duMAp5QX6pgc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=V6GP4VfZ; spf=pass (imf14.hostedemail.com: domain of glider@google.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675101623; a=rsa-sha256; cv=none; b=q5Zk/7zjNNbLNUPhNMhNVoON03Py4a1XH5kEu9Y7oKxyyKkaoD26Xa81cYHoecHPLRDfFm 9qI5w6WCOWOrVsquEysggqJwLaE46lAFeFT6Wi5SKsMY/5UKV9nTN6lJbhmd81H2DRAmQp hkDYFT3caQPrMokpphpPIaplImD3Lds= Received: by mail-vs1-f54.google.com with SMTP id p10so8920152vsu.5 for ; Mon, 30 Jan 2023 10:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qeeO0muJc63AtgyRY2bnkkH6u3phpiwZmrClVwHeBEo=; b=V6GP4VfZrNzU2D5zuwo0NPyl2YHs9yVedxsvI9A0n4rROnmatrdp+Cw2M637sJPJU8 64kESSJMYPeVdsTxAIpuzTqdHCDS+KXmY/WUXkFyDMbu513QW1N0VNrPMomf89OMALiA 1Y6yfXsa/EHS4OCNJyOe+iCzfGpPSOCPSHxDr9u7G/DpQChv1ucdDQ9bAk+kwhisjCxG Eea/ER8QqpGzttvYYE9BHL8uSAs6slzQU9pdwCFT2rBfGSBBjkyX8BFv15TVzNT/ulFc M7OSyijc4mHujcNMTpsmlW0adMJettHikS6Bu5QFVURLBVWsbf/glckrzdtBukLqKs0O L6XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qeeO0muJc63AtgyRY2bnkkH6u3phpiwZmrClVwHeBEo=; b=iknaEw+u/IgLLN58Yg25Pr7VToNcAHZThFo8lE5HY2rmjf1u5vPrqpHoHLof48jkSj ZQgSDcDuqvzLXf0NrwNsiEKSdNyI/kYvYUFFcj0yXaut1olH22NEAA4ZSTcHHo22gftw /djvAHeuyO27Cz0f25qw5vuSk1JVE+8vQcTr17qGW9ecJDW3U0XgR6dGTnoMqLBAm+Qw GS6fJBP5FIRtUr7kUqHLPpfCMkV2ZJwePI8ibzXy4Lr5OZWvr7yuGVOwoJlpCLb+KrAU uwmnd1pb6t0dtgWElAnfnXs3GNAVxHXKkoogeJ2ZyWu85hqJJosnF4Q//2aJ+TuVF/5T RowA== X-Gm-Message-State: AO0yUKU4pzUjNOLH2HubTIFrcL3Ktw2g/+yn0fiA2xASDOfSTgzXuQ40 NJHHHdRVq/16jz7jfRIcvdF10WlkgejDTKx31QrRSg== X-Google-Smtp-Source: AK7set/TYaFtWnZHcBBMy2SDxHlTt70E23XScKK0Y1EW7ItjvJ4FTz76KujSZX0gdHshdVQ5dK8L1GnHnJ6gOWXWtg4= X-Received: by 2002:a05:6102:449:b0:3fc:3a9e:3203 with SMTP id e9-20020a056102044900b003fc3a9e3203mr224518vsq.84.1675101621972; Mon, 30 Jan 2023 10:00:21 -0800 (PST) MIME-Version: 1.0 References: <20230130130739.563628-1-arnd@kernel.org> In-Reply-To: From: Alexander Potapenko Date: Mon, 30 Jan 2023 18:59:45 +0100 Message-ID: Subject: Re: [PATCH] mm: extend max struct page size for kmsan To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 043AD10001C X-Rspam-User: X-Stat-Signature: xw8f9pybsqbpcjbpt7r5ad1tugg433qy X-HE-Tag: 1675101622-207943 X-HE-Meta: U2FsdGVkX1+Ib12fREnprY6YJjCE+HpC+oF8eIwfjN+A1yjoou1vMrZWJOZmZqx6CZZd8O6Yvh1TAAW7nRRezpxne1GSufd+9gMxakeKrWYPcssNkeM8nF/DWmiLg48lwWc+esGij5lwJsREn6HXDCd7U47+0xFqjtwOU5ol0qmVcYF77TGknMGzntIhnBv2f09gMc5lLibsKs8ra2f3NI5cPTgxsDGT85bBceAmmKVUI1H7rC6afsVQuex/KbRKavS6T6+FaFXIWfYwXfL5Sva9AsXfVWzx4w0xjo2Ww9Cb8+kMqnaPUlE9JV/+vJe0KzLFyxwBeA6rYWf9rNWEagihiOn5lwZ9+SBGp4J0zzHUebZcD5EQ8iggfczkR7cOeAAImDaEQQcMSRucH2TmN6Oq3ArZLr1gqX3SjzSN+eJJAzDUCmtg99bPpIrLgRTpZ5Bjp4aDJGNPpIjLtEbm9rETELSiHKKNpcUhK5wntGiEKBBZCn1W7+ED9waxe7oWzAU0/s2YkGXqk7MqBXtR9/7IOkU02G7/i0BftgSgSyp6Sacx+x8LcD39PqWTduNjtjnbnUzBqsBXOWTPK3Y67y3IvemOsFKpEHwl8+1sV+i8GkHQUZN4SR8OhPkoOLuwSYLBrOqL8Lv8aJ0xVeQxGsrDD6+r/24yG8h5tfSMqyGFqs9MAY4Xfb793iCukyH2/l/gOWEB4Mb0m+kvcTZB669LWCHwG88qBWr4Sun83IHzpIYQRYfLqVTEJyK2+ALx//QOnRfAd6vzJTIGRiikcJ1e0c0vfFs00xVoy1JeTaEi6YXuWZekfme5pheD36jPyfelb+p5iGJUV7kfUk2GcHzmCeywIZvKvoXp2bKResKRxYljbjFU0iqqgyvYGJUG9ALNW8H7rzAdd7cQm0j7PUHc007KCwKo8NNu4NtyHgCqT1Tg6EQYqt+AbdJGF04SyHvwNqSoArWAmv/JPH2 6QD0j3Tf ubdF+GkinPX2DhRqUSaLR0CT2CoKFlmZm+htRhq1BG+qszofTQAzC6Ae46Jgj6N0EY28UEmYV9ZlH7ewQhyDTZd1gieCUv6Jnhh7JzBuWY35nbi2Rk/RYpiS7KLt1mxX+pV9yKGFSUgQaDueD9pP0iVitAyIEAGDFgD6ZRjoKTJY5jstuSTTy1Q8Rr6gDE4zkmWFAFgxbKXtglIwF42amsx/EZzmnol849sXmsmHjlC6DD5ffUPbANKDvHl09RsJw3o1EN+cDk9GBHpK3yhXqA7bbJ0z579IGbIFtC23p4boHR4A= 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, 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. 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. [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.