All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-mm@kvack.org, xfs@oss.sgi.com
Subject: Re: fput under mmap_sem
Date: Wed, 18 Mar 2009 23:37:48 +1100	[thread overview]
Message-ID: <200903182337.48789.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20090318071313.GA30011@infradead.org>

On Wednesday 18 March 2009 18:13:13 Christoph Hellwig wrote:
> On Mon, Mar 16, 2009 at 09:19:21AM +1100, Dave Chinner wrote:
> > This is a VM problem where it calls fput() with the mmap_sem() held
> > in remove_vma(). It makes the incorrect assumption that filesystems
> > will never use the same lock in the IO path and the inode release path.
> >
> > This can deadlock if you are really unlucky.
>
> I really wonder why other filesystems haven't hit this yet.  Any chance
> we can get the fput moved out of mmap_sem to get rid of this class of
> problems?

Yes I don't think there is any reason against holding the file refcount
a little longer, but it can be pretty nasty to do in practice because
of deep call chains and sometimes multiple fputs within a given lock
section.

Possibly the easiest and quickest way will be to move aio's deferred
__fput into a usable API and try that. If there are any performance
problems, then we can try to move those fputs out from the mmap_sem
one at a time (eg. I don't expect fput for vma replacement/merging to
often cause the refcount to reach 0, and this is one of the harder
places; wheras fput for a simple munmap might be more often causing
refcount to reach 0 but it should be simpler to move out of mmap_sem
if it is a problem).

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com, linux-mm@kvack.org
Subject: Re: fput under mmap_sem
Date: Wed, 18 Mar 2009 23:37:48 +1100	[thread overview]
Message-ID: <200903182337.48789.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20090318071313.GA30011@infradead.org>

On Wednesday 18 March 2009 18:13:13 Christoph Hellwig wrote:
> On Mon, Mar 16, 2009 at 09:19:21AM +1100, Dave Chinner wrote:
> > This is a VM problem where it calls fput() with the mmap_sem() held
> > in remove_vma(). It makes the incorrect assumption that filesystems
> > will never use the same lock in the IO path and the inode release path.
> >
> > This can deadlock if you are really unlucky.
>
> I really wonder why other filesystems haven't hit this yet.  Any chance
> we can get the fput moved out of mmap_sem to get rid of this class of
> problems?

Yes I don't think there is any reason against holding the file refcount
a little longer, but it can be pretty nasty to do in practice because
of deep call chains and sometimes multiple fputs within a given lock
section.

Possibly the easiest and quickest way will be to move aio's deferred
__fput into a usable API and try that. If there are any performance
problems, then we can try to move those fputs out from the mmap_sem
one at a time (eg. I don't expect fput for vma replacement/merging to
often cause the refcount to reach 0, and this is one of the harder
places; wheras fput for a simple munmap might be more often causing
refcount to reach 0 but it should be simpler to move out of mmap_sem
if it is a problem).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-03-18 12:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-15 12:59 XFS lock warning, 2.6.29-rc8 Denys Fedoryschenko
2009-03-15 22:19 ` Dave Chinner
2009-03-15 22:19   ` Dave Chinner
2009-03-18  7:13   ` fput under mmap_sem Christoph Hellwig
2009-03-18  7:13     ` Christoph Hellwig
2009-03-18 12:37     ` Nick Piggin [this message]
2009-03-18 12:37       ` Nick Piggin

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=200903182337.48789.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=hch@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.