From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bharata B Rao" Subject: Re: [RFC PATCH 2/4] Mount changes to support union mount. Date: Wed, 20 Jun 2007 14:23:30 +0530 Message-ID: <344eb09a0706200153j3b856dcvb983218714d1eda0@mail.gmail.com> References: <20070620055050.GB4267@in.ibm.com> <20070620055241.GD4267@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, bharata@linux.vnet.ibm.com To: "Jan Blunck" Return-path: Received: from wa-out-1112.google.com ([209.85.146.182]:59644 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752365AbXFTIxb (ORCPT ); Wed, 20 Jun 2007 04:53:31 -0400 Received: by wa-out-1112.google.com with SMTP id v27so30791wah for ; Wed, 20 Jun 2007 01:53:30 -0700 (PDT) In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org (replying from a different ID as you didn't copy me on reply) On 6/20/07, Jan Blunck wrote: > On Wed, 20 Jun 2007 11:22:41 +0530, Bharata B Rao wrote: > > > +/* > > + * When propagating mount events to peer group, this is called under > > + * vfsmount_lock. Hence using GFP_ATOMIC for kmalloc here. > > + * TODO: Can we use a separate kmem cache for union_mount ? > > + */ > > +struct union_mount *alloc_union_mount(struct vfsmount *src_mnt, > > + struct dentry *src_dentry, struct vfsmount *dst_mnt, > > + struct dentry *dst_dentry) > > +{ > > + struct union_mount *u; > > + u = kmalloc(sizeof(struct union_mount), GFP_ATOMIC); > > + if (!u) > > + return u; > > + u->dst_mnt = mntget(dst_mnt); > > + u->dst_dentry = dget(dst_dentry); > > + u->src_mnt = src_mnt; > > + u->src_dentry = dget(src_dentry); > > + INIT_LIST_HEAD(&u->hash); > > + INIT_LIST_HEAD(&u->list); > > + return u; > > +} > > Hmm, you pin the dentries in memory until umount. This isn't good. Besides > that this doesn't work with file systems that do invalidate their > dentries. The file system must have a chance to replace the dentry in the > union structure. Yes, both top level and next level dentries are pinned until umount of the upper layer. I was thinking if we could prune these from prune_dcache(). What do you think ? Ok, I haven't thought about filesystem invalidating the dentries. Yet to understand the dentry invalidation, but would filesystem invalidate an inuse dentry ? Regards, Bharata. -- "Men come and go but mountains remain" -- Ruskin Bond.