From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
Theodore Ts'o <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
Chris Wedgwood <reviews@ml.cw.f00f.org>,
Michael Krufky <mkrufky@linuxtv.org>,
Chuck Ebbert <cebbert@redhat.com>,
Domenico Andreoli <cavokz@gmail.com>, Willy Tarreau <w@1wt.eu>,
Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
Jake Edge <jake@lwn.net>, Eugene Teo <eteo@redhat.com>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
alan@lxorguk.ukuu.org.uk, linux-ext4@vger.kernel.org,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: [patch 60/60] ext4: Fix race in ext4_inode_info.i_cached_extent
Date: Tue, 09 Jun 2009 17:14:28 -0700 [thread overview]
Message-ID: <20090610002353.503772667@blue.kroah.org> (raw)
In-Reply-To: <20090610032135.GA19346@kroah.com>
[-- Attachment #1: ext4-fix-race-in-ext4_inode_info.i_cached_extent.patch --]
[-- Type: text/plain, Size: 2478 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
From: "Theodore Ts'o" <tytso@mit.edu>
(cherry picked from commit 2ec0ae3acec47f628179ee95fe2c4da01b5e9fc4)
If two CPU's simultaneously call ext4_ext_get_blocks() at the same
time, there is nothing protecting the i_cached_extent structure from
being used and updated at the same time. This could potentially cause
the wrong location on disk to be read or written to, including
potentially causing the corruption of the block group descriptors
and/or inode table.
This bug has been in the ext4 code since almost the very beginning of
ext4's development. Fortunately once the data is stored in the page
cache cache, ext4_get_blocks() doesn't need to be called, so trying to
replicate this problem to the point where we could identify its root
cause was *extremely* difficult. Many thanks to Kevin Shanahan for
working over several months to be able to reproduce this easily so we
could finally nail down the cause of the corruption.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/ext4/extents.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -1633,11 +1633,13 @@ ext4_ext_put_in_cache(struct inode *inod
{
struct ext4_ext_cache *cex;
BUG_ON(len == 0);
+ spin_lock(&EXT4_I(inode)->i_block_reservation_lock);
cex = &EXT4_I(inode)->i_cached_extent;
cex->ec_type = type;
cex->ec_block = block;
cex->ec_len = len;
cex->ec_start = start;
+ spin_unlock(&EXT4_I(inode)->i_block_reservation_lock);
}
/*
@@ -1694,12 +1696,17 @@ ext4_ext_in_cache(struct inode *inode, e
struct ext4_extent *ex)
{
struct ext4_ext_cache *cex;
+ int ret = EXT4_EXT_CACHE_NO;
+ /*
+ * We borrow i_block_reservation_lock to protect i_cached_extent
+ */
+ spin_lock(&EXT4_I(inode)->i_block_reservation_lock);
cex = &EXT4_I(inode)->i_cached_extent;
/* has cache valid data? */
if (cex->ec_type == EXT4_EXT_CACHE_NO)
- return EXT4_EXT_CACHE_NO;
+ goto errout;
BUG_ON(cex->ec_type != EXT4_EXT_CACHE_GAP &&
cex->ec_type != EXT4_EXT_CACHE_EXTENT);
@@ -1710,11 +1717,11 @@ ext4_ext_in_cache(struct inode *inode, e
ext_debug("%u cached by %u:%u:%llu\n",
block,
cex->ec_block, cex->ec_len, cex->ec_start);
- return cex->ec_type;
+ ret = cex->ec_type;
}
prev parent reply other threads:[~2009-06-10 3:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090610001328.251476848@blue.kroah.org>
[not found] ` <20090610032135.GA19346@kroah.com>
2009-06-10 0:14 ` [patch 37/60] ext4: fix ext4_free_inode() vs. ext4_claim_inode() race Greg KH
2009-06-10 0:14 ` [patch 38/60] ext4: fix header check in ext4_ext_search_right() for deep extent trees Greg KH
2009-06-10 0:14 ` [patch 39/60] ext4: Print the find_group_flex() warning only once Greg KH
2009-06-10 0:14 ` [patch 40/60] ext4: fix bogus BUG_ONs in in mballoc code Greg KH
2009-06-10 0:14 ` [patch 41/60] ext4: fix bb_prealloc_list corruption due to wrong group locking Greg KH
2009-06-10 0:14 ` [patch 42/60] ext4: dont inherit inappropriate inode flags from parent Greg KH
2009-06-10 0:14 ` [patch 43/60] ext4: tighten restrictions on inode flags Greg KH
2009-06-10 0:14 ` [patch 44/60] ext4: return -EIO not -ESTALE on directory traversal through deleted inode Greg KH
2009-06-10 0:14 ` [patch 45/60] ext4: Add fine print for the 32000 subdirectory limit Greg KH
2009-06-10 0:14 ` [patch 46/60] ext4: add EXT4_IOC_ALLOC_DA_BLKS ioctl Greg KH
2009-06-10 0:14 ` [patch 47/60] ext4: Automatically allocate delay allocated blocks on close Greg KH
2009-06-10 0:14 ` [patch 48/60] ext4: Automatically allocate delay allocated blocks on rename Greg KH
2009-06-10 0:14 ` [patch 49/60] ext4: Fix discard of inode prealloc space with delayed allocation Greg KH
2009-06-10 0:14 ` [patch 50/60] ext4: Check for an valid i_mode when reading the inode from disk Greg KH
2009-06-10 0:14 ` [patch 51/60] jbd2: Update locking coments Greg KH
2009-06-10 0:14 ` [patch 52/60] ext4: fix typo which causes a memory leak on error path Greg KH
2009-06-10 0:14 ` [patch 53/60] ext4: fix locking typo in mballoc which could cause soft lockup hangs Greg KH
2009-06-10 0:14 ` [patch 54/60] ext4: really print the find_group_flex fallback warning only once Greg KH
2009-06-10 0:14 ` [patch 55/60] ext4: Fix softlockup caused by illegal i_file_acl value in on-disk inode Greg KH
2009-06-10 0:14 ` [patch 56/60] ext4: Ignore i_file_acl_high unless EXT4_FEATURE_INCOMPAT_64BIT is present Greg KH
2009-06-10 0:14 ` [patch 57/60] ext4: Fix sub-block zeroing for writes into preallocated extents Greg KH
2009-06-10 0:14 ` [patch 58/60] ext4: Use a fake block number for delayed new buffer_head Greg KH
2009-06-10 0:14 ` [patch 59/60] ext4: Clear the unwritten buffer_head flag after the extent is initialized Greg KH
2009-06-10 0:14 ` 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=20090610002353.503772667@blue.kroah.org \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cavokz@gmail.com \
--cc=cebbert@redhat.com \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=eteo@redhat.com \
--cc=jake@lwn.net \
--cc=jmforbes@linuxtx.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkrufky@linuxtv.org \
--cc=rbranco@la.checkpoint.com \
--cc=rdunlap@xenotime.net \
--cc=reviews@ml.cw.f00f.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=w@1wt.eu \
--cc=zwane@arm.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;
as well as URLs for NNTP newsgroup(s).