Is this something that is expected to work? It pretty much deadlocks
during boot. I took a vmcore... the oldest RPC task (and the one that
had the RPC transport locked) was a SETATTR that was waiting on an id
mapper upcall, and the first task in the sending RPC wait queue was the
OPEN of the /sbin/request-key program.
If I disable id mapping on the NFS server then it looks like it works...
-Scott
On Thu, Oct 15, 2015 at 3:09 PM, Scott Mayhew <[email protected]> wrote:
>
> Is this something that is expected to work? It pretty much deadlocks
> during boot. I took a vmcore... the oldest RPC task (and the one that
> had the RPC transport locked) was a SETATTR that was waiting on an id
> mapper upcall, and the first task in the sending RPC wait queue was the
> OPEN of the /sbin/request-key program.
>
> If I disable id mapping on the NFS server then it looks like it works...
>
Yes, that is 100% expected behaviour. You get circular behaviour if
you try to use idmapped identities when starting the idmapper. :-)
In fact, if you look in the commit logs, you'll find that enabling
rootless NFSv4 was one of the justifications for adding the AUTH_SYS
non-idmapped mode on the client.
Cheers
Trond