mbox series

[0/2] fixes for btrfs_read_folio races

Message ID cover.1734131353.git.boris@bur.io (mailing list archive)
Headers show
Series fixes for btrfs_read_folio races | expand

Message

Boris Burkov Dec. 13, 2024, 11:13 p.m. UTC
We have a common pattern of getting a folio (locked) checking if it is
uptodate, then reading it with btrfs_read_folio if it is not.

btrfs_read_folio returns the folio unlocked, so we immediately lock it
again with folio_lock. However, in the time that it is unlocked, a
different thread can modify folio->mapping (like set it NULL with
an invalidate) so we must also check that folio->mapping is still what
we expect after folio_lock. Most users of btrfs_read_folio do it
correctly (retry on mismatched folio->mapping), and this series tidies
up a couple that were doing it wrong.

Boris Burkov (2):
  btrfs: fix btrfs_read_folio race in relocation
  btrfs: fix btrfs_read_folio race in send

 fs/btrfs/relocation.c | 6 ++++++
 fs/btrfs/send.c       | 6 ++++++
 2 files changed, 12 insertions(+)

Comments

Qu Wenruo Dec. 13, 2024, 11:17 p.m. UTC | #1
在 2024/12/14 09:43, Boris Burkov 写道:
> We have a common pattern of getting a folio (locked) checking if it is
> uptodate, then reading it with btrfs_read_folio if it is not.
> 
> btrfs_read_folio returns the folio unlocked, so we immediately lock it
> again with folio_lock. However, in the time that it is unlocked, a
> different thread can modify folio->mapping (like set it NULL with
> an invalidate) so we must also check that folio->mapping is still what
> we expect after folio_lock. Most users of btrfs_read_folio do it
> correctly (retry on mismatched folio->mapping), and this series tidies
> up a couple that were doing it wrong.

Reviewed-by: Qu Wenruo <wqu@suse.com>

Thanks,
Qu

> 
> Boris Burkov (2):
>    btrfs: fix btrfs_read_folio race in relocation
>    btrfs: fix btrfs_read_folio race in send
> 
>   fs/btrfs/relocation.c | 6 ++++++
>   fs/btrfs/send.c       | 6 ++++++
>   2 files changed, 12 insertions(+)
>