Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

[Myklebust, Trond]

On Mon, 2013-03-04 at 21:53 +0100, Oleg Nesterov wrote:
> On 03/04, Mandeep Singh Baines wrote:
> >
> > The problem is that freezer_count() calls try_to_freeze(). In this
> > case, try_to_freeze() is not really adding any value.
> 
> Well, I tend to agree.
> 
> If a task calls __refrigerator() holding a lock which another freezable
> task can wait for, this is not freezer-friendly.
> 
> freezable_schedule/freezer_do_not_count/etc not only means "I won't be
> active if freezing()", it should also mean "I won't block suspend/etc".

If suspend for some reason requires a re-entrant mount, then yes, I can
see how it might be a problem that we're holding a mount-related lock.
The question is why is that necessary?

> OTOH, I understand that probably it is not trivial to change this code
> to make it freezer-friendly. But at least  I disagree with "push your
> problems onto others".

That code can't be made freezer-friendly if it isn't allowed to hold
basic filesystem-related locks across RPC calls. A number of those RPC
calls do things that need to be protected by VFS or MM-level locks.
i.e.: lookups, file creation/deletion, page fault in/out, ...
 
IOW: the problem would need to be solved differently, possibly by adding
a new FIFREEZE-like call to allow the filesystem to quiesce itself
_before_ NetworkManager pulls the rug out from underneath it. There
would still be plenty of corner cases to keep people entertained (e.g.
the server goes down before the quiesce call is invoked) but at least
the top 90% of cases would be solved.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/