Re: [PATCH v2 07/12] rbd: Enable lock context analysis

On Tue, 4 Aug 2026 at 20:24, Bart Van Assche <[email protected]> wrote:
>
> On 8/4/26 3:48 AM, Nilay Shroff wrote:
> > However, I still think acquiring_list, running_list, and object_map should
> > ideally be guarded by their respective locks. The fact that some code
> > obtains
> > pointers to these objects before acquiring the corresponding lock makes the
> > locking pattern worth looking at more closely rather than simply leaving
> > these fields unannotated.
>
> Marco, to implement what Nilay is asking I need support for annotating
> function arguments with __guarded_by(). This would not only be useful
> for the rbd driver but also for other Linux kernel drivers, e.g. the
> loop driver. If I try to annotate function arguments in the loop driver
> with __guarded_by() the following error message appears:
>
> drivers/block/loop.c:2002:30: warning: 'guarded_by' attribute only
> applies to non-static data members and global variables
> [-Wignored-attributes]
>   2002 |                 struct list_head *cmd_list
> __guarded_by(&lo->lo_work_lock))
>
> Your opinion about this is welcome.

Can you show the diff you're trying?

It doesn't seem right to me. For one, the source of truth is scattered
around, and it's not all that obvious which arguments should then have
this attribute and which should not.

I wonder if there's a cleaner way to design this, where the source of
truth is centralized (hence the restriction on struct members or
globals) and not scattered around.

In general the analysis warns on __guarded_by fields passed by
pointer, but from what I can tell that wouldn't work here because the
locks should not be acquired before the function call that takes the
pointer.