Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757937AbZFPLlD (ORCPT ); Tue, 16 Jun 2009 07:41:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754731AbZFPLky (ORCPT ); Tue, 16 Jun 2009 07:40:54 -0400 Received: from mga03.intel.com ([143.182.124.21]:30526 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753248AbZFPLkx (ORCPT ); Tue, 16 Jun 2009 07:40:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.42,228,1243839600"; d="scan'208";a="155047442" Date: Tue, 16 Jun 2009 19:40:24 +0800 From: Wu Fengguang 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" 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: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1655 Lines: 36 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/