From: Hugh Dickins on
On Tue, Aug 3, 2010 at 7:46 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
> On Wed, 4 Aug 2010 11:31:22 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
>
>> On Wed, 4 Aug 2010 10:50:54 +0900
>> KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
>>
>> > This patch is created against 2.6.35. CC'ed stable.
>> > Thank you for all helps.
>> >
>>
>> I'm sorry I now doubt this patch is wrong.
>
> Changed the description.
> Maybe the patch description/my understanding was wrong
> but the patch itself should work.
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com>
>
> Since 2.6.31, swap_map[]'s refcounting was changed to show that
> a used swap entry is just for swap-cache, can be reused.
> Then, while scanning free entry in swap_map[], a swap entry may
> be able to be reclaimed and reused. It was by the commit
> c9e444103b5e7a5a3519f9913f59767f92e33baf.
>
> But this caused deta corruption at resume.
> The scenario is
>        - Assume a clean-swap cache, but mapped.
>        - at hibernation_snapshot[], clean-swap-cache is saved as
>          clean-swap-cache and swap_map[] is marked as SWAP_HAS_CACHE.
>        - then, save_image() is called. And reuse SWAP_HAS_CACHE entry
>          to save image, and break the contents.
>        After resume.
>        - the memory reclaim runs and finds clean-not-referenced-swap-cache
>          and discards it because it's marked as clean.
>          But here, the contents on disk and swap-cache is inconsistent.
>
> Here, memory is corrupted.

Yes, that's the scenario: I thought that was what you meant by your
original description, but this more detailed description is a better
one.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/