RE: EACCES errors using preload libs

["Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

> On Fri, Sep 30, 2016 at 12:43:02PM -0500, Steve Wise wrote:
> 
> > The single case I see failing so far is trying to preload my library
with
> > netserver.  If I run netserver with '-D -f' which avoids fork() calls,
it
> > works fine.  If I omit the -f, then the forked process gets an EACCES
error
> > trying to do ibv_query_device().  Thoughts?
> 
> Hum, so I expect the patch to break things. Specifically if you change
> the process credentials after opening verbs. However just forking()
> shouldn't cause a problem. Can you confirm there is nothing that
> changes uid,gid, etc during the fork?
> 

I'll debug this further, but this is running as root, so that sort of stuff
shouldn't be changing.

> Unfortunately it was designed by Linus and Andy to work this way, so
> we cannot weaken the check.
>

Sure.
 
> I don't know how your preload library works, but after fork basically
> everything related to verbs is garbage - so it should be safe to
> close/reopen then uverbs fd which will avoid the problem. It is only
> because the FD was passed across a credential change that you got
> EACCESS.
>

Fork() is actually not supported by this preload library, but we were
getting by, I guess, with netserver because it fork()s before it allocates
the UDP socket that then gets accelerated by the preload lib.  However, I'm
thinking that librdacm is getting invoked and is opening contexts to all the
verbs devices before the fork() and thus after it, this new "safe" check it
biting me.   

> The way forward to restore the lost functionality is to rework the
> entire uAPI to use ioctl, which is what Matan/Sean/etc have been
> doing. 

Right, I'm ok with waiting for this (and helping as I can, but I've been
very quiet to date :) ).

Thanks Jason, 

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html