On Wed 12-04-23 00:47:37, JunChao Sun wrote: > From: sunjunchao <sunjunchao@xxxxxxxxxxxxxx> > > There is a BUG_ON statement which will be triggered in the > following scenario, let's remove it. > > thread0 thread1 > ext4_write_begin(inode0) > ->ext4_try_to_write_inline_data() > written some bits successfully > ext4_write_end(inode0) > ->ext4_write_inline_data_end() > ext4_write_begin(inode0) > ->ext4_try_to_write_inline_data() > ->ext4_convert_inline_data_to_extent() > ->ext4_write_lock_xattr() > ->ext4_destroy_inline_data_nolock() > ->ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA); > ->ext4_write_unlock_xattr() > ->ext4_write_lock_xattr() > ->BUG_ON(!ext4_has_inline_data()) will be triggered > > The problematic logic is that ext4_write_end() test ext4_has_inline_data() > without holding xattr_sem, and ext4_write_inline_data_end() test it again using > a BUG_ON() with holding xattr_sem. Were you able to actually hit this? Because inode->i_rwsem should be protecting us from races like this so I don't think the above described scenario can happen. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
