* RT, what to do about up/down_read_non_owner()
@ 2016-06-05 6:57 Mike Galbraith
2016-06-06 7:49 ` Sebastian Andrzej Siewior
0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2016-06-05 6:57 UTC (permalink / raw)
To: linux-rt-users; +Cc: Sebastian Andrzej Siewior, Thomas Gleixner, Steven Rostedt
Greetings,
In v4.7, Al added those buggers to NFS. BCACHE is disabled in RT
because of same.. but that's a somewhat suboptimal solution for
something as widely used as NFS.
Suggestions? I reverted the offending commit to get 4.7-rt up and
running, but that's not gonna fly long term.
-Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RT, what to do about up/down_read_non_owner()
2016-06-05 6:57 RT, what to do about up/down_read_non_owner() Mike Galbraith
@ 2016-06-06 7:49 ` Sebastian Andrzej Siewior
2016-06-06 9:07 ` Mike Galbraith
0 siblings, 1 reply; 6+ messages in thread
From: Sebastian Andrzej Siewior @ 2016-06-06 7:49 UTC (permalink / raw)
To: Mike Galbraith, linux-rt-users
Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar
On 06/05/2016 08:57 AM, Mike Galbraith wrote:
> Greetings,
>
> In v4.7, Al added those buggers to NFS. BCACHE is disabled in RT
> because of same.. but that's a somewhat suboptimal solution for
> something as widely used as NFS.
>
> Suggestions? I reverted the offending commit to get 4.7-rt up and
> running, but that's not gonna fly long term.
This API should be avoided according to the comment and completions
should be used. I am for removal of those. Were the locking people okay
with this change in the first place or did this just sneak in?
>
> -Mike
>
Sebastian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RT, what to do about up/down_read_non_owner()
2016-06-06 7:49 ` Sebastian Andrzej Siewior
@ 2016-06-06 9:07 ` Mike Galbraith
2016-06-06 9:50 ` Mike Galbraith
0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2016-06-06 9:07 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-rt-users
Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar
On Mon, 2016-06-06 at 09:49 +0200, Sebastian Andrzej Siewior wrote:
> On 06/05/2016 08:57 AM, Mike Galbraith wrote:
> > Greetings,
> >
> > In v4.7, Al added those buggers to NFS. BCACHE is disabled in RT
> > because of same.. but that's a somewhat suboptimal solution for
> > something as widely used as NFS.
> >
> > Suggestions? I reverted the offending commit to get 4.7-rt up and
> > running, but that's not gonna fly long term.
>
> This API should be avoided according to the comment and completions
> should be used. I am for removal of those. Were the locking people okay
> with this change in the first place or did this just sneak in?
It just snuck in. Al reworked sillyunlink, whacking the wait_event()
stuff that was there, using annoying $subject instead.
-Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RT, what to do about up/down_read_non_owner()
2016-06-06 9:07 ` Mike Galbraith
@ 2016-06-06 9:50 ` Mike Galbraith
2016-06-06 19:24 ` Al Viro
0 siblings, 1 reply; 6+ messages in thread
From: Mike Galbraith @ 2016-06-06 9:50 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-rt-users
Cc: Thomas Gleixner, Peter Zijlstra, Ingo Molnar, Al Viro
(CCs Al, who knows, maybe he'll make them go *poof*)
On Mon, 2016-06-06 at 11:07 +0200, Mike Galbraith wrote:
> On Mon, 2016-06-06 at 09:49 +0200, Sebastian Andrzej Siewior wrote:
> > On 06/05/2016 08:57 AM, Mike Galbraith wrote:
> > > Greetings,
> > >
> > > In v4.7, Al added those buggers to NFS. BCACHE is disabled in RT
> > > because of same.. but that's a somewhat suboptimal solution for
> > > something as widely used as NFS.
> > >
> > > Suggestions? I reverted the offending commit to get 4.7-rt up and
> > > running, but that's not gonna fly long term.
> >
> > This API should be avoided according to the comment and completions
> > should be used. I am for removal of those. Were the locking people okay
> > with this change in the first place or did this just sneak in?
>
> It just snuck in. Al reworked sillyunlink, whacking the wait_event()
> stuff that was there, using annoying $subject instead.
>
> > -Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RT, what to do about up/down_read_non_owner()
2016-06-06 9:50 ` Mike Galbraith
@ 2016-06-06 19:24 ` Al Viro
2016-06-07 2:39 ` Mike Galbraith
0 siblings, 1 reply; 6+ messages in thread
From: Al Viro @ 2016-06-06 19:24 UTC (permalink / raw)
To: Mike Galbraith
Cc: Sebastian Andrzej Siewior, linux-rt-users, Thomas Gleixner,
Peter Zijlstra, Ingo Molnar
On Mon, Jun 06, 2016 at 11:50:04AM +0200, Mike Galbraith wrote:
> (CCs Al, who knows, maybe he'll make them go *poof*)
>
> > > > In v4.7, Al added those buggers to NFS. BCACHE is disabled in RT
> > > > because of same.. but that's a somewhat suboptimal solution for
> > > > something as widely used as NFS.
> > > >
> > > > Suggestions? I reverted the offending commit to get 4.7-rt up and
> > > > running, but that's not gonna fly long term.
> > >
> > > This API should be avoided according to the comment and completions
> > > should be used. I am for removal of those. Were the locking people okay
> > > with this change in the first place or did this just sneak in?
> >
> > It just snuck in. Al reworked sillyunlink, whacking the wait_event()
> > stuff that was there, using annoying $subject instead.
It's more than just wait_event() crap being killed (and crap it certainly
was). The situation is pretty much the same as with bcache; we don't want
readers to stick around until the initiated action has been completed.
What exactly is RT problem, just to be sure to avoid reproducing exact same
issue in the replacement?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RT, what to do about up/down_read_non_owner()
2016-06-06 19:24 ` Al Viro
@ 2016-06-07 2:39 ` Mike Galbraith
0 siblings, 0 replies; 6+ messages in thread
From: Mike Galbraith @ 2016-06-07 2:39 UTC (permalink / raw)
To: Al Viro
Cc: Sebastian Andrzej Siewior, linux-rt-users, Thomas Gleixner,
Peter Zijlstra, Ingo Molnar
On Mon, 2016-06-06 at 20:24 +0100, Al Viro wrote:
> On Mon, Jun 06, 2016 at 11:50:04AM +0200, Mike Galbraith wrote:
> > (CCs Al, who knows, maybe he'll make them go *poof*)
> >
> > > > > In v4.7, Al added those buggers to NFS. BCACHE is disabled in RT
> > > > > because of same.. but that's a somewhat suboptimal solution for
> > > > > something as widely used as NFS.
> > > > >
> > > > > Suggestions? I reverted the offending commit to get 4.7-rt up and
> > > > > running, but that's not gonna fly long term.
> > > >
> > > > This API should be avoided according to the comment and completions
> > > > should be used. I am for removal of those. Were the locking people okay
> > > > with this change in the first place or did this just sneak in?
> > >
> > > It just snuck in. Al reworked sillyunlink, whacking the wait_event()
> > > stuff that was there, using annoying $subject instead.
>
> It's more than just wait_event() crap being killed (and crap it certainly
> was). The situation is pretty much the same as with bcache; we don't want
> readers to stick around until the initiated action has been completed.
>
> What exactly is RT problem, just to be sure to avoid reproducing exact same
> issue in the replacement?
These primitives take a lock class that's wired for PI, and break it.
What RT used to do about that was to create a whole new lock type, and
inject it into the tree wherever non_owner was used. When non_owner
was killed, RT maintainers happily trashed that workaround.. but then
bcache came along and brought the damn things back from the grave.
-Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-06-07 2:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-05 6:57 RT, what to do about up/down_read_non_owner() Mike Galbraith
2016-06-06 7:49 ` Sebastian Andrzej Siewior
2016-06-06 9:07 ` Mike Galbraith
2016-06-06 9:50 ` Mike Galbraith
2016-06-06 19:24 ` Al Viro
2016-06-07 2:39 ` Mike Galbraith
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).