From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: vfs-2.6 mountinfo Date: Mon, 31 Mar 2008 18:00:31 +0100 Message-ID: <20080331170031.GL9785@ZenIV.linux.org.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Miklos Szeredi Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58821 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753510AbYCaRAd (ORCPT ); Mon, 31 Mar 2008 13:00:33 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Mar 31, 2008 at 04:02:47PM +0200, Miklos Szeredi wrote: > Some hunks from "[patch 4/7] vfs: mountinfo: add mount peer group ID" > seems to have accidentally leaked into "[PATCH] teach seq_file to > discard entries", affecting bisectability. Ugh... Will fix; thanks for spotting - I wonder how that had happened... > And in "[patch 3/7] vfs: mountinfo: add mount ID" allocation is *not* > serialized by namespace_sem on the vfs_kern_mount() call path, so this > is racy AFAICS: *hrm* Right you are ;-/ I really don't like the look of that - the real question here is whether we want vfsmount IDs to exist through the entire lifetime of vfsmount. If we do, then we need that (and use of vfsmount_lock in free_vfsmnt() path as it is done now); if not... I'm still tempted to move allocation to the same place where we attach the damn thing to some tree... Anyway, retry variant will do for now, but I still wonder whether it's really right long-term... Do we want vfsmount IDs to have any exposure other than that in mountinfo?