summaryrefslogtreecommitdiffstats
path: root/fs/ubifs
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2009-05-15 09:07:28 -0400
committerTheodore Ts'o <tytso@mit.edu>2009-05-15 09:07:28 -0400
commit2ec0ae3acec47f628179ee95fe2c4da01b5e9fc4 (patch)
treef8cf43b7d3840c405dac1db3974466a2d755919a /fs/ubifs
parent2a8964d63d50dd2d65d71d342bc7fb6ef4117614 (diff)
downloadop-kernel-dev-2ec0ae3acec47f628179ee95fe2c4da01b5e9fc4.zip
op-kernel-dev-2ec0ae3acec47f628179ee95fe2c4da01b5e9fc4.tar.gz
ext4: Fix race in ext4_inode_info.i_cached_extent
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>
Diffstat (limited to 'fs/ubifs')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud