Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758080Ab3FLV1G (ORCPT ); Wed, 12 Jun 2013 17:27:06 -0400 Received: from icebox.esperi.org.uk ([81.187.191.129]:39187 "EHLO mail.esperi.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751890Ab3FLV1F (ORCPT ); Wed, 12 Jun 2013 17:27:05 -0400 From: Nix To: Al Viro Cc: linux-kernel@vger.kernel.org, NFS list 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 References: <871u89vp46.fsf@spindle.srvr.nix> <20130612012304.GF4165@ZenIV.linux.org.uk> <87k3lzpm4l.fsf@spindle.srvr.nix> <20130612155419.GG4165@ZenIV.linux.org.uk> Emacs: don't cry -- it won't help. Date: Wed, 12 Jun 2013 22:27:01 +0100 In-Reply-To: <20130612155419.GG4165@ZenIV.linux.org.uk> (Al Viro's message of "Wed, 12 Jun 2013 16:54:19 +0100") Message-ID: <877ghzow9m.fsf@spindle.srvr.nix> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DCC-INFN-TO-Metrics: spindle 1233; Body=3 Fuz1=3 Fuz2=3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2105 Lines: 49 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/