✓ CI.checkpatch: success for locking/ww_mutex: Adjust to lockdep nest_lock requirements (rev3)

[Patchwork]

== Series Details ==

Series: locking/ww_mutex: Adjust to lockdep nest_lock requirements (rev3)
URL   : https://patchwork.freedesktop.org/series/123522/
State : success

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
30ab6715fc09baee6cc14cb3c89ad8858688d474
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 8f349d9fe3e7d3a068d641dd721b51d7cba4b7ad
Author: Thomas Hellström <thomas.hellstrom at linux.intel.com>
Date:   Wed Oct 2 14:56:11 2024 +0200

    locking/ww_mutex: Adjust to lockdep nest_lock requirements
    
    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.
    
    Note that this is only problem when lockdep is enabled and affects only
    dereferences of struct lockdep_map.
    
    Adjust to this by adding a fake lockdep_map to the acquired context and
    make sure it is the first acquired lockdep map of the associated
    ww_mutex class. Then hold it for the duration of the WW/WD transaction.
    
    This has the side effect that trying to lock a ww mutex *without* a
    ww_acquire_context but where a such context has been acquire, we'd see
    a lockdep splat. The test-ww_mutex.c selftest attempts to do that, so
    modify that particular test to not acquire a ww_acquire_context if it
    is not going to be used.
    
    Cc: Peter Zijlstra <peterz at infradead.org>
    Cc: Ingo Molnar <mingo at redhat.com>
    Cc: Will Deacon <will at kernel.org>
    Cc: Waiman Long <longman at redhat.com>
    Cc: Boqun Feng <boqun.feng at gmail.com>
    Cc: Maarten Lankhorst <maarten at lankhorst.se>
    Cc: Christian König <christian.koenig at amd.com>
    Cc: dri-devel at lists.freedesktop.org
    Cc: linux-kernel at vger.kernel.org
    Signed-off-by: Thomas Hellström <thomas.hellstrom at linux.intel.com>
+ /mt/dim checkpatch d91e474f9dd2c29e4927c2b2ddbe28a313bf593f drm-intel
8f349d9fe3e7 locking/ww_mutex: Adjust to lockdep nest_lock requirements