linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Eric Whitney <enwlinux@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: ext4 xfstests-bld results for 3.8-rc6 on Pandaboard ES
Date: Mon, 11 Feb 2013 16:29:08 +0100	[thread overview]
Message-ID: <20130211152908.GE5318@quack.suse.cz> (raw)
In-Reply-To: <20130207220536.GA16092@wallace>

On Thu 07-02-13 17:05:36, Eric Whitney wrote:
> Here's the lockdep report for xfstest 113 run in the dioread_nolock scenario
> as mentioned above (the taint is due to an unrelated warning from the clk
> subsystem believed to be unique to 3.8 on Pandaboards/OMAP):
  Thanks for the report!

> [ INFO: possible circular locking dependency detected ]
> 3.8.0-rc6 #1 Tainted: G        W   
> -------------------------------------------------------
> aio-stress/8597 is trying to acquire lock:
>  (&mm->mmap_sem){++++++}, at: [<c00f1928>] get_user_pages_fast+0x48/0x88
> 
> but task is already holding lock:
>  (&ei->i_data_sem){++++.+}, at: [<c01ae2a8>] ext4_direct_IO+0x3d4/0x450
>  
> which lock already depends on the new lock.
  Drat, this looks like a real deadlock possibility. I didn't realize this
when reviewing the dioread_nolock patches but i_data_sem ranks below
mmap_sem because we need to grab it in page fault path to map blocks. So we
cannot acquire it in ext4_ext_direct_IO() as it calls
__blockdev_direct_IO() which gets mmap_sem to fault in user-provided pages.
That will be tough to fix... Luckily, the deadlock isn't easy to hit in
practice as it requires mmap and DIO to happen on the same file (already
unlikely) and furthermore three processes, two of them sharing mm, to race
in the right way:

Thread 1		Thread 2	Thread 3
down_read(mmap_sem);
			mmap()
...			  down_write(mmap_sem); [blocked]
  ext4_page_mkwrite();
					ext4_ext_direct_IO()
					  down_read(i_data_sem);
					  ...
					  __blockdev_direct_IO();
					    get_user_pages_fast();
					      down_read(mmap_sem); [blocked]
    ...
    ext4_da_get_block_prep();
      down_write(i_data_sem); [blocked]


								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

      parent reply	other threads:[~2013-02-11 15:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-07 22:05 ext4 xfstests-bld results for 3.8-rc6 on Pandaboard ES Eric Whitney
2013-02-08  3:55 ` Zheng Liu
2013-02-11  1:35   ` Theodore Ts'o
2013-02-11  2:08     ` Theodore Ts'o
2013-02-11  3:24       ` Theodore Ts'o
2013-02-11  3:36         ` gnehzuil.liu
2013-02-11  3:48           ` Theodore Ts'o
2013-02-11 15:56     ` Eric Sandeen
2013-02-11 21:16       ` Theodore Ts'o
2013-02-11 15:29 ` Jan Kara [this message]

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=20130211152908.GE5318@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=enwlinux@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).