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

[Jeff Layton]

On Thu, 7 Mar 2013 17:16:12 +0000
"Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote:

> On Thu, 2013-03-07 at 09:03 -0800, Linus Torvalds wrote:
> > On Thu, Mar 7, 2013 at 8:45 AM, Myklebust, Trond
> > <Trond.Myklebust@xxxxxxxxxx> wrote:
> > >
> > > The problem there is that we get into the whole 'hard' vs 'soft' mount
> > > problem. We're supposed to guarantee data integrity for 'hard' mounts,
> > > so no funny business is allowed. OTOH, 'soft' mounts time out and return
> > > EIO to the application anyway, and so shouldn't be a problem.
> > >
> > > Perhaps we could add a '-oslushy' mount option :-) that guarantees data
> > > integrity for all situations _except_ ENETDOWN/ENETUNREACH?
> > 
> > I do think we are probably over-analyzing this. It's not like people
> > who want freezing to work usually use flaky NFS. There's really two
> > main groups:
> > 
> >  - the "freezer as a snapshot mechanism" that might use NFS because
> > they are in a server environment.
> > 
> >  - the "freeezer for suspend/resume on a laptop"
> > 
> > The first one does use NFS, and cares about it, and probably would
> > prefer the freeze event to take longer and finish for all ongoing IO
> > operations. End result: just ditch the "freezable_schedule()"
> > entirely.
> > 
> > The second one is unlikely to really use NFS anyway. End result:
> > ditching the freezable_schedule() is probably perfectly fine, even if
> > it would cause suspend failures if the network is being troublesome.
> > 
> > So for now, why not just replace freezable_schedule() with plain
> > schedule() in the NFS code, and ignore it until somebody actually
> > complains about it, and then aim to try to do something more targeted
> > for that particular complaint?
> 
> We _have_ had complaints about the laptop suspension problem; that was
> why Jeff introduced freezable_schedule() in the first place. We've never
> had complaints about any problems involvinf cgroup_freeze. This is why
> our focus tends to be on the former, and why I'm more worried about
> laptop suspend regressions for any short term fixes.
> 

Right. I don't know of anyone using the cgroup_freeze stuff. OTOH, I've
seen *many* reports of people who complained because their machine
didn't suspend because of a busy NFS mount.

In fact, the problem is still not fully "solved" with the
freezable_schedule stuff we have so far anyway. Even after this
(admittedly crappy) solution went in, we still had reports of machines
that failed to suspend because other tasks were stuck in
wait_on_page_writeback() for NFS pages.

So, in principle I think we need to abandon the current approach. The
question is what should replace it.

-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
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/