* devtmpfs [censored] oddities @ 2009-12-16 8:04 Al Viro 2009-12-17 0:39 ` Greg KH 0 siblings, 1 reply; 4+ messages in thread From: Al Viro @ 2009-12-16 8:04 UTC (permalink / raw) To: linux-kernel; +Cc: Kay Sievers, Greg Kroah-Hartman May I respectfully suggest that a blocking operation (such as kstrdup with GFP_KERNEL, or grabbing a mutex, or, say it, pathname resolution) is not quite the thing to do while holding an rwlock? As it is, any device_add() is an embarrassingly obvious deadlock waiting to happen... ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: devtmpfs [censored] oddities 2009-12-16 8:04 devtmpfs [censored] oddities Al Viro @ 2009-12-17 0:39 ` Greg KH 2009-12-17 0:46 ` Al Viro 0 siblings, 1 reply; 4+ messages in thread From: Greg KH @ 2009-12-17 0:39 UTC (permalink / raw) To: Al Viro; +Cc: linux-kernel, Kay Sievers On Wed, Dec 16, 2009 at 08:04:31AM +0000, Al Viro wrote: > May I respectfully suggest that a blocking operation (such as > kstrdup with GFP_KERNEL, or grabbing a mutex, or, say it, pathname resolution) > is not quite the thing to do while holding an rwlock? > > As it is, any device_add() is an embarrassingly obvious deadlock > waiting to happen... Thomas has posted a patch to fix this now. Sorry for not catching it sooner, we should just delete the rwlocks so no one tries to ever use it again. thanks, greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: devtmpfs [censored] oddities 2009-12-17 0:39 ` Greg KH @ 2009-12-17 0:46 ` Al Viro 2009-12-17 1:00 ` Greg KH 0 siblings, 1 reply; 4+ messages in thread From: Al Viro @ 2009-12-17 0:46 UTC (permalink / raw) To: Greg KH; +Cc: linux-kernel, Kay Sievers On Wed, Dec 16, 2009 at 04:39:22PM -0800, Greg KH wrote: > On Wed, Dec 16, 2009 at 08:04:31AM +0000, Al Viro wrote: > > May I respectfully suggest that a blocking operation (such as > > kstrdup with GFP_KERNEL, or grabbing a mutex, or, say it, pathname resolution) > > is not quite the thing to do while holding an rwlock? > > > > As it is, any device_add() is an embarrassingly obvious deadlock > > waiting to happen... > > Thomas has posted a patch to fix this now. > > Sorry for not catching it sooner, we should just delete the rwlocks so > no one tries to ever use it again. Say again? Why would we delete rwlocks? -- If you stare into drivers/staging long enough, drivers/staging stares back at you... ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: devtmpfs [censored] oddities 2009-12-17 0:46 ` Al Viro @ 2009-12-17 1:00 ` Greg KH 0 siblings, 0 replies; 4+ messages in thread From: Greg KH @ 2009-12-17 1:00 UTC (permalink / raw) To: Al Viro; +Cc: linux-kernel, Kay Sievers On Thu, Dec 17, 2009 at 12:46:43AM +0000, Al Viro wrote: > On Wed, Dec 16, 2009 at 04:39:22PM -0800, Greg KH wrote: > > On Wed, Dec 16, 2009 at 08:04:31AM +0000, Al Viro wrote: > > > May I respectfully suggest that a blocking operation (such as > > > kstrdup with GFP_KERNEL, or grabbing a mutex, or, say it, pathname resolution) > > > is not quite the thing to do while holding an rwlock? > > > > > > As it is, any device_add() is an embarrassingly obvious deadlock > > > waiting to happen... > > > > Thomas has posted a patch to fix this now. > > > > Sorry for not catching it sooner, we should just delete the rwlocks so > > no one tries to ever use it again. > > Say again? Why would we delete rwlocks? Sorry, no _new_ use of rwlocks should be added, generally they are used incorrectly, like this one was. thanks, greg k-h ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-12-17 1:01 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-16 8:04 devtmpfs [censored] oddities Al Viro 2009-12-17 0:39 ` Greg KH 2009-12-17 0:46 ` Al Viro 2009-12-17 1:00 ` Greg KH
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.