Re: [PATCHv2 11/17] nvme: add Clang context annotations for nvme_queue::sq_lock
From: Marco Elver
Date: Fri Jun 26 2026 - 05:51:32 EST
On Fri, 26 Jun 2026 at 08:47, Christoph Hellwig <hch@xxxxxx> wrote:
>
> On Sun, Jun 14, 2026 at 06:45:26PM +0530, Nilay Shroff wrote:
> > Accesses to sq_tail used solely for tracing are annotated with
> > context_unsafe(), as they only require a lockless snapshot of the
This sounds like an intentional "benign" data race...
> > value. Likewise, nvme_init_queue() and nvme_free_queue() operate on
> > queues that have not yet been published or are no longer reachable,
> > and therefore do not require sq_lock protection. Similarly,
> > nvme_alloc_sq_cmds() allocates memory for nvme_queue::sq_cmds for
> > the queue which is not yet published or in use and hence it's safe
> > to annotate all these helpers using context_unsafe.
>
> Accessing scalar fields without lock is pretty common. Don't we
> have an annotation that only requires the guarding lock for
> writes?
If the writes can happen concurrently with readers these are data
races. I'd probably annotate the particular reads with data_race(...):
this will both tell Context Analysis this is ok without a lock, and
also if KCSAN is enabled, not to report these data races when actually
observed at runtime
(https://docs.kernel.org/dev-tools/lkmm/docs/access-marking.html).