Re: [PATCH 00/18] dev->struct_mutex crusade

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 09, 2015 at 11:32:32PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> I wanted to take another look at struct_mutex usage in modern (gem) drivers and
> noticed that for a fair lot we're very to be completely struct_mutex free.
> 
> This pile here is the the simple part, which mostly just removes code and
> mutex_lock/unlock calls. All the patches here are independent and can be merged
> in any order whatsoever. My plan is to send out a pull request for all those not
> picked up by driver maintainers in 2-3 weeks or so, assuming no one complains.
> 
> Of course review & comments still very much welcome.
> 
> The more tricky 2nd part of this (and that one's not yet done) is to rework the
> gem mmap handler to use the same kref_get_unless_zero trick as ttm. With that
> there's no core requirement to hold struct_mutex over the final unref, which
> means we can make that one lockless. I plan to add a gem_object_free_unlocked
> for all the drivers which don't have any need for this lock.
> 
> Also there's a few more drivers which can be made struct_mutex free easily, I'll
> propably stitch together poc patches for those.

There's a concurrency bug in Tegra DRM currently because we don't lock
accesses to drm_mm (I guess this demonstrates how badly we need better
testing...) and it seems like this is typically protected by the very
same struct_mutex that you're on a crusade to remove. If your goal is
to get rid of it for good, should we simply add a separate lock just
for the drm_mm? We don't have another one that would fit.

Thierry

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux