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

[Nilay Shroff <nilay@linux.ibm.com>]

On 7/12/26 3:29 AM, Marco Elver wrote:
> On Fri, 10 Jul 2026 at 10:10, Nilay Shroff <nilay@linux.ibm.com> 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@google.com>
>>>>
>>>> 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