linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: [GIT PULL] Please pull NFS client bugfixes....
Date: Fri, 8 Jan 2010 01:43:29 +0100	[thread overview]
Message-ID: <20100108004329.GE16076@basil.fritz.box> (raw)
In-Reply-To: <1262909682.2659.45.camel@localhost>

On Thu, Jan 07, 2010 at 07:14:42PM -0500, Trond Myklebust wrote:
> 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.

Is that really a 2.6.33 solution?

It sounds intrusive.

> 
> > 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?

Because every lockdep user NFS+mmap gets spammed now.

That's like having an oops in the startup sequence. The system
might still boot, but users are not happy.

> 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 bet there were deadlocks somewhere, probably just didn't get reported.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

  parent reply	other threads:[~2010-01-08  0:43 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-07 20:29 [GIT PULL] Please pull NFS client bugfixes Trond Myklebust
2010-01-07 21:00 ` Andi Kleen
2010-01-07 21:23   ` Peter Staubach
2010-01-07 21:35     ` Andi Kleen
2010-01-07 21:53   ` Trond Myklebust
2010-01-07 23:51     ` Andi Kleen
2010-01-08  0:14       ` Trond Myklebust
2010-01-08  0:34         ` Linus Torvalds
2010-01-08  0:45           ` Andi Kleen
2010-01-08  1:03             ` Trond Myklebust
2010-01-08  1:03           ` Trond Myklebust
2010-01-08  1:12             ` Linus Torvalds
2010-01-08  1:22               ` Trond Myklebust
2010-01-08  1:26                 ` Trond Myklebust
2010-01-09  0:56                   ` [RFC PATCH 0/2] Fix up the NFS mmap code Trond Myklebust
2010-01-09  0:56                     ` [RFC PATCH 2/2] NFS: Fix a potential deadlock in nfs_file_mmap() Trond Myklebust
2010-01-09  1:54                       ` Al Viro
2010-01-09  0:56                     ` [RFC PATCH 1/2] VFS: Add a mmap_file() callback to struct file_operations Trond Myklebust
2010-01-09  1:17                     ` [RFC PATCH 0/2] Fix up the NFS mmap code Linus Torvalds
2010-01-09  1:38                       ` Al Viro
2010-01-09  1:46                         ` Al Viro
2010-01-09  1:57                         ` Linus Torvalds
2010-01-09  2:11                           ` Al Viro
2010-01-09  2:22                             ` Linus Torvalds
2010-01-09  2:30                               ` Al Viro
2010-01-09  2:40                                 ` Al Viro
2010-01-09  2:43                                   ` Al Viro
2010-01-10  2:00                     ` Andi Kleen
2010-01-08  1:30                 ` [GIT PULL] Please pull NFS client bugfixes Linus Torvalds
2010-01-08  1:35                   ` Linus Torvalds
2010-01-08  2:00                     ` Linus Torvalds
2010-01-14 13:18                       ` Peter Zijlstra
2010-01-08  5:19                   ` Andi Kleen
2010-01-08  1:22               ` Linus Torvalds
2010-01-08  0:43         ` Andi Kleen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-01-07 18:09 Trond Myklebust
2023-01-07 18:43 ` pr-tracker-bot
2022-09-12 21:34 Trond Myklebust
2022-09-12 21:57 ` pr-tracker-bot
2021-01-12 14:31 Trond Myklebust
2021-01-12 18:00 ` pr-tracker-bot
2020-09-28 17:27 Trond Myklebust
2020-09-28 18:16 ` pr-tracker-bot
2020-05-15 21:00 Trond Myklebust
2020-05-15 21:10 ` pr-tracker-bot
2020-05-02 13:35 Trond Myklebust
2020-05-02 18:45 ` pr-tracker-bot
2019-08-27 19:26 Trond Myklebust
2019-08-27 20:55 ` pr-tracker-bot
2019-08-08 21:26 Trond Myklebust
2019-08-09  1:30 ` pr-tracker-bot
2019-06-05 21:02 Schumaker, Anna
2019-04-13 14:56 Trond Myklebust
2019-04-13 22:00 ` pr-tracker-bot
2018-12-19 16:49 Trond Myklebust
2018-12-20  2:50 ` pr-tracker-bot
2018-12-20 15:23 ` Geert Uytterhoeven
2018-03-12 17:29 Trond Myklebust
2018-02-25 17:02 Trond Myklebust
2017-01-28 17:04 Trond Myklebust
2017-01-16 20:14 Trond Myklebust
2016-10-21 20:30 Anna Schumaker
2015-10-07  2:52 Trond Myklebust
2015-09-25 15:14 Trond Myklebust
2015-07-28 16:03 Trond Myklebust
2015-03-06  3:46 Trond Myklebust
2015-01-29 21:37 Trond Myklebust
2015-01-16 14:35 Trond Myklebust
2014-11-14 23:04 Trond Myklebust
2014-09-19 19:32 Trond Myklebust
2014-01-31 21:41 Trond Myklebust
2013-12-05 17:20 Trond Myklebust
2013-11-16 21:09 Myklebust, Trond
2013-09-30 22:02 Myklebust, Trond
2013-05-26 19:29 Myklebust, Trond
2013-03-26 18:26 Myklebust, Trond
2013-03-03  0:08 Myklebust, Trond
2013-02-21  3:38 Myklebust, Trond
2013-01-07 15:45 Myklebust, Trond
2012-11-03 19:48 Myklebust, Trond
2012-10-22 17:42 Myklebust, Trond
2012-09-12 19:19 Myklebust, Trond
2012-07-13 15:14 Myklebust, Trond
2012-05-02  3:57 Myklebust, Trond
2012-04-24 20:18 [GIT PULL] please " Myklebust, Trond
2011-12-20  6:15 [GIT PULL] Please " Trond Myklebust
2011-11-22 11:50 Trond Myklebust
2011-08-19  1:05 Trond Myklebust
2011-07-12 23:30 Trond Myklebust
2011-05-13 20:23 Trond Myklebust
2011-04-08 18:40 [GIT PULL] please " Trond Myklebust
2011-03-14 18:09 [GIT PULL] Please " Trond Myklebust
2010-11-26 18:56 Trond Myklebust
2010-05-26 19:42 Trond Myklebust
2010-05-07  2:22 Trond Myklebust
2010-04-29 16:48 Trond Myklebust
2010-03-23 17:00 Trond Myklebust
2010-03-17 21:55 Trond Myklebust
2010-02-04 19:10 Trond Myklebust
2009-05-26 19:06 Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100108004329.GE16076@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).