[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251126111924.1533590ce355b92d5306a0ec@linux-foundation.org>
Date: Wed, 26 Nov 2025 11:19:24 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: corbet@....net, nicolas.frattaroli@...labora.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, kees@...nel.org,
davidgow@...gle.com, pmladek@...e.com, tamird@...il.com,
raemoar63@...il.com, ebiggers@...nel.org,
diego.daniel.professional@...il.com, rppt@...nel.org, pratyush@...nel.org,
jasonmiu@...gle.com, graf@...zon.com, dmatlack@...gle.com,
rientjes@...gle.com
Subject: Re: [PATCH v1 0/3] list: add primitives for private list
manipulations
On Wed, 26 Nov 2025 13:57:22 -0500 Pasha Tatashin <pasha.tatashin@...een.com> wrote:
> Recently
Well, 2015, in ad315455d396, it seems.
> linux introduced the ability to mark structure members as
> __private and access them via ACCESS_PRIVATE(). This mechanism ensures
> that internal implementation details are only accessible by the owning
> subsystem, enforcing better encapsulation.
Didn't know about this. It's a thing which requires running sparse
(which is fine, people run sparse). It isn't used much at all.
> However, struct list_head is frequently used as an internal linkage
> mechanism within these private sections. The standard macros in
> <linux/list.h> (such as list_entry and list_for_each_entry) do not
> support ACCESS_PRIVATE() natively. Consequently, subsystems using
> private lists are forced to implement ad-hoc workarounds, verbose
> casting, or local iterator macros to avoid compiler warnings and access
> violations.
>
> This series introduces <linux/list_private.h>, which provides a set of
> primitives identical in function to those in <linux/list.h>, but
> designed specifically for cases where the embedded struct list_head is a
> private member.
>
> The series is structured as follows:
> Core Implementation: Adds the list_private.h header with support for
> entry retrieval and iteration (forward, reverse, safe, etc.).
>
> Testing: Adds a KUnit test suite to verify that the macros compile
> correctly and handle pointer offsets/qualifiers as expected.
>
> Adoption: Updates the liveupdate subsystem to use the new generic API,
> replacing its local luo_list_for_each_private implementation.
Fair enough. Let's push this into the next -rc cycle, OK?
Powered by blists - more mailing lists