Hey,
I'm pretty sure I've seen this use-after-free in the wild, just never found the
root cause since it's so unlikely to trigger on demand.
Acked-by: Maarten Lankhorst
Den 2024-10-02 kl. 14:56, skrev Thomas Hellström:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
>
On Wed, 2024-10-09 at 15:42 +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed
> "WARNING:at_kernel/locking/lockdep.c:#__lock_acquire" on:
>
> commit: d417c66b8b12b5706c9df4ddf5367af540f195c6 ("[PATCH RESEND]
> locking/ww_mutex
Hello,
kernel test robot noticed "WARNING:at_kernel/locking/lockdep.c:#__lock_acquire"
on:
commit: d417c66b8b12b5706c9df4ddf5367af540f195c6 ("[PATCH RESEND]
locking/ww_mutex: Adjust to lockdep nest_lock requirements")
url:
https://github.com/intel-lab-lkp/linux/comm
On Fri, 2024-10-04 at 12:16 +0200, Peter Zijlstra wrote:
> On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellström wrote:
> > When using mutex_acquire_nest() with a nest_lock, lockdep refcounts
> > the
> > number of acquired lockdep_maps of mutexes of the same class, and
> > also
> > keeps a poi
On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellström wrote:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
> number of acquired lockdep_maps of mutexes of the same class, and also
> keeps a pointer to the first acquired lockdep_map of a class. That pointer
> is then
When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
number of acquired lockdep_maps of mutexes of the same class, and also
keeps a pointer to the first acquired lockdep_map of a class. That pointer
is then used for various comparison-, printing- and checking purposes,
but there
