[Intel-gfx] [PATCH 08/35] drm: Protect dev->filelist with its own mutex

[Daniel Vetter]

On Tue, Apr 26, 2016 at 05:45:44PM -0400, Alex Deucher wrote:
> On Tue, Apr 26, 2016 at 4:52 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Tue, Apr 26, 2016 at 07:29:41PM +0200, Daniel Vetter wrote:
> >> amdgpu gained dev->struct_mutex usage, and that's because it's walking
> >> the dev->filelist list. Protect that list with it's own lock to take
> >> one more step towards getting rid of struct_mutex usage in drivers
> >> once and for all.
> >>
> >> While doing the conversion I noticed that 2 debugfs files in i915
> >> completely lacked appropriate locking. Fix that up too.
> >>
> >> v2: don't forget to switch to drm_gem_object_unreference_unlocked.
> >>
> >> Cc: Alex Deucher <alexander.deucher at amd.com>
> >> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> >
> > Just wondering if this worth converting over. Opening/closing isn't
> > going to be high contention, I hope, though we can certainly write
> > stress cases for it! The goal for drivers to stop using the struct_mutex
> > as their BKL, which doesn't preclude keeping the struct_mutex around for
> > where it makes sense to have a single mutex rather than a multitude.
> >
> > I have some misgivings over this, but only because I think its overkill.
> > Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> I agree with Chris' sentiments.

It's not to have more speed or less contention, but just to have fewer
things to worry about when reviewing locking. Hence orthogonal locks for
independent parts.

My goal is that in the end dev->struct_mutex is only used by some existing
drivers for their internals, plus all the legacy core stuff. And never
even used by modern drivers. New locks are pretty cheap, and not dragging
in the entire legacy horror show has benefits.

When/once I tackle the one thing left (master locking) I might move the
master handling under this lock too (since it's closely related to open
files). Not sure yet.
-Daniel

> Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch