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:

quoted

(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?

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