Messages in this thread |  | | Date | Fri, 8 May 2026 20:14:56 +0800 | | From | Nathan Chancellor <> | | Subject | Re: [tip: locking/core] locking/rtmutex: Annotate API and implementation |
| |
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@acm.org> > > > AuthorDate: Tue, 05 May 2026 04:26:44 +02:00 > > > Committer: Peter Zijlstra <peterz@infradead.org> > > > 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@acm.org> > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> > > > Link: https://patch.msgid.link/20260505022649.870788-1-bvanassche@acm.org > > > > 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@intel.com/). > 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
|  |