Messages in this thread | | | Subject | Re: [cgroup or VFS ?] INFO: possible recursive locking detected | From | Peter Zijlstra <> | Date | Tue, 10 Feb 2009 09:32:35 +0100 |
| |
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@chello.nl> > > Tested-by: Li Zefan <lizf@cn.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@cn.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@cn.fujitsu.com> > ---
| |