[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080624213439.GB2785@mail.oracle.com>
Date: Tue, 24 Jun 2008 14:34:39 -0700
From: Joel Becker <Joel.Becker@...cle.com>
To: Louis Rilling <Louis.Rilling@...labs.com>
Cc: linux-kernel@...r.kernel.org, ocfs2-devel@....oracle.com
Subject: Re: configfs: Q: item leak in a failing configfs_attach_group()?
On Tue, Jun 24, 2008 at 08:04:56PM +0200, Louis Rilling wrote:
> On Tue, Jun 24, 2008 at 10:10:51AM -0700, Joel Becker wrote:
> > On Tue, Jun 24, 2008 at 04:16:49PM +0200, Louis Rilling wrote:
> > > Hi,
> > >
> > > I'd like an opinion on the following scenario:
> > >
> > > process 1: process 2:
> > > configfs_mkdir("A")
> > > attach_group("A")
> > > attach_item("A")
> > > d_instantiate("A")
> > > populate_groups("A")
> > > mutex_lock("A")
> > > attach_group("A/B")
> > > attach_item("A")
> > > d_instantiate("A/B")
> > > mkdir("A/B/C")
> > > do_path_lookup("A/B/C", LOOKUP_PARENT)
> >
> > This has to sleep until
> > configfs_mkdir("A") finishes.
> > It's waiting on A->d_parent's
> > i_mutex, which is held by
> > sys_mkdirat().
>
> Can you be more precise? I don't see where do_path_lookup() locks an inode
It doesn't. It's in lookup_create(), which takes the mutex on the
parent of 'A'. Note that the end of sys_mkdirat() explicitly drops that
mutex - it couldn't do so if it hadn't been taken :-)
Joel
--
"You cannot bring about prosperity by discouraging thrift. You cannot
strengthen the weak by weakening the strong. You cannot help the wage
earner by pulling down the wage payer. You cannot further the
brotherhood of man by encouraging class hatred. You cannot help the
poor by destroying the rich. You cannot build character and courage by
taking away a man's initiative and independence. You cannot help men
permanently by doing for them what they could and should do for
themselves."
- Abraham Lincoln
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists