All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chris Mason <chris.mason@oracle.com>,
	Jeff Mahoney <jeffm@jeffreymahoney.com>
Subject: Re: reiserfs locking (v2)
Date: Sat, 3 Jul 2010 10:24:42 +0100	[thread overview]
Message-ID: <20100703092441.GM31073@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20100702131248.GA5324@nowhere>

On Fri, Jul 02, 2010 at 03:12:52PM +0200, Frederic Weisbecker wrote:
> Right.
> 
> 
> The problem is:
> 
> vfs_readdir() {						do_munmap() {
> 	mutex_lock(inode);					read or write(don't know)_lock(mm->mmap_sem)
> 	reiserfs_readdir() {					reiserfs_file_release() {
> 		read_lock(mm->mmap_sem)					mutex_lock(inode);
> 	}							}
> }							}
> 
> 
> 
> I don't think the deadlock can really happen, as we can't release the directory while
> we are reading it. Plus I guess we can't mmap a directory (someone correct me if
> I'm wrong).

Gyah...  For the 1001st time: readdir() is far from being the only thing that
nests mmap_sem inside i_mutex.  In particular, write() does the same thing.

So yes, it *is* a real deadlock, TYVM, with no directories involved.  Open the
same file twice, mmap one fd, close it, then have munmap() hitting i_mutex
in reiserfs_file_release() race with write() through another fd.

Incidentally, reiserfs_file_release() checks in the fastpath look completely
bogus.  Checking i_count?  What the hell is that one about?  And no, these
checks won't stop open() coming between them and grabbing i_mutex, so they
couldn't prevent the deadlock in question anyway.

  parent reply	other threads:[~2010-07-03  9:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02  9:34 reiserfs locking (v2) Sergey Senozhatsky
2010-07-02 13:12 ` Frederic Weisbecker
2010-07-02 13:44   ` Peter Zijlstra
2010-07-02 14:34     ` Frederic Weisbecker
2010-07-02 14:38       ` Peter Zijlstra
2010-07-02 13:59   ` Edward Shishkin
2010-07-02 14:03   ` Sergey Senozhatsky
2010-07-03  9:24   ` Al Viro [this message]
2010-07-03  9:43     ` Al Viro
2010-07-04  9:15       ` Al Viro
2010-07-09  3:16         ` Frederic Weisbecker
2010-07-09 10:42           ` Sergey Senozhatsky
2010-07-10 13:57             ` Frederic Weisbecker
  -- strict thread matches above, loose matches on Subject: below --
2010-07-02  9:49 Sergey Senozhatsky
2010-07-02  9:53 Sergey Senozhatsky

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=20100703092441.GM31073@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jeffm@jeffreymahoney.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=sergey.senozhatsky@gmail.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.