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

[Linus Torvalds <torvalds@linux-foundation.org>]

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