On Wed, Jun 28, 2023 at 05:31:40PM +0200, Christoph Hellwig wrote:
> compress_file_range needs to clear the dirty bit before handing off work
> to the compression worker threads to prevent processes coming in through
> mmap and changing the file contents while the compression is accessing
> the data (See commit 4adaa611020f ("Btrfs: fix race between mmap writes
> and compression").
>
> But when compress_file_range decides to not compress the data, it falls
> back to submit_uncompressed_range which uses extent_write_locked_range
> to write the uncompressed data. extent_write_locked_range currently
> expects all pages to be marked dirty so that it can clear the dirty
> bit itself, and thus compress_file_range has to redirty the page range.
>
> Redirtying the page range is rather inefficient and also pointless,
> so instead pass a pages_dirty parameter to extent_write_locked_range
> and skip the redirty game entirely.
>
> Note that compress_file_range was even redirtying the locked_page twice
> given that extent_range_clear_dirty_for_io already redirties all pages
> in the range, which must include locked_page if there is one.
This is probably the only scary patch in the series. I don't see
anything obviously wrong, the reditrying logic added due to the mmap
case is preserved.
