From: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
corbet@lwn.net, nicolas.frattaroli@collabora.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, kees@kernel.org, davidgow@google.com,
pmladek@suse.com, tamird@gmail.com, raemoar63@gmail.com,
ebiggers@kernel.org, diego.daniel.professional@gmail.com,
pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com,
dmatlack@google.com, rientjes@google.com
Subject: Re: [PATCH v1 0/3] list: add primitives for private list manipulations
Date: Thu, 27 Nov 2025 07:09:18 +0200 [thread overview]
Message-ID: <aSfc_h6U9GZo0KBG@kernel.org> (raw)
In-Reply-To: <20251126185725.4164769-1-pasha.tatashin@soleen.com>
(added Dan Carpenter)
On Wed, Nov 26, 2025 at 01:57:22PM -0500, Pasha Tatashin wrote:
> Recently 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.
>
> 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.
>
> Pasha Tatashin (3):
> list: add primitives for private list manipulations
> list: add kunit test for private list primitives
> liveupdate: luo_file: Use private list
>
> Documentation/core-api/list.rst | 9 ++
> include/linux/list_private.h | 256 +++++++++++++++++++++++++++++++
> kernel/liveupdate/luo_file.c | 7 +-
> kernel/liveupdate/luo_internal.h | 7 -
> lib/Kconfig.debug | 14 ++
> lib/tests/Makefile | 1 +
> lib/tests/list-private-test.c | 76 +++++++++
> 7 files changed, 360 insertions(+), 10 deletions(-)
> create mode 100644 include/linux/list_private.h
> create mode 100644 lib/tests/list-private-test.c
>
>
> base-commit: 663d0d1af3faefe673cabf4b6b077149a87ad71f
> --
> 2.52.0.487.g5c8c507ade-goog
>
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2025-11-27 5:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 18:57 [PATCH v1 0/3] list: add primitives for private list manipulations Pasha Tatashin
2025-11-26 18:57 ` [PATCH v1 1/3] " Pasha Tatashin
2025-11-26 18:57 ` [PATCH v1 2/3] list: add kunit test for private list primitives Pasha Tatashin
2025-11-29 7:47 ` David Gow
2025-11-29 19:48 ` Pasha Tatashin
2025-11-26 18:57 ` [PATCH v1 3/3] liveupdate: luo_file: Use private list Pasha Tatashin
2025-12-17 22:47 ` Andrew Morton
2025-12-18 0:58 ` Pasha Tatashin
2025-11-26 19:19 ` [PATCH v1 0/3] list: add primitives for private list manipulations Andrew Morton
2025-11-28 14:45 ` Pasha Tatashin
2025-12-06 0:52 ` Pasha Tatashin
2025-12-06 21:39 ` Andrew Morton
2025-12-06 23:25 ` Pasha Tatashin
2025-11-27 5:09 ` Mike Rapoport [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aSfc_h6U9GZo0KBG@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dan.carpenter@linaro.org \
--cc=davidgow@google.com \
--cc=diego.daniel.professional@gmail.com \
--cc=dmatlack@google.com \
--cc=ebiggers@kernel.org \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=kees@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.frattaroli@collabora.com \
--cc=pasha.tatashin@soleen.com \
--cc=pmladek@suse.com \
--cc=pratyush@kernel.org \
--cc=raemoar63@gmail.com \
--cc=rientjes@google.com \
--cc=tamird@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.