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 pointer to the first acquired lockdep_map of a class. That > > pointer > > is then used for various comparison-, printing- and checking > > purposes, > > but there is no mechanism to actively ensure that lockdep_map stays > > in > > memory. Instead, a warning is printed if the lockdep_map is freed > > and > > there are still held locks of the same lock class, even if the > > lockdep_map > > itself has been released. > > > > In the context of WW/WD transactions that means that if a user > > unlocks > > and frees a ww_mutex from within an ongoing ww transaction, and > > that > > mutex happens to be the first ww_mutex grabbed in the transaction, > > such a warning is printed and there might be a risk of a UAF. > > I'm assuming you actually hit this? Yes, but there was a change merged to drm_exec, a main ww_mutex user that makes it less likely to happen. (Unlocking in reverse unless the user explicitly requests an unlock which will be a more common use-case moving forward). > > Anyway, work around seems sane enough, thanks! Thanks, Thomas
