On Mon, Jul 01, 2013 at 05:13:55AM -0400, Chen Gong wrote: > On Fri, May 17, 2013 at 12:18:02PM -0400, Naoya Horiguchi wrote: > > Date: Fri, 17 May 2013 12:18:02 -0400 > > From: Naoya Horiguchi <n-horigu...@ah.jp.nec.com> > > To: linux...@kvack.org > > Cc: Andrew Morton <a...@linux-foundation.org>, Andi Kleen > > <a...@firstfloor.org>, linux-kernel@vger.kernel.org, Naoya Horiguchi > > <n-horigu...@ah.jp.nec.com> > > Subject: [PATCH] mm/memory-failure.c: fix memory leak in successful soft > > offlining > > > > After a successful page migration by soft offlining, the source page is > > not properly freed and it's never reusable even if we unpoison it afterward. > > > > This is caused by the race between freeing page and setting PG_hwpoison. > > In successful soft offlining, the source page is put (and the refcount > > becomes 0) by putback_lru_page() in unmap_and_move(), where it's linked to > > pagevec and actual freeing back to buddy is delayed. So if PG_hwpoison is > > set for the page before freeing, the freeing does not functions as expected > > (in such case freeing aborts in free_pages_prepare() check.) > > > > This patch tries to make sure to free the source page before setting > > PG_hwpoison on it. To avoid reallocating, the page keeps MIGRATE_ISOLATE > > until after setting PG_hwpoison. > > > > This patch also removes obsolete comments about "keeping elevated refcount" > > because what they say is not true. Unlike memory_failure(), > > soft_offline_page() > > uses no special page isolation code, and the soft-offlined pages have no > > difference from buddy pages except PG_hwpoison. So no need to keep refcount > > elevated. > > > > Signed-off-by: Naoya Horiguchi <n-horigu...@ah.jp.nec.com> > > --- ... > Hi, Naoya > > What happens about this patch? It looks find to me but not merged yet. > If something I missed, would you please tell me again?
Hello Gong, It's already on mmotm, so I hope Andrew will push it in this merge window (just opened yesterday.) Thanks, Naoya Horiguchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
