On Tue, 18 Nov 2014 16:51:36 +0800 Weijie Yang <[email protected]> wrote:
> If a frontswap dup-store failed, it should invalidate the expired page
> in the backend, or it could trigger some data corruption issue.
> Such as:
> 1. use zswap as the frontswap backend with writeback feature
> 2. store a swap page(version_1) to entry A, success
> 3. dup-store a newer page(version_2) to the same entry A, fail
> 4. use __swap_writepage() write version_2 page to swapfile, success
> 5. zswap do shrink, writeback version_1 page to swapfile
> 6. version_2 page is overwrited by version_1, data corrupt.
>
> This patch fixes this issue by invalidating expired data immediately
> when meet a dup-store failure.
>
> ...
>
> --- a/mm/frontswap.c
> +++ b/mm/frontswap.c
> @@ -244,8 +244,10 @@ int __frontswap_store(struct page *page)
> the (older) page from frontswap
> */
> inc_frontswap_failed_stores();
> - if (dup)
> + if (dup) {
> __frontswap_clear(sis, offset);
> + frontswap_ops->invalidate_page(type, offset);
> + }
> }
> if (frontswap_writethrough_enabled)
> /* report failure so swap also writes to swap device */
I tagged this for backporting into -stable kernels. Please shout at me
if you think that was inappropriate.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
