* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).