Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754769AbZKIWex (ORCPT ); Mon, 9 Nov 2009 17:34:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754512AbZKIWew (ORCPT ); Mon, 9 Nov 2009 17:34:52 -0500 Received: from mail-pw0-f42.google.com ([209.85.160.42]:46033 "EHLO mail-pw0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754314AbZKIWew convert rfc822-to-8bit (ORCPT ); Mon, 9 Nov 2009 17:34:52 -0500 MIME-Version: 1.0 In-Reply-To: <20091109141439.GA10927@us.ibm.com> References: <1257249429-12384-12-git-send-email-ebiederm@xmission.com> <20091104214938.GA21033@us.ibm.com> <4AF4D76C.6090008@kernel.org> <20091109141439.GA10927@us.ibm.com> Date: Mon, 9 Nov 2009 14:34:57 -0800 Message-ID: Subject: Re: [PATCH 12/13] sysfs: Propagate renames to the vfs on demand From: Eric Biederman To: "Serge E. Hallyn" Cc: Tejun Heo , "Eric W. Biederman" , Greg Kroah-Hartman , Kay Sievers , Greg KH , linux-kernel@vger.kernel.org, Cornelia Huck , linux-fsdevel@vger.kernel.org, Eric Dumazet , Benjamin LaHaise Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1558 Lines: 35 On Mon, Nov 9, 2009 at 6:14 AM, Serge E. Hallyn wrote: > Quoting Tejun Heo (tj@kernel.org): >> Hello, >> >> Eric W. Biederman wrote: >> > It isn't what I want but it is what the VFS requires. ?If let the vfs >> > continue on it's delusional state we will leak the vfs mount and >> > everything mounted on top of it, with no way to remove the mounts. >> >> This is caused by not having any way to prevent deletion on >> directories with submounts, right? ?How does other distributed >> filesystems deal with directories with submounts going away underneath >> it? > > Ooooh. ?I see, I was thinking only about the rename case, and forgot > this was the path for deleted files, too. ?For the rename case it > should be ok to let the dentry be put since the submounts will be > accessible at the new location, right? ?Should that be handled > separately? No in the rename case it isn't ok to let the dentry be discarded put as mounts are implemented using a hash of the struct dentry's address, and if you aren't the mount point you are referenced as d_parent. For rename I am slightly better than NFS. sysfs does not support hard links so if I am looking up the new name I can look for a preexisting dentry for my inode and if I find one I call d_move on it to lazily perform the rename. Eric -- 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/