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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Mar 2013 16:43:03 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Mandeep Singh Baines <msb@...omium.org>,
	Ming Lei <ming.lei@...onical.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

On Thu, 7 Mar 2013 17:16:12 +0000
"Myklebust, Trond" <Trond.Myklebust@...app.com> 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@...app.com> 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@...hat.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/