From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
"Theodore Tso" <tytso@mit.edu>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: [34/34] ext4: Fix potential fiemap deadlock (mmap_sem vs. i_data_sem)
Date: Thu, 10 Dec 2009 21:23:46 -0800 [thread overview]
Message-ID: <20091211052558.863762484@linux.site> (raw)
In-Reply-To: <20091211052858.GA23229@kroah.com>
[-- Attachment #1: 0030-ext4-Fix-potential-fiemap-deadlock-mmap_sem-vs.-i_da.patch --]
[-- Type: text/plain, Size: 5130 bytes --]
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
(cherry picked from commit fab3a549e204172236779f502eccb4f9bf0dc87d)
Fix the following potential circular locking dependency between
mm->mmap_sem and ei->i_data_sem:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-04115-gec044c5 #37
-------------------------------------------------------
ureadahead/1855 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<ffffffff81107224>] might_fault+0x5c/0xac
but task is already holding lock:
(&ei->i_data_sem){++++..}, at: [<ffffffff811be1fd>] ext4_fiemap+0x11b/0x159
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&ei->i_data_sem){++++..}:
[<ffffffff81099bfa>] __lock_acquire+0xb67/0xd0f
[<ffffffff81099e7e>] lock_acquire+0xdc/0x102
[<ffffffff81516633>] down_read+0x51/0x84
[<ffffffff811a2414>] ext4_get_blocks+0x50/0x2a5
[<ffffffff811a3453>] ext4_get_block+0xab/0xef
[<ffffffff81154f39>] do_mpage_readpage+0x198/0x48d
[<ffffffff81155360>] mpage_readpages+0xd0/0x114
[<ffffffff811a104b>] ext4_readpages+0x1d/0x1f
[<ffffffff810f8644>] __do_page_cache_readahead+0x12f/0x1bc
[<ffffffff810f86f2>] ra_submit+0x21/0x25
[<ffffffff810f0cfd>] filemap_fault+0x19f/0x32c
[<ffffffff81107b97>] __do_fault+0x55/0x3a2
[<ffffffff81109db0>] handle_mm_fault+0x327/0x734
[<ffffffff8151aaa9>] do_page_fault+0x292/0x2aa
[<ffffffff81518205>] page_fault+0x25/0x30
[<ffffffff812a34d8>] clear_user+0x38/0x3c
[<ffffffff81167e16>] padzero+0x20/0x31
[<ffffffff81168b47>] load_elf_binary+0x8bc/0x17ed
[<ffffffff81130e95>] search_binary_handler+0xc2/0x259
[<ffffffff81166d64>] load_script+0x1b8/0x1cc
[<ffffffff81130e95>] search_binary_handler+0xc2/0x259
[<ffffffff8113255f>] do_execve+0x1ce/0x2cf
[<ffffffff81027494>] sys_execve+0x43/0x5a
[<ffffffff8102918a>] stub_execve+0x6a/0xc0
-> #0 (&mm->mmap_sem){++++++}:
[<ffffffff81099aa4>] __lock_acquire+0xa11/0xd0f
[<ffffffff81099e7e>] lock_acquire+0xdc/0x102
[<ffffffff81107251>] might_fault+0x89/0xac
[<ffffffff81139382>] fiemap_fill_next_extent+0x95/0xda
[<ffffffff811bcb43>] ext4_ext_fiemap_cb+0x138/0x157
[<ffffffff811be069>] ext4_ext_walk_space+0x178/0x1f1
[<ffffffff811be21e>] ext4_fiemap+0x13c/0x159
[<ffffffff811390e6>] do_vfs_ioctl+0x348/0x4d6
[<ffffffff811392ca>] sys_ioctl+0x56/0x79
[<ffffffff81028cb2>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
1 lock held by ureadahead/1855:
#0: (&ei->i_data_sem){++++..}, at: [<ffffffff811be1fd>] ext4_fiemap+0x11b/0x159
stack backtrace:
Pid: 1855, comm: ureadahead Not tainted 2.6.32-04115-gec044c5 #37
Call Trace:
[<ffffffff81098c70>] print_circular_bug+0xa8/0xb7
[<ffffffff81099aa4>] __lock_acquire+0xa11/0xd0f
[<ffffffff8102f229>] ? sched_clock+0x9/0xd
[<ffffffff81099e7e>] lock_acquire+0xdc/0x102
[<ffffffff81107224>] ? might_fault+0x5c/0xac
[<ffffffff81107251>] might_fault+0x89/0xac
[<ffffffff81107224>] ? might_fault+0x5c/0xac
[<ffffffff81124b44>] ? __kmalloc+0x13b/0x18c
[<ffffffff81139382>] fiemap_fill_next_extent+0x95/0xda
[<ffffffff811bcb43>] ext4_ext_fiemap_cb+0x138/0x157
[<ffffffff811bca0b>] ? ext4_ext_fiemap_cb+0x0/0x157
[<ffffffff811be069>] ext4_ext_walk_space+0x178/0x1f1
[<ffffffff811be21e>] ext4_fiemap+0x13c/0x159
[<ffffffff81107224>] ? might_fault+0x5c/0xac
[<ffffffff811390e6>] do_vfs_ioctl+0x348/0x4d6
[<ffffffff8129f6d0>] ? __up_read+0x8d/0x95
[<ffffffff81517fb5>] ? retint_swapgs+0x13/0x1b
[<ffffffff811392ca>] sys_ioctl+0x56/0x79
[<ffffffff81028cb2>] system_call_fastpath+0x16/0x1b
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/ext4/extents.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -1761,7 +1761,9 @@ int ext4_ext_walk_space(struct inode *in
while (block < last && block != EXT_MAX_BLOCK) {
num = last - block;
/* find extent for this block */
+ down_read(&EXT4_I(inode)->i_data_sem);
path = ext4_ext_find_extent(inode, block, path);
+ up_read(&EXT4_I(inode)->i_data_sem);
if (IS_ERR(path)) {
err = PTR_ERR(path);
path = NULL;
@@ -3730,10 +3732,8 @@ int ext4_fiemap(struct inode *inode, str
* Walk the extent tree gathering extent information.
* ext4_ext_fiemap_cb will push extents back to user.
*/
- down_read(&EXT4_I(inode)->i_data_sem);
error = ext4_ext_walk_space(inode, start_blk, len_blks,
ext4_ext_fiemap_cb, fieinfo);
- up_read(&EXT4_I(inode)->i_data_sem);
}
return error;
prev parent reply other threads:[~2009-12-11 5:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091211052312.805428372@linux.site>
2009-12-11 5:28 ` [00/34] 2.6.32.1-stable review Greg KH
2009-12-11 5:23 ` [01/34] signal: Fix alternate signal stack check Greg KH
2009-12-11 5:23 ` [02/34] SCSI: scsi_lib_dma: fix bug with dma maps on nested scsi objects Greg KH
2009-12-11 5:23 ` [03/34] SCSI: osd_protocol.h: Add missing #include Greg KH
2009-12-11 5:23 ` [04/34] SCSI: megaraid_sas: fix 64 bit sense pointer truncation Greg KH
2009-12-11 5:23 ` [05/34] ext4: fix potential buffer head leak when add_dirent_to_buf() returns ENOSPC Greg KH
2009-12-11 5:23 ` [06/34] ext4: avoid divide by zero when trying to mount a corrupted file system Greg KH
2009-12-11 5:23 ` [07/34] ext4: fix the returned block count if EXT4_IOC_MOVE_EXT fails Greg KH
2009-12-11 5:23 ` [08/34] ext4: fix lock order problem in ext4_move_extents() Greg KH
2009-12-11 5:23 ` [09/34] ext4: fix possible recursive locking warning in EXT4_IOC_MOVE_EXT Greg KH
2009-12-11 5:23 ` [10/34] ext4: plug a buffer_head leak in an error path of ext4_iget() Greg KH
2009-12-11 5:23 ` [11/34] ext4: make sure directory and symlink blocks are revoked Greg KH
2009-12-11 5:23 ` [12/34] ext4: fix i_flags access in ext4_da_writepages_trans_blocks() Greg KH
2009-12-11 5:23 ` [13/34] ext4: journal all modifications in ext4_xattr_set_handle Greg KH
2009-12-11 5:23 ` [14/34] ext4: dont update the superblock in ext4_statfs() Greg KH
2009-12-11 5:23 ` [15/34] ext4: fix uninit block bitmap initialization when s_meta_first_bg is non-zero Greg KH
2009-12-11 5:23 ` [16/34] ext4: fix block validity checks so they work correctly with meta_bg Greg KH
2009-12-11 5:23 ` [17/34] ext4: avoid issuing unnecessary barriers Greg KH
2009-12-11 5:23 ` [18/34] ext4: fix error handling in ext4_ind_get_blocks() Greg KH
2009-12-11 5:23 ` [19/34] ext4: make trim/discard optional (and off by default) Greg KH
2009-12-11 5:23 ` [20/34] ext4: make "norecovery" an alias for "noload" Greg KH
2009-12-11 5:23 ` [21/34] ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT Greg KH
2009-12-11 5:23 ` [22/34] ext4: initialize moved_len before calling ext4_move_extents() Greg KH
2009-12-11 5:23 ` [23/34] ext4: move_extent_per_page() cleanup Greg KH
2009-12-11 5:23 ` [24/34] jbd2: Add ENOMEM checking in and for jbd2_journal_write_metadata_buffer() Greg KH
2009-12-11 5:23 ` [25/34] ext4: Return the PTR_ERR of the correct pointer in setup_new_group_blocks() Greg KH
2009-12-11 5:23 ` [26/34] ext4: Avoid data / filesystem corruption when write fails to copy data Greg KH
2009-12-11 5:23 ` [27/34] ext4: wait for log to commit when umounting Greg KH
2009-12-11 5:23 ` [28/34] ext4: remove blocks from inode prealloc list on failure Greg KH
2009-12-11 5:23 ` [29/34] ext4: ext4_get_reserved_space() must return bytes instead of blocks Greg KH
2009-12-11 5:23 ` [30/34] ext4: quota macros cleanup Greg KH
2009-12-11 5:23 ` [31/34] ext4: fix incorrect block reservation on quota transfer Greg KH
2009-12-11 5:23 ` [32/34] ext4: Wait for proper transaction commit on fsync Greg KH
2009-12-11 5:23 ` [33/34] ext4: Fix insufficient checks in EXT4_IOC_MOVE_EXT Greg KH
2009-12-11 5:23 ` Greg KH [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=20091211052558.863762484@linux.site \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=stable-review@kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.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 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.