Re: [PATCH] btrfs: fix a race between reflink and compressed writes

[Breno Leitao <leitao@debian.org>]

Hello Qu,

On Thu, Nov 05, 2026 at 11:38:00AM +1030, Qu Wenruo wrote:
> Do not clear the folio dirty early during compress_file_range().
> 
> The early clearing is done through extent_range_clear_dirty_for_io(), so
> remove the folio dirty clearing completely from it.
> 
> And since what's left is only checking the folio write protection,
> rename the function to extent_range_check_write_protected() instead, and
> slightly clean it up, so it doesn't need to return an int.
> 
> Finally since the range is still dirty now, all run_delalloc_cow()
> callers pass @pages_dirty = true, we can remove that parameter along other
> involved functions.
> 
> Fixes: 1d2fbb7f1f9e ("btrfs: allow compression even if the range is not page aligned")
> Reported-by: Breno Leitao <leitao@debian.org>
> Link: https://lore.kernel.org/linux-btrfs/ause7k_HjzUWT3D-@gmail.com/
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Thanks for the quick fix.  I ran the reproducer against next-20261104 with
and without this patch, on arm64, compress-force=zstd:3 (compress=zstd:3
for the compress mode), and CONFIG_BTRFS_DEBUG and CONFIG_BTRFS_ASSERT
enabled:

  pages            run.sh mode   without the patch       with the patch
  64K              clone         stale read after 2s     clean for 600s
  64K              clone -d      read-only after 2s      clean for 300s
  64K              compress      stale read after 2s     clean for 300s
  64K              inline        deadlock after 32s      clean for 300s
  4K, large folio  clone         stale read after 26s    clean for 600s
  4K, large folio  clone -d      read-only after 2s      clean for 300s
  4K, large folio  compress      stale read after 16s    clean for 300s

I've also run fstests (-g clone,compress,punch,fiemap with
compress-force) give the same results with and without the patch, with
no new warnings.

Tested-by: Breno Leitao <leitao@debian.org>