Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751371Ab3IJTNZ (ORCPT ); Tue, 10 Sep 2013 15:13:25 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:58320 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751028Ab3IJTNX (ORCPT ); Tue, 10 Sep 2013 15:13:23 -0400 Date: Tue, 10 Sep 2013 20:13:19 +0100 From: Al Viro To: Linus Torvalds Cc: Josh Boyer , Waiman Long , "Linux-Kernel@Vger. Kernel. Org" , Mace Moneta Subject: Re: kernel BUG at fs/dcache.c:648! with v3.11-7890-ge5c832d Message-ID: <20130910191319.GZ13318@ZenIV.linux.org.uk> References: <20130910184324.GY13318@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1882 Lines: 36 On Tue, Sep 10, 2013 at 12:01:22PM -0700, Linus Torvalds wrote: > On Tue, Sep 10, 2013 at 11:43 AM, Al Viro wrote: > > > > !LOOKUP_ROOT: we set nd->root the first time we need / (in the very > > beginning if it's an absolute pathname, on the first absolute symlink > > otherwise). In non-RCU mode we hold a reference to it; in RCU mode > > we do not. As the result, leaving RCU mode should either grab > > a reference to the damn thing (if we intend to go on) or zero it out. > > Yeah, that was what I was thinking. But in particular, I was wondering > if we could simplify unlazy_walk() to _not_ take that root reference > at all, and just always zero it out even if we succeed. > > IOW, doing the attached patch (_instead_ of the one I sent out). > > Or is there something in path lookup retrying that might get uphappy > if we go back to a NULL root.mnt, and doesn't check it? Ugh... I really don't like that - your patch introduces the situations when race with chroot can lead to two absolute symlinks in the same path being interpreted wrt different roots. And yes, sure, anybody who gets in that kind of races isn't going to get particulary sane results, but still, I'd rather have simpler semantics here... Anyway, I think I see how to tidy the things up in a different way; let's go with your original fix for now and deal with the cleanups a bit later. Another thing: could you merge vfs.git#for-linus? It's getting really messy to keep track of changes both in mainline and in vfs.git, especially since there's a pile of pending stuff (lru_list work) that needs to be resolved wrt both... -- 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/