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

[Mike Galbraith <umgwanakikbuti@gmail.com>]

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