ext4: fix bh->b_state corruption
Subsystems (2)
PATCH 1/1 ext4: fix bh->b_state corruption
From: Jan Kara <[email protected]>
commit ed8ad83808f009ade97ebbf6519bc3a97fefbc0c upstream
ext4 can update bh->b_state non-atomically in _ext4_get_block() and ext4_da_get_block_prep(). Usually this is fine since bh is just a temporary storage for mapping information on stack but in some cases it can be fully living bh attached to a page. In such case non-atomic update of bh->b_state can race with an atomic update which then gets lost. Usually when we are mapping bh and thus updating bh->b_state non-atomically, nobody else touches the bh and so things work out fine but there is one case to especially worry about: ext4_finish_bio() uses BH_Uptodate_Lock on the first bh in the page to synchronize handling of PageWriteback state. So when blocksize < pagesize, we can be atomically modifying bh->b_state of a buffer that actually isn't under IO and thus can race e.g. with delalloc trying to map that buffer. The result is that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock.
Fix the problem by always updating bh->b_state bits atomically.
--- fs/ext4/inode.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-)
fs/ext4/inode.c +30 -2
@@ -657,6 +657,34 @@ has_zeroout:return retval; } +/* +* Update EXT4_MAP_FLAGS in bh->b_state. For buffer heads attached to pages +* we have to be careful as someone else may be manipulating b_state as well. +*/ +static void ext4_update_bh_state (struct buffer_head *bh,unsigned long flags) +{ +unsigned long old_state; +unsigned long new_state; + + flags &=EXT4_MAP_FLAGS ; + +/* Dummy buffer_head? Set non-atomically. */ +if (!bh->b_page) { + bh->b_state = (bh->b_state & ~EXT4_MAP_FLAGS ) | flags; +return ; + } +/* +* Someone else may be modifying b_state. Be careful! This is ugly but +* once we get rid of using bh as a container for mapping information +* to pass to / from get_block functions, this can go away. +*/ +do { + old_state =READ_ONCE (bh->b_state); + new_state = (old_state & ~EXT4_MAP_FLAGS ) | flags; + }while (unlikely ( +cmpxchg (&bh->b_state, old_state, new_state) != old_state)); +} +/* Maximum number of blocks we map for direct IO at once. */ #define DIO_MAX_BLOCKS 4096
@@ -693,7 +721,7 @@ static int _ext4_get_block(struct inode *inode, sector_t iblock,ext4_io_end_t *io_end =ext4_inode_aio (inode);map_bh (bh, inode->i_sb, map.m_pblk); - bh->b_state = (bh->b_state & ~EXT4_MAP_FLAGS ) | map.m_flags; +ext4_update_bh_state (bh, map.m_flags);if (IS_DAX (inode) &&buffer_unwritten (bh)) {/* * dgc: I suspect unwritten conversion on ext4+DAX is
@@ -1669,7 +1697,7 @@ int ext4_da_get_block_prep(struct inode *inode, sector_t iblock,return ret;map_bh (bh, inode->i_sb, map.m_pblk); - bh->b_state = (bh->b_state & ~EXT4_MAP_FLAGS ) | map.m_flags; +ext4_update_bh_state (bh, map.m_flags);if (buffer_unwritten (bh)) {/* A delayed write to unwritten bh should be marked
Signature · 1 line
2.5.0
Quoted 19 lines · Nikolay Borisov
From: Jan Kara <[email protected]>
commit
ed8ad83808f009ade97ebbf6519bc3a97fefbc0cupstreamext4 can update
bh->b_statenon-atomically in_ext4_get_block()andext4_da_get_block_prep(). Usually this is fine since bh is just a temporary storage for mapping information on stack but in some cases it can be fully living bh attached to a page. In such case non-atomic update ofbh->b_statecan race with an atomic update which then gets lost. Usually when we are mapping bh and thus updatingbh->b_statenon-atomically, nobody else touches the bh and so things work out fine but there is one case to especially worry about:ext4_finish_bio()usesBH_Uptodate_Lockon the first bh in the page to synchronize handling of PageWriteback state. So when blocksize < pagesize, we can be atomically modifyingbh->b_stateof a buffer that actually isn't under IO and thus can race e.g. with delalloc trying to map that buffer. The result is that we can mistakenly set / clearBH_Uptodate_Lockbit resulting in the corruption of PageWriteback state or missed unlock ofBH_Uptodate_Lock.
Quoted 8 lines
Fix the problem by always updating
bh->b_statebits atomically.Reported-by Nikolay Borisov <[email protected]>Signed-off-by Jan Kara <[email protected]>Signed-off-by Theodore Ts'o <[email protected]>Signed-off-by Nikolay Borisov <[email protected]>[NB: Backported to 4.4.2]
(This failed the auto backport to the 4.4 stable branch; thanks to Nikolay for backporting it.)
- Ted