Re: [PATCH bpf-next v1 1/1] bpf: Annotate rqspinlock lock acquiring functions with __must_check

[David Laight <david.laight.linux@gmail.com>]

On Thu, 20 Nov 2025 12:12:12 -0800
Amery Hung <ameryhung@gmail.com> wrote:

> On Tue, Nov 18, 2025 at 2:42 AM David Laight
> <david.laight.linux@gmail.com> wrote:
> >
> > On Tue, 18 Nov 2025 05:16:50 -0500
> > Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
> >  
> > > On Mon, 17 Nov 2025 at 14:15, Amery Hung <ameryhung@gmail.com> wrote:  
> > > >
> > > > Locking a resilient queued spinlock can fail when deadlock or timeout
> > > > happen. Mark the lock acquring functions with __must_check to make sure
> > > > callers always handle the returned error.
> > > >
> > > > Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> > > > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > > > ---  
> > >
> > > Looks like it's working :)
> > > I would just explicitly ignore with (void) cast the locktorture case.  
> >
> > I'm not sure that works - I usually have to try a lot harder to ignore
> > a '__must_check' result.  
> 
> Thanks for the heads up.
> 
> Indeed, gcc still complains about it even casting the return to (void)
> while clang does not.
> 
> I have to silence the warning by:
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wunused-result"
>        raw_res_spin_lock(&rqspinlock);
> #pragma GCC diagnostic pop

I think the simpler:
	if (raw_res_spin_lock(&rqspinlock)) {};
also works.
But I'm sure I've resorted to crap like:
	x += foo() ? 0 : 0;
and/or:
	x += foo() == IMPOSSIBLE_VALUE;
and/or wrapping the call in a static inline function.

It is all a right PITA when you are doing read/write on a pipe
that is being used for events.

At least no one has put a 'must_check' on fprintf() (yet).
Code that looks at the return value is usually broken!
(hint: you need to call fflush() and then check ferror().)

	David

> 
> Thanks!
> Amery
> 
> >
> >         David