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

[Patchwork]

== Series Details ==

Series: locking/ww_mutex: Adjust to lockdep nest_lock requirements (rev2)
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
6030b24c1386b00de8187b5fb987e283a57b372a
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit c727a02bef6811a5d81f0705b52e11ed2fc5be87
Author: Thomas Hellström <thomas.hellstrom at linux.intel.com>
Date:   Tue Dec 19 17:05:24 2023 +0100

    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 974cd401b8e534a6275fb4d2c0db6aea440508a6 drm-intel
c727a02be locking/ww_mutex: Adjust to lockdep nest_lock requirements