linux-kernel - Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

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: <aPtpt4hYMuJnwnOO@tiehlicka>
Date: Fri, 24 Oct 2025 13:57:43 +0200
From: Michal Hocko <mhocko@...e.com>
To: Dmitry Ilvokhin <d@...okhin.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	David Hildenbrand <david@...hat.com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Hugh Dickins <hughd@...gle.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Kiryl Shutsemau <kas@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH] mm: shmem/tmpfs hugepage defaults config choice

On Fri 24-10-25 11:19:50, Dmitry Ilvokhin wrote:
> On Fri, Oct 24, 2025 at 09:38:53AM +0200, Michal Hocko wrote:
> > On Thu 23-10-25 18:12:02, Dmitry Ilvokhin wrote:
> > > Allow to override defaults for shemem and tmpfs at config time. This is
> > > consistent with how transparent hugepages can be configured.
> > > 
> > > Same results can be achieved with the existing
> > > 'transparent_hugepage_shmem' and 'transparent_hugepage_tmpfs' settings
> > > in the kernel command line, but it is more convenient to define basic
> > > settings at config time instead of changing kernel command line later.
> > 
> > Being consistent is usually nice but you are not telling us _who_ is
> > going to benefit from this. Increasing the config space is not really
> > free. So please focus on Why do we need it rather than it is consistent
> > argument.
> 
> Thanks for the feedback, Michal, totally make sense to me, I should have
> expand on this point in the initial commit message.
> 
> Primary motivation for adding config option is to enable policy
> enforcement at build time. In large-scale production environments
> (Meta's for example), the kernel configuration is often maintained
> centrally close to the kernel code itself and owned by the kernel
> engineers, while boot parameters are managed independently (e.g. by
> provisioning systems). In such setups, the kernel build defines the
> supported and expected behavior in a single place, but there is no
> reliable or uniform control over the kernel command line options.
> 
> A build-time default allows kernel integrators to enforce a predictable
> hugepage policy for shmem/tmpfs on a base layer, ensuring reproducible
> behavior and avoiding configuration drift caused by possible boot-time
> differences.
> 
> In short, primary benefit is mostly operational: it provides a way to
> codify preferred policy in the kernel configuration, which is versioned,
> reviewed, and tested as part of the kernel build process, rather than
> depending on potentially variable boot parameters.

Please expand the changelog with this explanation. Thanks!

> I hope possible operational benefits outweigh downsides from increasing
> the config space. Please, let me know if this argument sounds
> reasonable to you, I'll rephrase commit message for v2 to include this
> reasoning.

Yes, this is exactly what I was looking for. Thank you.

With this information added, feel free to add
Acked-by: Michal Hocko <mhocko@...e.com>
-- 
Michal Hocko
SUSE Labs