3 ms·

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

by N48 6y ago

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/dd6bd0d9c7dbb3951005db4e424abbd37c4ff801 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?

kerneltrap 6y ago
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.