public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ingo Molnar <mingo@elte.hu>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joe Korty <joe.korty@ccur.com>, Al Viro <viro@zeniv.linux.org.uk>,
	Steve French <sfrench@us.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: circular locking dependency detected panic in filldir when CONFIG_PROVE_LOCKING=y
Date: Sat, 19 Sep 2009 13:19:48 +0200	[thread overview]
Message-ID: <1253359188.7085.0.camel@laptop> (raw)
In-Reply-To: <20090919072349.GC15292@elte.hu>

On Sat, 2009-09-19 at 09:23 +0200, Ingo Molnar wrote:
> * Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> 
> > On Fri, 2009-09-18 at 17:15 -0400, Joe Korty wrote:
> > > I experienced a might_fault panic from NFS's use of filldir
> > > in a 2.6.31 kernel compiled with CONFIG_PROVE_LOCKING=y.
> > > 
> > > Looking at filldir, I see it is accessing user space with
> > > __put_dir's (which are inatomic) and with one copy_to_user
> > > (which is not inatomic).  It is the single copy_to_user
> > > which is causing the might_fault panic.
> > > 
> > > It doesn't make any sense to be mixing use of inatomic
> > > and non-inatomic services in filldir.  Either all should be
> > > the inatomic version, or none should be.
> > > 
> > > The might_fault condition being reported by the panic looks
> > > real to me, so I suspect the wrong answer is converting
> > > everything to the inatomic version, since that just
> > > suppresses the circular dependency check while leaving
> > > the circular dependency in place.
> > 
> > Yes. This is known... Please see 
> >    http://thread.gmane.org/gmane.linux.nfs/28578
> > and
> >    http://thread.gmane.org/gmane.linux.nfs/27406
> > 
> > I'm still hoping the VM folks can see fit to merge Peter's fix at some
> > point...
> 
> Ouch, those patches at:
> 
>   http://programming.kicks-ass.net/kernel-patches/mmap-vs-nfs/
> 
> .... are 2 years old. Higher intensity prodding needed to get this 
> moving?

No I just need to find a way to clone() myself :-)


  reply	other threads:[~2009-09-19 11:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 21:15 circular locking dependency detected panic in filldir when CONFIG_PROVE_LOCKING=y Joe Korty
2009-09-18 21:39 ` Trond Myklebust
2009-09-19  7:23   ` Ingo Molnar
2009-09-19 11:19     ` Peter Zijlstra [this message]
2009-09-19 17:39       ` Ingo Molnar

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=1253359188.7085.0.camel@laptop \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sfrench@us.ibm.com \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@zeniv.linux.org.uk \
    /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