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()

 kernel/locking/Makefile           |  3 +-
 kernel/locking/lock_events_list.h | 28 ++++++++++++++
 kernel/locking/lockdep.c          | 17 ++++++++-
 kernel/locking/rtmutex.c          | 29 +++++++++++---
 kernel/locking/rtmutex_common.h   |  4 +-
 kernel/locking/semaphore.c        | 13 +++++--
 rust/helpers/helpers.c            |  1 +
 rust/helpers/sync.c               | 13 +++++++
 rust/kernel/sync.rs               | 63 ++++++++++++++++++++++++++-----
 rust/kernel/sync/condvar.rs       | 28 ++++++++++++--
 rust/kernel/sync/lock.rs          | 35 +++++++++++++++--
 rust/kernel/sync/lock/global.rs   |  5 ++-
 rust/kernel/sync/poll.rs          |  2 +-
 rust/kernel/task.rs               |  2 +
 rust/kernel/workqueue.rs          |  2 +-
 15 files changed, 211 insertions(+), 34 deletions(-)
 create mode 100644 rust/helpers/sync.c

-- 
2.47.1

* Boqun Feng <boqun.feng@gmail.com> 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!

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.

I have applied the others to tip:locking/core:

  locking/lock_events: Add locking events for rtmutex slow pathsa94d32446ab5 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()
  rust: sync: Add accessor for the lock behind a given guard
  rust: sync: lock: Add an example for Guard:: Lock_ref()
  rust: sync: condvar: Add wait_interruptible_freezable()
  rust: lockdep: Use Pin for all LockClassKey usages

I cleaned up changelogs where necessary - for example we generally 
don't include printk timestamps in changelogs, unless it's relevant, 
plus there were a number of typos and grammar mistakes left in some of 
the changelogs.

Thanks,

	Ingo

On Sat, Mar 08, 2025 at 01:01:45AM +0100, Ingo Molnar wrote:
> 
> * Boqun Feng <boqun.feng@gmail.com> 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.

> I have applied the others to tip:locking/core:
> 
>   locking/lock_events: Add locking events for rtmutex slow pathsa94d32446ab5 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()
>   rust: sync: Add accessor for the lock behind a given guard
>   rust: sync: lock: Add an example for Guard:: Lock_ref()
>   rust: sync: condvar: Add wait_interruptible_freezable()
>   rust: lockdep: Use Pin for all LockClassKey usages
> 
> I cleaned up changelogs where necessary - for example we generally 
> don't include printk timestamps in changelogs, unless it's relevant, 

Got it, I will avoid them in the future.

> plus there were a number of typos and grammar mistakes left in some of 
> the changelogs.
> 

Will take a look at your updates and keep working on improve them,
thanks!

Regards,
Boqun

> Thanks,
> 
> 	Ingo

* Boqun Feng <boqun.feng@gmail.com> wrote:

> On Sat, Mar 08, 2025 at 01:01:45AM +0100, Ingo Molnar wrote:
> > 
> > * Boqun Feng <boqun.feng@gmail.com> 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

On Sat, Mar 08, 2025 at 01:11:36AM +0100, Ingo Molnar wrote:
[...]
> > > 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?
> 

Sounds good to me, will do.

Regards,
Boqun

> Thanks,
> 
> 	Ingo