Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757508AbYFBF4D (ORCPT ); Mon, 2 Jun 2008 01:56:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752144AbYFBFzv (ORCPT ); Mon, 2 Jun 2008 01:55:51 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:33463 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116AbYFBFzu (ORCPT ); Mon, 2 Jun 2008 01:55:50 -0400 Date: Mon, 2 Jun 2008 01:55:48 -0400 From: Christoph Hellwig To: Miklos Szeredi Cc: hch@infradead.org, linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, linux-kernel@vger.kernel.org, agruen@suse.de, jjohansen@suse.de Subject: Re: [patch 3/8] Make d_path() consistent across mount operations Message-ID: <20080602055548.GA4296@infradead.org> References: <20080529113245.450308367@szeredi.hu> <20080529113310.608958055@szeredi.hu> <20080531082210.GD24135@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1185 Lines: 26 On Sun, Jun 01, 2008 at 10:38:35PM +0200, Miklos Szeredi wrote: > > > The path that __d_path() computes can become slightly inconsistent when it > > > races with mount operations: it grabs the vfsmount_lock when traversing mount > > > points but immediately drops it again, only to re-grab it when it reaches the > > > next mount point. The result is that the filename computed is not always > > > consisent, and the file may never have had that name. (This is unlikely, but > > > still possible.) > > > > > > Fix this by grabbing the vfsmount_lock for the whole duration of > > > __d_path(). > > > > Looks good, and lock holding times shouldn't be a problem either. > > Thanks for the review of this batch. > > Can you please in the future either explicitly ACK or NACK? Because I > really wouldn't want any more of this "Looks good, but bla bla bla" > and then NACKing the patch when I send it off to Andrew. ACK for patches 1-3. -- 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/