On top of [1].

Declaration macros that statically initialize embedded locks require static
storage when lockdep is enabled. Automatic objects must use runtime
initialization so lockdep receives a persistent class key.

For automatic local objects, lockdep cannot use the lock address as a persistent
class key and reports "INFO: trying to register non-static key" before disabling
itself.

Series [1] introduces an ASSERT_STATIC_STORAGE() macro to enforce static
duration of an object, and applies it for DEFINE_IDA() and DEFINE_MTREE().

This series applies the same mechanism for the other structures of that
sort found by Codex.

Link: https://lore.kernel.org/all/20260911221444.1523311-1-ynorov@nvidia.com/ [1]

--

[1] also describes the preferred route(s) for the material. According to
Andrew's (and mine) preferences, sending everything together in the hope
that the relevant maintainers would ack the corresponding patches or
simply take them in their trees.

Yury Norov (17):
  locking/mutex: assert static storage for DEFINE_MUTEX()
  locking/rtmutex: assert static storage for DEFINE_RT_MUTEX()
  locking/rwsem: assert static storage for semaphore definitions
  locking/semaphore: assert static storage for DEFINE_SEMAPHORE()
  locking/seqlock: assert static storage for DEFINE_SEQLOCK()
  sched: assert static storage for wait queue and completion
    declarations
  xarray: assert static storage for DEFINE_XARRAY_FLAGS()
  idr: enforce the static-storage contract of DEFINE_IDR()
  radix-tree: require static storage for RADIX_TREE()
  klist: assert static storage for DEFINE_KLIST()
  workqueue: assert static storage for work declarations
  timers: assert static storage for DEFINE_TIMER()
  kthread: assert static storage for delayed work declarations
  ratelimit: assert static storage for DEFINE_RATELIMIT_STATE()
  notifier: assert static storage for locking notifier heads
  rcu: assert static storage for RCU sync and SRCU definitions
  sysctl: assert static storage for DEFINE_CTL_TABLE_POLL()

 drivers/macintosh/ams/ams-pmu.c              |  4 +--
 drivers/net/wireguard/selftest/allowedips.c  |  4 +--
 include/linux/completion.h                   | 10 +++++--
 include/linux/idr.h                          |  4 ++-
 include/linux/klist.h                        |  4 ++-
 include/linux/kthread.h                      |  4 ++-
 include/linux/mutex.h                        |  7 +++--
 include/linux/notifier.h                     | 13 ++++++---
 include/linux/percpu-rwsem.h                 |  4 ++-
 include/linux/radix-tree.h                   |  4 ++-
 include/linux/ratelimit_types.h              |  4 ++-
 include/linux/rcu_sync.h                     |  4 ++-
 include/linux/rtmutex.h                      |  3 +-
 include/linux/rwsem.h                        |  7 +++--
 include/linux/semaphore.h                    |  4 ++-
 include/linux/seqlock.h                      |  3 +-
 include/linux/srcutiny.h                     |  4 ++-
 include/linux/srcutree.h                     |  7 +++--
 include/linux/swait.h                        |  6 ++--
 include/linux/sysctl.h                       |  4 ++-
 include/linux/timer.h                        |  4 ++-
 include/linux/wait.h                         |  7 +++--
 include/linux/workqueue.h                    | 10 +++++--
 include/linux/xarray.h                       |  3 +-
 tools/testing/memblock/linux/mutex.h         |  8 ++++--
 tools/testing/radix-tree/benchmark.c         |  4 ++-
 tools/testing/radix-tree/idr-test.c          | 29 ++++++++++++++------
 tools/testing/radix-tree/iteration_check_2.c |  4 ++-
 tools/testing/radix-tree/main.c              | 16 ++++++++---
 tools/testing/radix-tree/regression3.c       |  4 ++-
 tools/testing/radix-tree/tag_check.c         | 28 ++++++++++++++-----
 tools/testing/vma/include/dup.h              |  5 +++-
 tools/virtio/linux/compiler.h                |  9 ++++++
 tools/virtio/linux/ratelimit.h               |  6 +++-
 34 files changed, 176 insertions(+), 65 deletions(-)

-- 
2.53.0

On Mon, 14 Sep 2026 23:03:18 -0400 Yury Norov <ynorov@nvidia.com> wrote:

> Declaration macros that statically initialize embedded locks require static
> storage when lockdep is enabled. Automatic objects must use runtime
> initialization so lockdep receives a persistent class key.
> 
> For automatic local objects, lockdep cannot use the lock address as a persistent
> class key and reports "INFO: trying to register non-static key" before disabling
> itself.

So why haven't we been buried in reports about this warning coming out?

On Mon, 14 Sep 2026 23:14:18 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 14 Sep 2026 23:03:18 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> 
> > Declaration macros that statically initialize embedded locks require static
> > storage when lockdep is enabled. Automatic objects must use runtime
> > initialization so lockdep receives a persistent class key.
> > 
> > For automatic local objects, lockdep cannot use the lock address as a persistent
> > class key and reports "INFO: trying to register non-static key" before disabling
> > itself.  
> 
> So why haven't we been buried in reports about this warning coming out?
> 

Are there any code changes outside of testing?

David

On Tue, Sep 15, 2026 at 10:24:01AM +0100, David Laight wrote:
> On Mon, 14 Sep 2026 23:14:18 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Mon, 14 Sep 2026 23:03:18 -0400 Yury Norov <ynorov@nvidia.com> wrote:
> > 
> > > Declaration macros that statically initialize embedded locks require static
> > > storage when lockdep is enabled. Automatic objects must use runtime
> > > initialization so lockdep receives a persistent class key.
> > > 
> > > For automatic local objects, lockdep cannot use the lock address as a persistent
> > > class key and reports "INFO: trying to register non-static key" before disabling
> > > itself.  
> > 
> > So why haven't we been buried in reports about this warning coming out?

I have no answer. Maybe because lockdep isn't enabled by major distros...

The original report came from i386 randconfig. It looks like a combination
of some luck and a new code, probably attracting more robots attention.
 
> Are there any code changes outside of testing?

ams_pmu_set/get_register in patch #6 for example.