Re: [PATCH v3 14/18] list: Permit context-unguarded access with list_empty_careful()
Marco Elver <[email protected]>
| Newsgroups | org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CANpmjNMckikjJUdTT=ugs4pHMTOOQ+9mvSWZG31BGU3EFvRU1g@mail.gmail.com> |
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. Thanks, -- Marco