RT, what to do about up/down_read_non_owner()
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
Quoted 8 lines · Mike Galbraith
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?
Quoted 3 lines
-Mike
Sebastian
Quoted 7 lines · Sebastian Andrzej Siewior
Quoted 6 lines · Mike Galbraith
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.
Quoted 6 lines
Quoted 2 lines
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
(CCs Al, who knows, maybe he'll make them go *poof*)
Quoted 19 lines · Mike Galbraith
Quoted 7 lines · Sebastian Andrzej Siewior
Quoted 6 lines · Mike Galbraith
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.
Quoted 6 lines
Quoted 2 lines
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
Quoted 15 lines · Mike Galbraith
(CCs Al, who knows, maybe he'll make them go *poof*)
Quoted 13 lines
Quoted 10 lines
Quoted 6 lines
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?
Quoted 17 lines · Al Viro
Quoted 15 lines · Mike Galbraith
(CCs Al, who knows, maybe he'll make them go *poof*)
Quoted 13 lines
Quoted 10 lines
Quoted 6 lines
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.
Quoted 6 lines
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