linux-kernel - Re: [RFC 2/3] mm: add STATIC_PMD_ZERO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1c1f0ad7-8668-406b-9e4c-59ee52f816b3@intel.com>
Date: Tue, 27 May 2025 11:30:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>
Cc: Pankaj Raghav <p.raghav@...sung.com>,
 Suren Baghdasaryan <surenb@...gle.com>, Ryan Roberts <ryan.roberts@....com>,
 Vlastimil Babka <vbabka@...e.cz>, Baolin Wang
 <baolin.wang@...ux.alibaba.com>, Borislav Petkov <bp@...en8.de>,
 Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>,
 Zi Yan <ziy@...dia.com>, Mike Rapoport <rppt@...nel.org>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Michal Hocko <mhocko@...e.com>,
 David Hildenbrand <david@...hat.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Thomas Gleixner <tglx@...utronix.de>, Nico Pache <npache@...hat.com>,
 Dev Jain <dev.jain@....com>, "Liam R . Howlett" <Liam.Howlett@...cle.com>,
 Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, linux-block@...r.kernel.org, willy@...radead.org,
 x86@...nel.org, linux-fsdevel@...r.kernel.org,
 "Darrick J . Wong" <djwong@...nel.org>, mcgrof@...nel.org,
 gost.dev@...sung.com, hch@....de
Subject: Re: [RFC 2/3] mm: add STATIC_PMD_ZERO_PAGE config option

On 5/27/25 11:00, Pankaj Raghav (Samsung) wrote:
>> I get that callers have to handle failure. But isn't this pretty nasty
>> for mm==NULL callers to be *guaranteed* to fail? They'll generate code
>> for the success case that will never even run.
>>
> The idea was to still have dynamic allocation possible even if this
> config was disabled.

I don't really understand what you are trying to say here.

> You are right that if this config is disabled, the callers with NULL mm
> struct are guaranteed to fail, but we are not generating extra code
> because there are still users who want dynamic allocation.

I'm pretty sure you're making the compiler generate unnecessary code.
Think of this:

	if (mm_get_huge_zero_folio(mm)
		foo();
	else
		bar();

With the static zero page, foo() is always called. But bar() is dead
code. The compiler doesn't know that, so it will generate both sides of
the if().

If you can get the CONFIG_... option checks into the header, the
compiler can figure it out and not even generate the call to bar().

> Do you think it is better to have the code with inside an #ifdef instead
> of using the IS_ENABLED primitive?
It has nothing to do with an #ifdef versus IS_ENABLED(). It has to do
with the compiler having visibility into how mm_get_huge_zero_folio()
works enough to optimize its callers.