Re: [PATCH v3 14/18] list: Permit context-unguarded access with list_empty_careful()

[Nilay Shroff]

On 7/12/26 3:29 AM, Marco Elver wrote:
> On Fri, 10 Jul 2026 at 10:10, Nilay Shroff <nilay@xxxxxxxxxxxxx> wrote:
> > Hi Marco,
> >
> > On 7/9/26 12:00 PM, Christoph Hellwig wrote:
> > > On Mon, Jul 06, 2026 at 07:44:16PM +0530, Nilay Shroff wrote:
> > > > From: Marco Elver <elver@xxxxxxxxxx>
> > > >
> > > > With Context Analysis (viz. Clang's Thread Safety Analysis), list_heads
> > > > that are __guarded_by(..) require holding the appropriate context lock
> > > > when accessing and manipulating them via the list API. Because Clang's
> > > > warning diagnostics do not perform inter-procedural analysis, this is
> > > > enforced by Clang with -Wthread-safety-pointer in the caller at the call
> > > > boundary; a warning is produced when passing a pointer to a guarded
> > > > variable without holding the appropriate context locks:
> > >
> > > Same thing here, maybe try to get this to Linus late in the current
> > > window as it's trivial and makes dependency management much easier.
>
> It's not a bug fix, more of a feature, so I don't think this should be
> sent in a post-rc1 PR (and Linus would likely reject it).
>
> > > If that doesn't work, move it to the front of the series.
> > Would it be possible for you to send a pull request for Linus directly, or
> > would it need to go through another maintainer?
>
> Needs another maintainer.
>
> > If you're able to send it directly, we also have patch 09/18 in this
> > series that should go to Linus. In that case, I'd suggest including both
> > patches in the same pull request.
>
> list has no de-facto maintainer, so anyone could take it. My guess is
> it could go through tip/locking/core since it's related to Context
> Analysis...
>
> ... alas, this is more complex than it needs to be, esp. given it's
> borderline to get this merged post-rc1.
>
> > Otherwise, as Christoph suggested, I'll move these patches to the
> > beginning of the series in the next revision.
>
> I'd just move it to the beginning on the respin, given what I said above.
Okay so then I'd move it at the beginning while I spin next revision.

Thanks,
--Nilay