linux-kernel - Re: [PATCH v2 0/5] list private v2 & luo flb v9

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: <CA+CK2bD41sMDbN670G5RrNQ-3Qq36dO3LmD18zFu6uc9KxhRzQ@mail.gmail.com>
Date: Thu, 18 Dec 2025 17:30:45 -0500
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: pratyush@...nel.org, rppt@...nel.org, dmatlack@...gle.com, 
	skhawaja@...gle.com, rientjes@...gle.com, corbet@....net, kees@...nel.org, 
	davidgow@...gle.com, pmladek@...e.com, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, nicolas.frattaroli@...labora.com, 
	linux-doc@...r.kernel.org, tamird@...il.com, raemoar63@...il.com, 
	graf@...zon.com
Subject: Re: [PATCH v2 0/5] list private v2 & luo flb v9

On Thu, Dec 18, 2025 at 4:07 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Thu, 18 Dec 2025 10:57:47 -0500 Pasha Tatashin <pasha.tatashin@...een.com> wrote:
>
> > This series includes two separate workstreams. This is because FLB
> > should be applied on top of list_private, as it uses some of its
> > interfaces.
> >
> > 1. List private v2 (first 3 patches) Previous version:
> > https://lore.kernel.org/all/20251126185725.4164769-1-pasha.tatashin@soleen.com
> > For details, please read the cover letter from the previous submission.
> >
> > v2 Changelog:
> > - Added a Reviewed-by from David Gow.
> >
> > 2. LUO FLB v9 (last 2 patches) Previous version:
> > https://lore.kernel.org/all/20251125225006.3722394-2-pasha.tatashin@soleen.com
>
> Please, no.
>
> This patch series is intended for the Linux kernel.  Your grandchildren
> will read the above wondering "what did granddad do".  It's just lazy
> for us to expect readers to have to chase down links to earlier
> versions and then to figure out what changed and why we changed it,
> etc, etc.
>
> Let's give our audience a nice, self-contained and complete description
> of the proposed changes which doesn't refer them to the minute details
> of the ongoing development process.  A process which is utterly
> uninteresting three years from now.
>
> IOW, can we please have a complete and standalone description of *this
> patchset* which doesn't refer to earlier obsolete stuff?

Hi Andrew,

Point taken. You are right; the cover letter should be self-contained
and stand on its own for future readers. Here is the standalone
description of this patch series:

This series introduces two connected infrastructure improvements: a
new API for handling private linked lists, and the
"File-Lifecycle-Bound" (FLB) mechanism for the Live Update
Orchestrator.

1. Private List Primitives (patches 1-3)
Recently, Linux introduced the ability to mark structure members as
__private and access them via ACCESS_PRIVATE(). This enforces better
encapsulation by ensuring internal details are only accessible by the
owning subsystem.

However, struct list_head is frequently used as an internal linkage
mechanism within these private sections. The standard macros in
<linux/list.h> do not support ACCESS_PRIVATE() natively. Consequently,
subsystems using private lists are forced to implement ad-hoc
workarounds or local iterator macros.

This series adds <linux/list_private.h>, providing a set of primitives
identical to those in <linux/list.h> but designed for private list
heads. It also includes a KUnit test suite to verify that the macros
correctly handle pointer offsets and qualifiers.

2. This series adds FLB (patches 4-5) support to Live Update that also
internally uses private lists.

FLB allows global kernel state (such as IOMMU domains or HugeTLB
state) to be preserved once, shared across multiple file descriptors,
and restored when needed. This is necessary for subsystems where
multiple preserved file descriptors depend on a single, shared
underlying resource. Preserving this state for each individual file
would be redundant and incorrect.

FLB uses reference counting tied to the lifecycle of preserved files.
The state is preserved when the first file depending on it is
preserved, and restored or cleaned up only when the last file is
handled.

Changelog:
List-Private v2:
- Added a Reviewed-by from David Gow.
FLB v9:
- Addressed suggestions from David Matlack and Pratyush Yadav: added
  booleans to track if an object was retrieved and/or finished.
- Modified the patches to use the list_private interfaces.

Previous submissions:
List-Private:
v1 https://lore.kernel.org/all/20251126185725.4164769-1-pasha.tatashin@soleen.com

FLB:
v8 https://lore.kernel.org/all/20251125225006.3722394-2-pasha.tatashin@soleen.com

Thank you,
Pasha