* [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function @ 2026-01-22 2:30 kernel test robot 2026-01-22 9:16 ` Peter Zijlstra 0 siblings, 1 reply; 5+ messages in thread From: kernel test robot @ 2026-01-22 2:30 UTC (permalink / raw) To: Peter Zijlstra; +Cc: llvm, oe-kbuild-all tree: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core head: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a commit: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a [10/10] futex: Convert to compiler context analysis config: arm64-randconfig-001-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/config) compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202601221040.TeM0ihff-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function [-Wthread-safety-analysis] 982 | } | ^ kernel/futex/core.c:976:2: note: spinlock acquired here 976 | spin_lock(lock_ptr); | ^ >> kernel/futex/core.c:982:1: warning: expecting spinlock 'q->lock_ptr' to be held at the end of function [-Wthread-safety-analysis] 982 | } | ^ kernel/futex/core.c:966:6: note: spinlock acquired here 966 | void futex_q_lockptr_lock(struct futex_q *q) | ^ 2 warnings generated. vim +982 kernel/futex/core.c c1e2f0eaf015fb kernel/futex.c Peter Zijlstra 2017-12-08 965 b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 966 void futex_q_lockptr_lock(struct futex_q *q) b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 967 { b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 968 spinlock_t *lock_ptr; b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 969 b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 970 /* b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 971 * See futex_unqueue() why lock_ptr can change. b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 972 */ b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 973 guard(rcu)(); b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 974 retry: b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 975 lock_ptr = READ_ONCE(q->lock_ptr); b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 976 spin_lock(lock_ptr); b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 977 b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 978 if (unlikely(lock_ptr != q->lock_ptr)) { b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 979 spin_unlock(lock_ptr); b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 980 goto retry; b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 981 } b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 @982 } b04b8f3032aae6 kernel/futex/core.c Sebastian Andrzej Siewior 2025-04-16 983 :::::: The code at line 982 was first introduced by commit :::::: b04b8f3032aae6121303bfa324c768faba032242 futex: Introduce futex_q_lockptr_lock() :::::: TO: Sebastian Andrzej Siewior <bigeasy@linutronix.de> :::::: CC: Peter Zijlstra <peterz@infradead.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function 2026-01-22 2:30 [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function kernel test robot @ 2026-01-22 9:16 ` Peter Zijlstra 2026-01-22 18:31 ` Marco Elver 0 siblings, 1 reply; 5+ messages in thread From: Peter Zijlstra @ 2026-01-22 9:16 UTC (permalink / raw) To: kernel test robot; +Cc: llvm, oe-kbuild-all, Marco Elver On Thu, Jan 22, 2026 at 10:30:28AM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core > head: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a > commit: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a [10/10] futex: Convert to compiler context analysis > config: arm64-randconfig-001-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/config) > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710) > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp@intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202601221040.TeM0ihff-lkp@intel.com/ > > All warnings (new ones prefixed by >>): > > >> kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function [-Wthread-safety-analysis] > 982 | } > | ^ > kernel/futex/core.c:976:2: note: spinlock acquired here > 976 | spin_lock(lock_ptr); > | ^ > >> kernel/futex/core.c:982:1: warning: expecting spinlock 'q->lock_ptr' to be held at the end of function [-Wthread-safety-analysis] > 982 | } > | ^ > kernel/futex/core.c:966:6: note: spinlock acquired here > 966 | void futex_q_lockptr_lock(struct futex_q *q) > | ^ > 2 warnings generated. Urgh, this is the arm64 READ_ONCE() confusing the thing. It can't see through that mess and realize: lockptr == q->lock_ptr. Marco, any suggestion how to best fix that? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function 2026-01-22 9:16 ` Peter Zijlstra @ 2026-01-22 18:31 ` Marco Elver 2026-01-23 8:55 ` Peter Zijlstra 0 siblings, 1 reply; 5+ messages in thread From: Marco Elver @ 2026-01-22 18:31 UTC (permalink / raw) To: Peter Zijlstra; +Cc: kernel test robot, llvm, oe-kbuild-all, Will Deacon +Cc Will On Thu, Jan 22, 2026 at 10:16AM +0100, Peter Zijlstra wrote: > On Thu, Jan 22, 2026 at 10:30:28AM +0800, kernel test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core > > head: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a > > commit: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a [10/10] futex: Convert to compiler context analysis > > config: arm64-randconfig-001-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/config) > > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710) > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/reproduce) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot <lkp@intel.com> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202601221040.TeM0ihff-lkp@intel.com/ > > > > All warnings (new ones prefixed by >>): > > > > >> kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function [-Wthread-safety-analysis] > > 982 | } > > | ^ > > kernel/futex/core.c:976:2: note: spinlock acquired here > > 976 | spin_lock(lock_ptr); > > | ^ > > >> kernel/futex/core.c:982:1: warning: expecting spinlock 'q->lock_ptr' to be held at the end of function [-Wthread-safety-analysis] > > 982 | } > > | ^ > > kernel/futex/core.c:966:6: note: spinlock acquired here > > 966 | void futex_q_lockptr_lock(struct futex_q *q) > > | ^ > > 2 warnings generated. > > Urgh, this is the arm64 READ_ONCE() confusing the thing. It can't see > through that mess and realize: lockptr == q->lock_ptr. > > Marco, any suggestion how to best fix that? I have a tentative solution: diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h index 78beceec10cd..75265012ff2d 100644 --- a/arch/arm64/include/asm/rwonce.h +++ b/arch/arm64/include/asm/rwonce.h @@ -31,9 +31,8 @@ */ #define __READ_ONCE(x) \ ({ \ - typeof(&(x)) __x = &(x); \ - int atomic = 1; \ - union { __unqual_scalar_typeof(*__x) __val; char __c[1]; } __u; \ + typeof(&(x)) __x = &(x), *__xp = &__x; \ + union { TYPEOF_UNQUAL(*__x) __val; char __c[1]; } __u; \ switch (sizeof(x)) { \ case 1: \ asm volatile(__LOAD_RCPC(b, %w0, %1) \ @@ -56,9 +55,10 @@ : "Q" (*__x) : "memory"); \ break; \ default: \ - atomic = 0; \ + __u.__val = (*(volatile typeof(__x))__x); \ } \ - atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);\ + *__xp = &__u.__val; \ + *__x; \ }) #endif /* !BUILD_VDSO */ This works because the compiler doesn't analyze alias reassignment through pointer-to-alias within the same function. An alternative is to do the alias reassignment via an __always_inline function that takes the alias as a const pointer, and then cast the const away and do the assignment. But I think the above is cleaner. Only compile-tested. It also gets rid of the "atomic" flag, and switches to TYPEOF_UNQUAL which fixes a latent bug where __unqual_scalar_typeof was applied to a const non-integer variable that is less than 8 bytes, resulting in __val being "const" itself (likely benign). Before: File: vmlinux Size: 59628672 Blocks: 116472 IO Block: 4096 regular file After: File: vmlinux Size: 59563056 Blocks: 116336 IO Block: 4096 regular file So this claims we're saving space. But the couple functions I inspected that use READ_ONCE were identical. I need to double-check the asm, see where the differences are and if we're actually producing better code, and write a commit message that makes sense. ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function 2026-01-22 18:31 ` Marco Elver @ 2026-01-23 8:55 ` Peter Zijlstra 2026-01-23 14:37 ` Marco Elver 0 siblings, 1 reply; 5+ messages in thread From: Peter Zijlstra @ 2026-01-23 8:55 UTC (permalink / raw) To: Marco Elver; +Cc: kernel test robot, llvm, oe-kbuild-all, Will Deacon On Thu, Jan 22, 2026 at 07:31:08PM +0100, Marco Elver wrote: > +Cc Will > > On Thu, Jan 22, 2026 at 10:16AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 22, 2026 at 10:30:28AM +0800, kernel test robot wrote: > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core > > > head: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a > > > commit: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a [10/10] futex: Convert to compiler context analysis > > > config: arm64-randconfig-001-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/config) > > > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710) > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot <lkp@intel.com> > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202601221040.TeM0ihff-lkp@intel.com/ > > > > > > All warnings (new ones prefixed by >>): > > > > > > >> kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function [-Wthread-safety-analysis] > > > 982 | } > > > | ^ > > > kernel/futex/core.c:976:2: note: spinlock acquired here > > > 976 | spin_lock(lock_ptr); > > > | ^ > > > >> kernel/futex/core.c:982:1: warning: expecting spinlock 'q->lock_ptr' to be held at the end of function [-Wthread-safety-analysis] > > > 982 | } > > > | ^ > > > kernel/futex/core.c:966:6: note: spinlock acquired here > > > 966 | void futex_q_lockptr_lock(struct futex_q *q) > > > | ^ > > > 2 warnings generated. > > > > Urgh, this is the arm64 READ_ONCE() confusing the thing. It can't see > > through that mess and realize: lockptr == q->lock_ptr. > > > > Marco, any suggestion how to best fix that? > > I have a tentative solution: > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > index 78beceec10cd..75265012ff2d 100644 > --- a/arch/arm64/include/asm/rwonce.h > +++ b/arch/arm64/include/asm/rwonce.h > @@ -31,9 +31,8 @@ > */ > #define __READ_ONCE(x) \ > ({ \ > - typeof(&(x)) __x = &(x); \ > - int atomic = 1; \ > - union { __unqual_scalar_typeof(*__x) __val; char __c[1]; } __u; \ > + typeof(&(x)) __x = &(x), *__xp = &__x; \ > + union { TYPEOF_UNQUAL(*__x) __val; char __c[1]; } __u; \ > switch (sizeof(x)) { \ > case 1: \ > asm volatile(__LOAD_RCPC(b, %w0, %1) \ > @@ -56,9 +55,10 @@ > : "Q" (*__x) : "memory"); \ > break; \ > default: \ > - atomic = 0; \ > + __u.__val = (*(volatile typeof(__x))__x); \ > } \ > - atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);\ > + *__xp = &__u.__val; \ > + *__x; \ > }) > > #endif /* !BUILD_VDSO */ > > This works because the compiler doesn't analyze alias reassignment > through pointer-to-alias within the same function. An alternative is to > do the alias reassignment via an __always_inline function that takes the > alias as a const pointer, and then cast the const away and do the > assignment. But I think the above is cleaner. Only compile-tested. Oh clever! I suppose it does help if you know how the compiler works :-) I was thinking that perhaps it makes sense to invest in a 'directive' where we can explicitly hand alias information to the compiler. Consider: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/tree/kernel/locking/rtmutex.c?h=locking/core&id=a31a1351e9ec9df7a72ea4877a8e53a9c02e8641#n1259 rtm = container_of(lock, struct rt_mutex, rtmutex); __assume_ctx_lock(&rtm->rtmutex.wait_lock); res = __ww_mutex_add_waiter(waiter, rtm, ww_ctx, wake_q); Here there is a similar issue, where container_of() wrecks things. It cannot tell that rtm->rtmutex == lock and hence its idea of lock->wait_lock gets 'confused'. I hack around it with that __assume_ctx_lock() and I suppose that works, but perhaps it makes sense to be able to tell the compiler that yes, these things are the actual same thing. Perhaps it will even improve code-gen, like in your example. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function 2026-01-23 8:55 ` Peter Zijlstra @ 2026-01-23 14:37 ` Marco Elver 0 siblings, 0 replies; 5+ messages in thread From: Marco Elver @ 2026-01-23 14:37 UTC (permalink / raw) To: Peter Zijlstra; +Cc: kernel test robot, llvm, oe-kbuild-all, Will Deacon On Fri, Jan 23, 2026 at 09:55AM +0100, Peter Zijlstra wrote: > On Thu, Jan 22, 2026 at 07:31:08PM +0100, Marco Elver wrote: > > +Cc Will > > > > On Thu, Jan 22, 2026 at 10:16AM +0100, Peter Zijlstra wrote: > > > On Thu, Jan 22, 2026 at 10:30:28AM +0800, kernel test robot wrote: > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core > > > > head: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a > > > > commit: 33d9e7fdf9c17417347d1f06ddebaf25f21ab62a [10/10] futex: Convert to compiler context analysis > > > > config: arm64-randconfig-001-20260122 (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/config) > > > > compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710) > > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260122/202601221040.TeM0ihff-lkp@intel.com/reproduce) > > > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > > > the same patch/commit), kindly add following tags > > > > | Reported-by: kernel test robot <lkp@intel.com> > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202601221040.TeM0ihff-lkp@intel.com/ > > > > > > > > All warnings (new ones prefixed by >>): > > > > > > > > >> kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function [-Wthread-safety-analysis] > > > > 982 | } > > > > | ^ > > > > kernel/futex/core.c:976:2: note: spinlock acquired here > > > > 976 | spin_lock(lock_ptr); > > > > | ^ > > > > >> kernel/futex/core.c:982:1: warning: expecting spinlock 'q->lock_ptr' to be held at the end of function [-Wthread-safety-analysis] > > > > 982 | } > > > > | ^ > > > > kernel/futex/core.c:966:6: note: spinlock acquired here > > > > 966 | void futex_q_lockptr_lock(struct futex_q *q) > > > > | ^ > > > > 2 warnings generated. > > > > > > Urgh, this is the arm64 READ_ONCE() confusing the thing. It can't see > > > through that mess and realize: lockptr == q->lock_ptr. > > > > > > Marco, any suggestion how to best fix that? > > > > I have a tentative solution: > > > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > index 78beceec10cd..75265012ff2d 100644 > > --- a/arch/arm64/include/asm/rwonce.h > > +++ b/arch/arm64/include/asm/rwonce.h > > @@ -31,9 +31,8 @@ > > */ > > #define __READ_ONCE(x) \ > > ({ \ > > - typeof(&(x)) __x = &(x); \ > > - int atomic = 1; \ > > - union { __unqual_scalar_typeof(*__x) __val; char __c[1]; } __u; \ > > + typeof(&(x)) __x = &(x), *__xp = &__x; \ > > + union { TYPEOF_UNQUAL(*__x) __val; char __c[1]; } __u; \ > > switch (sizeof(x)) { \ > > case 1: \ > > asm volatile(__LOAD_RCPC(b, %w0, %1) \ > > @@ -56,9 +55,10 @@ > > : "Q" (*__x) : "memory"); \ > > break; \ > > default: \ > > - atomic = 0; \ > > + __u.__val = (*(volatile typeof(__x))__x); \ > > } \ > > - atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);\ > > + *__xp = &__u.__val; \ > > + *__x; \ > > }) > > > > #endif /* !BUILD_VDSO */ > > > > This works because the compiler doesn't analyze alias reassignment > > through pointer-to-alias within the same function. An alternative is to > > do the alias reassignment via an __always_inline function that takes the > > alias as a const pointer, and then cast the const away and do the > > assignment. But I think the above is cleaner. Only compile-tested. > > Oh clever! I suppose it does help if you know how the compiler works :-) Latest version: diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h index 78beceec10cd..1927bfe87695 100644 --- a/arch/arm64/include/asm/rwonce.h +++ b/arch/arm64/include/asm/rwonce.h @@ -31,9 +31,8 @@ */ #define __READ_ONCE(x) \ ({ \ - typeof(&(x)) __x = &(x); \ - int atomic = 1; \ - union { __unqual_scalar_typeof(*__x) __val; char __c[1]; } __u; \ + TYPEOF_UNQUAL(x) *__x = (typeof(__x))&(x), **__xp = &__x; \ + union { typeof(*__x) __val; char __c[1]; } __u; \ switch (sizeof(x)) { \ case 1: \ asm volatile(__LOAD_RCPC(b, %w0, %1) \ @@ -56,9 +55,10 @@ : "Q" (*__x) : "memory"); \ break; \ default: \ - atomic = 0; \ + __u.__val = (*(volatile typeof(x) *)__x); \ } \ - atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);\ + *__xp = &__u.__val; \ + (typeof(x))*__x; \ }) #endif /* !BUILD_VDSO */ Because the previous one was not stripping volatile and we'd end up reading things twice. This is more annoying than I thought, maybe I'll go back to a version that produces equivalent binaries. This version seems to be strictly reducing instructions (across ~100 functions or so), but not sure why or if that's correct. > I was thinking that perhaps it makes sense to invest in a 'directive' > where we can explicitly hand alias information to the compiler. > > Consider: > > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/tree/kernel/locking/rtmutex.c?h=locking/core&id=a31a1351e9ec9df7a72ea4877a8e53a9c02e8641#n1259 > > rtm = container_of(lock, struct rt_mutex, rtmutex); > __assume_ctx_lock(&rtm->rtmutex.wait_lock); > res = __ww_mutex_add_waiter(waiter, rtm, ww_ctx, wake_q); > > Here there is a similar issue, where container_of() wrecks things. It > cannot tell that rtm->rtmutex == lock and hence its idea of > lock->wait_lock gets 'confused'. > > I hack around it with that __assume_ctx_lock() and I suppose that works, > but perhaps it makes sense to be able to tell the compiler that yes, > these things are the actual same thing. Perhaps it will even improve > code-gen, like in your example. There is __builtin_assume, but I'd refrain from using that to tell the compiler things that may not be true anymore in future. But ThreadSafetyAnalysis's alias analysis ignores all that anyway because its alias analysis is detached from the rest of the compiler. Unclear how feasible it is to add a TSA-only builtin to do that. I think in many cases we can actually use __returns_ctx_lock to create aliases, but in the container_of cases I haven't yet figured out a way to do that. ^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-01-23 14:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-22 2:30 [peterz-queue:locking/core 10/10] kernel/futex/core.c:982:1: warning: spinlock 'atomic ? __u.__val : q->lock_ptr' is still held at the end of function kernel test robot 2026-01-22 9:16 ` Peter Zijlstra 2026-01-22 18:31 ` Marco Elver 2026-01-23 8:55 ` Peter Zijlstra 2026-01-23 14:37 ` Marco Elver
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox