[lkml]   [2010]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] Please pull NFS client bugfixes....
On Fri, 2010-01-08 at 00:51 +0100, Andi Kleen wrote: 
> > I'd like to see this fixed, but I do not want to jump onto a solution
> > that changes the behaviour of mmap() w.r.t. revalidation. The current
> > behaviour dates back at least to 2.3.x if not before.
> So do you have a plan to fix it?

Yes. I want to pursue Peter Zijlstra's patches, which split up the mmap
function into a set of parts which require the mmap_sem, and other parts
which don't, and that adds a filesystem callback that allows for
revalidation to occur outside the mmap_sem.

> I don't think it'll be possible to do drastic changes in the
> VFS for 2.6.33, and it seems preserving the current semantics
> would need that.
> > That's why I'm working slowly on this.
> Delaying a fix to after 2.6.33 is not an option imho.
> It hits everyone with LOCKDEP enabled who uses mmap over NFS.
> That's new in 2.6.33, previously LOCKDEP didn't diagnose this.
> I'll keep using my patch, but I suppose once we're going more
> towards a release you'll get more reports of this.

Why should this particular issue require us to rush into a solution?
This has been there for literally _years_, and I've never heard of a
single incident in which a deadlock actually occurred. The only reason
why we've noticed it at all is because lockdep has started to whine.

I agree it should be fixed.

I don't agree that it is urgent enough to warrant kneejerk reactions in
2.6.33 which change long established behaviours that people are actually
relying on.


 \ /
  Last update: 2010-01-08 01:19    [W:0.058 / U:0.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site