On 12 Jun 2013, Al Viro outgrape: > On Wed, Jun 12, 2013 at 01:08:26PM +0100, Nix wrote: > >> At this point, we have a sibcall to call_connect() I think. The RPC task >> of discourse happens to be local, and as the relevant comment says >> >> * We want the AF_LOCAL connect to be resolved in the >> * filesystem namespace of the process making the rpc >> * call. Thus we connect synchronously. >> >> Probably this should be doing this only if said namespace isn't >> disconnected and going away... > > Namespace, shnamespace... In this case the namespace is alive and well, > it's just that the process is getting killed and it's already past the > point where it has discarded all references to root/cwd. Yeah. >> > Why is it done in essentially random process context, anyway? There's such thing >> > as chroot, after all, which would screw that sucker as hard as NULL ->fs, but in >> > a less visible way... >> >> I don't think it is a random process context. It's all intentionally >> done in the context of the process which is the last to close that >> filesystem, as part of the process of tearing it down -- but it looks >> like the NFS svcrpc connection code isn't expecting to be called in that >> situation. > > _What_? Suppose we have something mounted on /jail/net/foo/bar; will the > effect of process chrooted into /jail doing umount /net/foo/bar be different > from that of process outside of the jail doing umount /jail/net/foo/bar? Correction: that comment suggests that it was intentionally done. I didn't write the comment and I make no judgement on whether it makes sense or not (it looks like it would *normally* make sense, but I guess nobody thought of the case of a connection being done as part of disconnection after the cwd is gone). I'm just the guy getting bitten by the resulting oops :) -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
