Re: [PATCH locking 00/11] LOCKDEP and Rust locking changes for v6.15

[Ingo Molnar]

* Boqun Feng <boqun.feng@xxxxxxxxx> wrote:

> On Sat, Mar 08, 2025 at 01:01:45AM +0100, Ingo Molnar wrote:
> > 
> > * Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
> > 
> > > Hi Ingo & Peter,
> > > 
> > > As discussed, I'm resending the pull request for lockdep and Rust
> > > locking for v6.15 in the format of email patches. I dropped one patch
> > > and will postpone it for v6.16 because of a bug [1], and I think the fix
> > > [2] needs more reviews.
> > > 
> > > [1]: https://lore.kernel.org/lkml/20250306122413.GBZ8mT7Z61Tmgnh5Y9@fat_crate.local/
> > > [2]: https://lore.kernel.org/lkml/Z8t8imzJVhWyDvhC@boqun-archlinux/
> > > 
> > > Regards,
> > > Boqun
> > > 
> > > Alice Ryhl (2):
> > >   rust: sync: Add accessor for the lock behind a given guard
> > >   rust: sync: condvar: Add wait_interruptible_freezable()
> > > 
> > > Boqun Feng (1):
> > >   rust: sync: lock: Add an example for Guard::lock_ref()
> > > 
> > > Mitchell Levy (2):
> > >   rust: lockdep: Remove support for dynamically allocated LockClassKeys
> > >   rust: lockdep: Use Pin for all LockClassKey usages
> > > 
> > > Randy Dunlap (1):
> > >   locking/rtmutex: Use struct keyword in kernel-doc comment
> > > 
> > > Waiman Long (5):
> > >   locking/semaphore: Use wake_q to wake up processes outside lock
> > >     critical section
> > >   locking/lock_events: Add locking events for rtmutex slow paths
> > >   locking/lock_events: Add locking events for lockdep
> > >   locking/lockdep: Disable KASAN instrumentation of lockdep.c
> > >   locking/lockdep: Add kasan_check_byte() check in lock_acquire()
> > 
> > Thanks Boqun!
> > 
> 
> Thanks.
> 
> > I've applied these 3 patches to the tip:locking/urgent tree:
> > 
> >   locking/semaphore: Use wake_q to wake up processes outside lock critical section
> >   locking/rtmutex: Use the 'struct' keyword in kernel-doc comment
> >   rust: lockdep: Remove support for dynamically allocated LockClassKeys
> > 
> > As a general rule, if a patch is marked Cc: stable, it must also be 
> > applied to current upstream.
> > 
> 
> Do you prefer a separate pull request for the future? I can send one for
> urgent and one for locking/core.

One tree is fine - maybe indicate which ones are urgent material and 
keep them at the head of the tree?

Thanks,

	Ingo