lkml.org 
[lkml]   [2019]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 3/3] drm/i915: use might_lock_nested in get_pages annotation
    Date
    So strictly speaking the existing annotation is also ok, because we
    have a chain of

    obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock

    (the shrinker cannot get at an object while we're in get_pages, hence
    this is safe). But it's confusing, so try to take the right subclass
    of the lock.

    This does a bit reduce our lockdep based checking, but then it's also
    less fragile, in case we ever change the nesting around.

    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: linux-kernel@vger.kernel.org
    ---
    drivers/gpu/drm/i915/gem/i915_gem_object.h | 34 +++++++++++-----------
    1 file changed, 17 insertions(+), 17 deletions(-)

    diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h
    index a0b1fa8a3224..b3fd6aac93bc 100644
    --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
    +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
    @@ -233,10 +233,26 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
    int ____i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
    int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);

    +enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
    + I915_MM_NORMAL = 0,
    + /*
    + * Only used by struct_mutex, when called "recursively" from
    + * direct-reclaim-esque. Safe because there is only every one
    + * struct_mutex in the entire system. */
    + I915_MM_SHRINKER = 1,
    + /*
    + * Used for obj->mm.lock when allocating pages. Safe because the object
    + * isn't yet on any LRU, and therefore the shrinker can't deadlock on
    + * it. As soon as the object has pages, obj->mm.lock nests within
    + * fs_reclaim.
    + */
    + I915_MM_GET_PAGES = 1,
    +};
    +
    static inline int __must_check
    i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
    {
    - might_lock(&obj->mm.lock);
    + might_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES);

    if (atomic_inc_not_zero(&obj->mm.pages_pin_count))
    return 0;
    @@ -279,22 +295,6 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
    __i915_gem_object_unpin_pages(obj);
    }

    -enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
    - I915_MM_NORMAL = 0,
    - /*
    - * Only used by struct_mutex, when called "recursively" from
    - * direct-reclaim-esque. Safe because there is only every one
    - * struct_mutex in the entire system. */
    - I915_MM_SHRINKER = 1,
    - /*
    - * Used for obj->mm.lock when allocating pages. Safe because the object
    - * isn't yet on any LRU, and therefore the shrinker can't deadlock on
    - * it. As soon as the object has pages, obj->mm.lock nests within
    - * fs_reclaim.
    - */
    - I915_MM_GET_PAGES = 1,
    -};
    -
    int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
    void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
    void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
    --
    2.23.0.rc1
    \
     
     \ /
      Last update: 2019-08-20 10:23    [W:4.204 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site