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]

Message-ID: <CA+55aFwB4Pjki8zg9idwbQbE-TOtTdD5o8d_r1=NY3veVqmPHg@mail.gmail.com>
Date:	Thu, 7 Mar 2013 09:03:43 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc:	Jeff Layton <jlayton@...hat.com>, 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, 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?

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