Thread (6 messages) 6 messages, 3 authors, 2016-06-07

Re: RT, what to do about up/down_read_non_owner()

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2016-06-06 19:24:56

On Mon, Jun 06, 2016 at 11:50:04AM +0200, Mike Galbraith wrote:
(CCs Al, who knows, maybe he'll make them go *poof*)
quoted
quoted
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help