]> git.baikalelectronics.ru Git - kernel.git/commit
ext4: ext4_read_bh_lock() should submit IO if the buffer isn't uptodate
authorZhang Yi <yi.zhang@huawei.com>
Wed, 31 Aug 2022 07:46:29 +0000 (15:46 +0800)
committerTheodore Ts'o <tytso@mit.edu>
Sat, 1 Oct 2022 03:46:51 +0000 (23:46 -0400)
commit7c673e0943fad3d4889a3991a5a643fac12049b0
tree85d14a3add2edbc37fde0ce0bd426a1c7558f23c
parentb9d0dcb412674adf34a2dc2858c009c717cfdcf1
ext4: ext4_read_bh_lock() should submit IO if the buffer isn't uptodate

Recently we notice that ext4 filesystem would occasionally fail to read
metadata from disk and report error message, but the disk and block
layer looks fine. After analyse, we lockon commit e1b215781d1e
("blkdev: avoid migration stalls for blkdev pages"). It provide a
migration method for the bdev, we could move page that has buffers
without extra users now, but it lock the buffers on the page, which
breaks the fragile metadata read operation on ext4 filesystem,
ext4_read_bh_lock() was copied from ll_rw_block(), it depends on the
assumption of that locked buffer means it is under IO. So it just
trylock the buffer and skip submit IO if it lock failed, after
wait_on_buffer() we conclude IO error because the buffer is not
uptodate.

This issue could be easily reproduced by add some delay just after
buffer_migrate_lock_buffers() in __buffer_migrate_folio() and do
fsstress on ext4 filesystem.

  EXT4-fs error (device pmem1): __ext4_find_entry:1658: inode #73193:
  comm fsstress: reading directory lblock 0
  EXT4-fs error (device pmem1): __ext4_find_entry:1658: inode #75334:
  comm fsstress: reading directory lblock 0

Fix it by removing the trylock logic in ext4_read_bh_lock(), just lock
the buffer and submit IO if it's not uptodate, and also leave over
readahead helper.

Cc: stable@kernel.org
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20220831074629.3755110-1-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fs/ext4/super.c