fix corruption of hibernation caused by reusing swap at saving image
in [Kernel]
|
Prev: ext4: Don't send extra barrier during fsync if there are no dirty pages.
Next: [PATCH 1/5] staging: hv: Fixed bounce kmap problem by using correct index
From: Hugh Dickins on 5 Aug 2010 15:20 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/ |