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

Nilay Shroff <[email protected]>
Newsgroups org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/12/26 3:29 AM, Marco Elver wrote:
> On Fri, 10 Jul 2026 at 10:10, Nilay Shroff <[email protected]> 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 <[email protected]>
>>>>
>>>> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.