[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250901-ungut-geerntet-51b9f03284be@brauner>
Date: Mon, 1 Sep 2025 15:44:51 +0200
From: Christian Brauner <brauner@...nel.org>
To: Max Kellermann <max.kellermann@...os.com>
Cc: akpm@...ux-foundation.org, david@...hat.com, axelrasmussen@...gle.com,
yuanchu@...gle.com, willy@...radead.org, hughd@...gle.com, mhocko@...e.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, lorenzo.stoakes@...cle.com,
Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
vishal.moola@...il.com, linux@...linux.org.uk, James.Bottomley@...senpartnership.com,
deller@....de, agordeev@...ux.ibm.com, gerald.schaefer@...ux.ibm.com,
hca@...ux.ibm.com, gor@...ux.ibm.com, borntraeger@...ux.ibm.com,
svens@...ux.ibm.com, davem@...emloft.net, andreas@...sler.com,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com, chris@...kel.net,
jcmvbkbc@...il.com, viro@...iv.linux.org.uk, jack@...e.cz, weixugc@...gle.com,
baolin.wang@...ux.alibaba.com, rientjes@...gle.com, shakeel.butt@...ux.dev, thuth@...hat.com,
broonie@...nel.org, osalvador@...e.de, jfalempe@...hat.com, mpe@...erman.id.au,
nysal@...ux.ibm.com, linux-arm-kernel@...ts.infradead.org,
linux-parisc@...r.kernel.org, linux-s390@...r.kernel.org, sparclinux@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v5 00/12] mm: establish const-correctness for pointer
parameters
On Mon, Sep 01, 2025 at 02:30:16PM +0200, Max Kellermann wrote:
> For improved const-correctness.
>
> This patch series systematically adds const qualifiers to pointer
> parameters throughout the memory management subsystem, establishing a
> foundation for improved const-correctness across the entire Linux
> kernel.
>
> Const-correctness provides multiple benefits:
>
> 1. Type Safety: The compiler enforces that functions marked as taking
> const parameters cannot accidentally modify the data, catching
> potential bugs at compile time rather than runtime.
>
> 2. Compiler Optimizations: When the compiler knows data won't be
> modified, it can generate more efficient code through better
> register allocation, code motion, and aliasing analysis.
>
> 3. API Documentation: Const qualifiers serve as self-documenting code,
> making it immediately clear to developers which functions are
> read-only operations versus those that modify state.
>
> 4. Maintenance Safety: Future modifications to const-correct code are
> less likely to introduce subtle bugs, as the compiler will reject
> attempts to modify data that should remain unchanged.
>
> The memory management subsystem is a fundamental building block of the
> kernel. Most higher-level kernel subsystems (filesystems, drivers,
> networking) depend on mm interfaces. By establishing
> const-correctness at this foundational level:
>
> 1. Enables Propagation: Higher-level subsystems can adopt
> const-correctness in their own interfaces. Without const-correct
> mm functions, filesystems cannot mark their own parameters const
> when they need to call mm functions.
>
> 2. Maximum Impact: Changes to core mm APIs benefit the entire kernel, as
> these functions are called from virtually every subsystem.
>
> 3. Prevents Impedance Mismatch: Without const-correctness in mm, other
> subsystems must either cast away const (dangerous) or avoid using
> const altogether (missing optimization opportunities).
>
> Each patch focuses on a specific header or subsystem component to ease review
> and bisection.
>
> This work was initially posted as a single large patch:
> https://lore.kernel.org/lkml/20250827192233.447920-1-max.kellermann@ionos.com/
>
> Following feedback from Lorenzo Stoakes and David Hildenbrand, it has been
> split into focused, reviewable chunks. The approach was validated with a
> smaller patch that received agreement:
> https://lore.kernel.org/lkml/20250828130311.772993-1-max.kellermann@ionos.com/
>
> Signed-off-by: Max Kellermann <max.kellermann@...os.com>
Seems fine,
Reviewed-by: Christian Brauner <brauner@...nel.org>
Powered by blists - more mailing lists