Re: [tip: locking/core] locking/rtmutex: Annotate API and implementation

[Nathan Chancellor]

On Thu, May 07, 2026 at 12:09:25PM +0200, Bart Van Assche wrote:
> On 5/7/26 10:43 AM, Nathan Chancellor wrote:
> > On Tue, May 05, 2026 at 10:55:34AM -0000, tip-bot2 for Bart Van Assche wrote:
> > > The following commit has been merged into the locking/core branch of tip:
> > > 
> > > Commit-ID:     d30a456aa7ce1bab05d9b364eeacad0c9cb10cc2
> > > Gitweb:        https://git.kernel.org/tip/d30a456aa7ce1bab05d9b364eeacad0c9cb10cc2
> > > Author:        Bart Van Assche <bvanassche@xxxxxxx>
> > > AuthorDate:    Tue, 05 May 2026 04:26:44 +02:00
> > > Committer:     Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > > CommitterDate: Tue, 05 May 2026 12:50:49 +02:00
> > > 
> > > locking/rtmutex: Annotate API and implementation
> > > 
> > > Add lock context annotations to the rtmutex API and implementation and
> > > enable lock context analysis.
> > > 
> > > Signed-off-by: Bart Van Assche <bvanassche@xxxxxxx>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > > Link: https://patch.msgid.link/20260505022649.870788-1-bvanassche@xxxxxxx
> > 
> > This breaks the build for me.
> > 
> >    $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 mrproper defconfig kernel/locking/rtmutex_api.o
> >    kernel/locking/rtmutex_api.c:93:1: error: expecting rt_mutex 'lock' to be held at the end of function [-Werror,-Wthread-safety-analysis]
> >       93 | }
> >          | ^
> >    kernel/locking/rtmutex_api.c:90:14: note: rt_mutex acquired here
> >       90 | void __sched rt_mutex_lock(struct rt_mutex *lock)
> >          |              ^
> >    1 error generated.
> > 
> > This is with LLVM 22.1.5, in case it matters.
> 
> Hi Nathan,
> 
> I think this is the same error as what has been reported by the kernel
> test robot
> (https://lore.kernel.org/all/202605060005.JYWpZXr2-lkp@xxxxxxxxx/).
> I plan to post a new version with a fix for CONFIG_DEBUG_LOCK_ALLOC=n
> soon.

Thanks, I missed that report in trying to keep up with my inbox on
vacation :) In the meantime, perhaps this should be dropped from
locking/core since it is on top? Peter?

-- 
Cheers,
Nathan