[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1234254755.4893.3.camel@laptop>
Date: Tue, 10 Feb 2009 09:32:35 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Li Zefan <lizf@...fujitsu.com>
Cc: Al Viro <viro@...IV.linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Menage <menage@...gle.com>,
Arjan van de Ven <arjan@...radead.org>,
linux-fsdevel@...r.kernel.org
Subject: Re: [cgroup or VFS ?] INFO: possible recursive locking detected
On Tue, 2009-02-10 at 11:06 +0800, Li Zefan wrote:
> > It seems to me we can simply put the new s_umount instance in a
> > different subclass. Its a bit unusual to use _nested for the outer lock,
> > but lockdep doesn't particularly cares about subclass order.
> >
> > If there's any issue with the callers of sget() assuming the s_umount
> > lock being of sublcass 0, then there is another annotation we can use to
> > fix that, but lets not bother with that if this is sufficient.
> >
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
>
> Tested-by: Li Zefan <lizf@...fujitsu.com>
>
> Thanks!
>
> a minor comment
>
> > + * lock of the old one. Since these are clearly distrinct
>
> s/distrinct/distinct
Yes, someone else was kind enough to point that out as well :-)
Al, do you want a resend or will you fix that up when you add the patch
to your queue?
> BTW, I found another bug in current code:
Yep, looks good, freeing held locks makes lockdep unhappy.
> From: Li Zefan <lizf@...fujitsu.com>
> Date: Tue, 10 Feb 2009 10:55:53 +0800
> Subject: [PATCH] vfs: add missing unlock in sget()
>
> We should release s->s_umount before calling destroy_super(s).
>
> Signed-off-by: Li Zefan <lizf@...fujitsu.com>
> ---
--
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