From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756770Ab0CCVut (ORCPT ); Wed, 3 Mar 2010 16:50:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43203 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756752Ab0CCVuc (ORCPT ); Wed, 3 Mar 2010 16:50:32 -0500 Date: Wed, 3 Mar 2010 16:49:52 -0500 From: Valerie Aurora To: Miklos Szeredi , jblunck@suse.de Cc: viro@zeniv.linux.org.uk, hch@infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/6] union-mount: Drive the union cache via dcache Message-ID: <20100303214952.GD19689@shell> References: <1267567889-4637-1-git-send-email-vaurora@redhat.com> <1267567889-4637-2-git-send-email-vaurora@redhat.com> <1267567889-4637-3-git-send-email-vaurora@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 03, 2010 at 06:35:55PM +0100, Miklos Szeredi wrote: > On Tue, 2 Mar 2010, Valerie Aurora wrote: > > +/* > > + * This must be called after __d_drop_unions() without holding any locks. > > + * Note: The dentry might still be reachable via a lookup but at that time it > > + * already a negative dentry. Otherwise it would be unhashed. The union_mount > > + * structure itself is still reachable through mnt->mnt_unions (which we > > + * protect against with union_lock). > > + * > > + * We were worried about a recursive dput() call through: > > + * > > + * dput()->d_kill()->shrink_d_unions()->union_put()->dput() > > + * > > + * But this path can only be reached if the dentry is unhashed when we > > + * enter the first dput(), and it can only be unhashed if it was > > + * rmdir()'d, and d_delete() calls shrink_d_unions() for us. > > + */ > > +void shrink_d_unions(struct dentry *dentry) > > +{ > > + struct union_mount *this, *next; > > + > > +repeat: > > + spin_lock(&union_lock); > > + list_for_each_entry_safe(this, next, &dentry->d_unions, u_unions) { > > + BUG_ON(!hlist_unhashed(&this->u_hash)); > > + BUG_ON(!hlist_unhashed(&this->u_rhash)); > > + list_del(&this->u_unions); > > + this->u_next.dentry->d_unionized--; > > + spin_unlock(&union_lock); > > + union_put(this); > > + goto repeat; > > This loop is weird. That list_for_each_entry_safe is just used to > initialize "this", since it unconditionally restarts from the > beginning. This loop is definitely weird, but the alternative is so simple (replace the goto with a spin_lock()) that I suspect Jan had a reason to write it this way. Jan, do you recall? Unfortunately it has not been tested on more than one element in the list (although multiple layers now seem a possibility with the current code). -VAL