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

[Myklebust, Trond]

On Thu, 2013-03-07 at 08:25 -0800, Linus Torvalds wrote:
> On Thu, Mar 7, 2013 at 7:59 AM, Myklebust, Trond
> <Trond.Myklebust@xxxxxxxxxx> wrote:
> >
> > It _shouldn't_ be an interruption unless the filesystem can't make
> > progress.
> 
> So how can we tell? Calling "freezable_schedule()" if you're not ready
> to be frozen is not good. And nobody but the NFS code can know.
> 
> You might want to introduce some counter that counts number of
> outstanding non-interruptible events, and only call the "freezable"
> version if that counter is zero.
> 
> A better alternative might be to *never* call the freezable version.
> Because those freezable_*() things are really quite disgusting, and
> are wrong - they don't actually freeze the process, they say "I don't
> care if you freeze me while I sleep", and you might actually wake up
> *while* the system is being frozen. I think the whole concept is
> broken. Rafaei - comments? The function really is crap, regardless of
> any unrelated NFS problems.
> 
> So what NFS could do instead is actually check the "do I need to
> freeze" flag, and if you need to freeze you consider it an abort - and
> do *not* try to continue. Just freeze, and then act as if the machine
> got rebooted as far as NFS was concerned. That should work anyway, no?
> 
> That does sound a lot more complex, though.

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?

-- 
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/