Prev: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn)
Next: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Andrew Morton on 4 Aug 2010 18:20
On Wed, 4 Aug 2010 13:57:39 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:

> At taking memory snapshot in hibernate_snapshot(), all (directly called)
> memory allocator uses GFP_ATOMIC. And it seems swap-misusage during
> hibernation never occurs.
>
> But, from pessimistic point of view, there is no guarantee to trust
> any page allcation doesn't have __GFP_WAIT. It's better to have an indication
> "we enter hibernation, don't use swap!".
>
> This patch tries to freeze new-swap-allocation during hibernation.
> (We can trust all user processes are freezed, then, dont't take care of swapin)
>
> By this, no updates will be happen to swap_map[] among hibernate_snapshot()
> to save_image(). swap is thawed when swsusp_free() is called.
> We can trust swap-corruption will never happen without any doubts.
>

Confused (as usual).

The above seems to be saying "there isn't a bug, but perhaps there is
one that we don't know about so let's fix it in case it's there". Or
something.

But this email thread used to be called "Memory corruption during
hibernation since 2.6.31" which sounds a heck of a lot more serious.

Does this patch fix memory corruption? If so, why was that corruption
occurring, and under which circumstances?

Once all this is known, let's decide whether -stable needs this patch.
--
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/
From: KAMEZAWA Hiroyuki on 4 Aug 2010 20:40
On Wed, 4 Aug 2010 15:18:39 -0700
Andrew Morton <akpm(a)linux-foundation.org> wrote:

> On Wed, 4 Aug 2010 13:57:39 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
>
> > At taking memory snapshot in hibernate_snapshot(), all (directly called)
> > memory allocator uses GFP_ATOMIC. And it seems swap-misusage during
> > hibernation never occurs.
> >
> > But, from pessimistic point of view, there is no guarantee to trust
> > any page allcation doesn't have __GFP_WAIT. It's better to have an indication
> > "we enter hibernation, don't use swap!".
> >
> > This patch tries to freeze new-swap-allocation during hibernation.
> > (We can trust all user processes are freezed, then, dont't take care of swapin)
> >
> > By this, no updates will be happen to swap_map[] among hibernate_snapshot()
> > to save_image(). swap is thawed when swsusp_free() is called.
> > We can trust swap-corruption will never happen without any doubts.
> >
>
> Confused (as usual).
>
Sorry
> The above seems to be saying "there isn't a bug, but perhaps there is
> one that we don't know about so let's fix it in case it's there". Or
> something.
>
> But this email thread used to be called "Memory corruption during
> hibernation since 2.6.31" which sounds a heck of a lot more serious.
>
> Does this patch fix memory corruption? If so, why was that corruption
> occurring, and under which circumstances?
>
The corruption we see now is fixed by
mm-fix-corruption-of-hibernation-caused-by-reusing-swap-during-image-saving.patch
This patch disables swap-reuse by the hibernation code itself and fixes the bug.

But, IIUC, comments from reviewer was "it looks like a temporary-fix. It will work
and be good for backporting...but can't we have a permanent fix which never be
broken by anyone ?"

IOW, the patch doesn't stop get_swap_page() because we believe all
subsystems related to hibernation works well _now_ and everyone use GFP_ATOMIC.

However, hibernation is a set of complex features. It's coded very carefully and
works well but no one can't see the all of codes in subsystems. So, some safe
system is better rather than believing.

(BTW, one of reasons we can believe we are safe is that critical threads have
to be frozen before creating snapshot.)

For example, for guaranteeing gfp_mask, we have
clear_gfp_allowed_mask()
set_gfp_allowed_mask()
and clears __GFP_IO|__GFP_FS from all allocation requests via alloc_pages, slab,
slub etc even if someone use a gfp_mask other than GFP_ATOMIC.
These code is for notifying memory allocator that "hibernation is running!".

The idea of this patch is notifying swap-allocator that "hibernation is running!"
(With this, we can believe ourselves even if some tainted modules are loaded.)

This patch's purpose is adding a safe system rather than believing no one does
bad thing. Fortunately, disallowing using swap is easy.



Thanks,
-Kame






--
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/
 | 
Pages: 1
Prev: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn)
Next: [PATCH] platform: Facilitate the creation of pseduo-platform busses