linux-kernel - Re: [GIT PULL] Please pull NFS client bugfixes....

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: <alpine.LFD.2.00.1001071718040.7821@localhost.localdomain>
Date:	Thu, 7 Jan 2010 17:22:36 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Please pull NFS client bugfixes....

On Thu, 7 Jan 2010, Linus Torvalds wrote:
> 
> A filesystem that depends on the different phases would be a fundamentally 
> buggy filesystem. Right now mmap is "atomic", and you can pre-populate (or 
> pre-verify, like NFS does) the mapping in the _knowledge_ that there are 
> no page faults that will populate it concurrently. Exactly because we hold 
> the mmap_sem for writing.

Side note: I realize that a filesystem could add its own lock, but that 
doesn't _help_ anything. In that case, it needs to take the lock while 
under the mmap_sem, and release it later in the "post-mmap-sem" callback, 
but not only is that ugly, it means that there is a mmap_sem -> newlock 
dependency between the two, which means that any lock dependency of code 
that runs under the new lock will not really have changed. You might as 
well have run it under the mmap_lock to begin with.

That's why I claim it's buggy. 

I'm sure you can do clever things for special cases, but it all sounds 
like you really need to fix the lockdep chain some way.

If you absolutely have to do the revalidation at mmap() time, then the 
lock chain needs to be broken somewhere else. Since this is a filesystem, 
and mmap_sem is involved, I can only assume that the other part of the 
chain is "readdir()" as usual.

See the whole sysfs discussion about that (look for sysfs and filldir on 
the kernel list a week or two ago).

		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/