From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id E12FD6B004F for ; Tue, 16 Jun 2009 07:40:09 -0400 (EDT) Date: Tue, 16 Jun 2009 19:40:24 +0800 From: Wu Fengguang Subject: Re: [PATCH 10/22] HWPOISON: check and isolate corrupted free pages v2 Message-ID: <20090616114024.GA6185@localhost> References: <20090615024520.786814520@intel.com> <20090615031253.715406280@intel.com> <20090615184112.ed8e2f03.kamezawa.hiroyu@jp.fujitsu.com> <20090615101620.GA7216@localhost> <20090616085222.1545cc05.kamezawa.hiroyu@jp.fujitsu.com> <20090616003440.GA7329@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: KAMEZAWA Hiroyuki , Andrew Morton , LKML , Andi Kleen , Ingo Molnar , Mel Gorman , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Nick Piggin , Andi Kleen , "riel@redhat.com" , "chris.mason@oracle.com" , "linux-mm@kvack.org" List-ID: On Tue, Jun 16, 2009 at 07:29:45PM +0800, Hugh Dickins wrote: > On Tue, 16 Jun 2009, Wu Fengguang wrote: > > > > Right. Then the original __ClearPageBuddy() call in bad_page() is > > questionable, I guess this line was there just for the sake of safety > > (ie. the buddy allocator itself goes wrong): > > > > sound-2.6/mm/page_alloc.c > > > > @@ -269,7 +269,6 @@ static void bad_page(struct page *page) > > dump_stack(); > > out: > > /* Leave bad fields for debug, except PageBuddy could make trouble */ > > ===> __ClearPageBuddy(page); > > add_taint(TAINT_BAD_PAGE); > > } > > I didn't put that in for the case of the buddy allocator going wrong > (not sure if there could be such a case - I don't mean that the buddy > allocator is provably perfect! but how would it get here if it were > wrong?). No, I put that in for the case when the flag bits in struct > page have themselves got corrupted somehow, and hence we arrive at > bad_page(): most of the bits are best left as they are, to provide > maximum debug info; but leaving PageBuddy set there might conceivably > allow this corrupted struct page to get paired up with its buddy later, > and so freed for reuse, when we're trying to make sure it's never reused. Hugh, thank you for the detailed explanations! You are always informative :) Thanks, Fengguang -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org