linux-kernel - Re: NFS/lazy-umount/path-lookup-related panics at shutdown (at kill of processes on lazy-umounted filesystems) with 3.9.2 and 3.9.5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130612155419.GG4165@ZenIV.linux.org.uk>
Date:	Wed, 12 Jun 2013 16:54:19 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Nix <nix@...eri.org.uk>
Cc:	linux-kernel@...r.kernel.org, NFS list <linux-nfs@...r.kernel.org>
Subject: Re: NFS/lazy-umount/path-lookup-related panics at shutdown (at kill
 of processes on lazy-umounted filesystems) with 3.9.2 and 3.9.5

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.

> > 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/