The fix makes me feel a little uneasy.

It changes the behaviour of swap_page_sector() to take into account the offset. But swap_page_sector() was already used before the bug was introduced, a few lines earlier in the bdev_write_page() fast path, as introduced by this commit from 2014: https://github.com/torvalds/linux/commit/dd6bd0d9c7dbb395100...

So either:

1. The bdev_write_page() call was also broken, and has been for years, or

2. The bdev_write_page() uses the sector value differently, worked fine with the old swap_page_sector(), but is now broken with the new version, or

3. The change in swap_page_sector() somehow doesn't affect bdev_write_page(); maybe it's a noop when using swap files?

Your first point is the correct one.

Basically the offset passed to bdev_write_page() was wrong, and has been like that since it was introduced to swap code back in v3.16.

In practice this means that the same filesystem corruption could happen with swapfiles sitting on top of filesystems which are created on top of block devices that bdev_write_page() supports (in specific: brd, zram, btt, pmem). This appears to be a non-common setup that apparently was not encountered. Nevertheless the fix is being backported to all stable kernels to cover those use-cases.

edit: bdev_write_page() was never broken, just the offset handed to it was wrong.

Why do you believe that’s the commit that caused the bug?

The second commit self-disambiguates with "swap: fix swapfile read/write offset" and the commit message notes "fixes: 48d1543", which is the first linked commit.

Thanks for answering the question

Because of the commit message of the fix?