On Tue, 18 Aug 2009 09:17:23 -0700 Jesse Barnes <jbar...@virtuousgeek.org> wrote: > > >> Exactly what in the generic modesetting code is protected by the > > >> struct mutex here? > > >> > > > > > > I'm a little fuzzy on the details, this part of the patch was > > > carried over from Jesse's original work. I believe set_base is > > > supposed to be called with the struct mutex held. > > > > > > > > > > We shouldn't be this sloppy about locking, and in particular we > > shouldn't protect a callback with a lock without knowing why. A > > lock should protect data, not serialize calls to functions, and it > > should ideally be documented somewhere. Why does set_base need the > > _caller_ to take the struct_mutex lock? Are there more driver > > callbacks that need the struct_mutex held? > > Yes; set_base is called from several places. The struct_mutex protect > all the mode setting related fields & lists, so if we're going to > change the fb (or any other setting) we need to hold it. Pushing the > locking for it out to callers was necessary because in the flip ioctl, > we already hold the lock. And we don't want to drop it and re-acquire > since that opens up a big window where the config could change out > from under us.
As Dave noted though I had the locks mixed up. We need the mode config mutex here... Looks like I "fixed" a non-existent deadlock by pushing the lock out! -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
