Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753309AbZFTPlU (ORCPT ); Sat, 20 Jun 2009 11:41:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752143AbZFTPlL (ORCPT ); Sat, 20 Jun 2009 11:41:11 -0400 Received: from mk-filter-1-a-1.mail.uk.tiscali.com ([212.74.100.52]:58347 "EHLO mk-filter-1-a-1.mail.uk.tiscali.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593AbZFTPlK (ORCPT ); Sat, 20 Jun 2009 11:41:10 -0400 X-Trace: 218514785/mk-filter-1.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/80.41.111.70/None/hugh.dickins@tiscali.co.uk X-SBRS: None X-RemoteIP: 80.41.111.70 X-IP-MAIL-FROM: hugh.dickins@tiscali.co.uk X-SMTP-AUTH: X-MUA: X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACagPEpQKW9G/2dsb2JhbACBUcp4hAkF X-IronPort-AV: E=Sophos;i="4.42,259,1243810800"; d="scan'208";a="218514785" Date: Sat, 20 Jun 2009 16:40:12 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@sister.anvils To: Maxim Levitsky cc: Johannes Weiner , Mel Gorman , linux-kernel@vger.kernel.org Subject: Re: BUG] Strange oopses in 2.6.30 In-Reply-To: <1245506908.6327.36.camel@localhost> Message-ID: References: <1245448091.5475.19.camel@localhost> <1245506908.6327.36.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6674 Lines: 170 On Sat, 20 Jun 2009, Maxim Levitsky wrote: > On Sat, 2009-06-20 at 00:48 +0300, Maxim Levitsky wrote: > > I see lots of following oopses in 2.6.30 and latest -git > > > > Many different applications shows up, not just reiserfsck > > Something in MM I guess, it makes me worry. But system seems to work. > > > > Is this known? I think so... > > > > dmesg attached. > > > > > > [ 34.544040] BUG: Bad page state in process reiserfsck pfn:37d86 > > [ 34.544044] page:c2a34f38 flags:3650000c count:0 mapcount:0 > > mapping:(null) index:bffeb > > [ 34.544048] Pid: 2654, comm: reiserfsck Tainted: G B > > 2.6.30-git #4 > > [ 34.544051] Call Trace: > > [ 34.544055] [] ? printk+0x18/0x1e > > [ 34.544059] [] bad_page+0xd5/0x140 > > [ 34.544064] [] free_hot_cold_page+0x1e7/0x280 > > [ 34.544069] [] ? release_pages+0x92/0x1b0 > > [ 34.544074] [] __pagevec_free+0x25/0x30 > > [ 34.544078] [] release_pages+0x168/0x1b0 > > [ 34.544084] [] ? lru_add_drain+0x53/0xd0 > > [ 34.544088] [] free_pages_and_swap_cache+0x84/0xa0 > > [ 34.544093] [] unmap_vmas+0x73d/0x760 > > [ 34.544099] [] ? lock_release_non_nested+0x15e/0x270 > > [ 34.544104] [] exit_mmap+0xb5/0x1b0 > > [ 34.544109] [] mmput+0x36/0xc0 > > [ 34.544113] [] exit_mm+0xe4/0x120 > > [ 34.544117] [] ? acct_collect+0x139/0x180 > > [ 34.544122] [] do_exit+0x6b9/0x720 > > [ 34.544142] [] ? vfs_write+0x122/0x180 > > [ 34.544146] [] ? do_sync_write+0x0/0x110 > > [ 34.544151] [] do_group_exit+0x30/0x90 > > [ 34.544156] [] sys_exit_group+0x13/0x20 > > [ 34.544161] [] sysenter_do_call+0x12/0x3c > > [ 34.544180] BUG: Bad page state in process reiserfsck pfn:37d91 > > [ 34.544184] page:c2a35174 flags:3650000c count:0 mapcount:0 > > mapping:(null) index:bfff6 > > [ 34.544188] Pid: 2654, comm: reiserfsck Tainted: G B > > 2.6.30-git #4 > > > > This really worries me I hope it's fixed by this patch Hannes posted yesterday... >From hannes@cmpxchg.org Fri Jun 19 19:04:49 2009 Date: Fri, 19 Jun 2009 19:45:02 +0200 From: Johannes Weiner To: Peter Chubb Cc: , , Subject: Re: [BUG] Bad page flags when process using mlock()ed memory exits On Fri, Jun 19, 2009 at 02:11:21PM +1000, Peter Chubb wrote: > > In recent kernels I've been seeing many mesages of the form: > > BUG: Bad page state in process reiserfsck pfn:79c58 > page:c3d03b00 flags:8050000c count:0 mapcount:0 mapping:(null) index:8095 > Pid: 3927, comm: reiserfsck Not tainted 2.6.30-test-05456-gda456f1 #60 > Call Trace: > [] ? printk+0xf/0x13 > [] bad_page+0xc9/0xe2 > [] free_hot_cold_page+0x5c/0x204 > [] __pagevec_free+0x1d/0x25 > [] release_pages+0x14e/0x18e) > [] free_pages_and_swap_cache+0x69/0x82 > [] exit_mmap+0xf6/0x11f > [] mmput+0x39/0xaf > [] exit_mm+0xe5/0xed > [] do_exit+0x13f/0x578 > [] do_group_exit+0x5e/0x85 > [] sys_exit_group+0x13/0x17 > [] sysenter_do_call+0x12/0x3c > Disabling lock debugging due to kernel taint > > This appears to have been introduced by patch > da456f14d2f2d7350f2b9440af79c85a34c7eed5 > page allocator: do not disable interrupts in free_page_mlock() > > That patch removed the free_page_mlock() from free_pages_check(), so > if free_hot_cold_page() is called on an Mlocked page (e.g., if a > process that used mlock() calls exit()) free_pages_check() will always > barf, whereas before it would just unlock the page. I prepared a fix, thanks for chasing it down. Mel, to keep this simple I just used the atomic test-clear, but if I am not mistaken we should not need any atomicity here, so we could probably add a __TestClearPage version and use this instead...? --- >From 493b74e8615db4e3323b5b169b0b8265dfd7c3f4 Mon Sep 17 00:00:00 2001 From: Johannes Weiner Date: Fri, 19 Jun 2009 19:30:56 +0200 Subject: [patch] mm: page_alloc: clear PG_locked before checking flags on free da456f1 "page allocator: do not disable interrupts in free_page_mlock()" moved the PG_mlocked clearing after the flag sanity checking which makes mlocked pages always trigger 'bad page'. Fix this by clearing the bit up front. Reported-by: Peter Chubb Debugged-by: Peter Chubb Signed-off-by: Johannes Weiner Cc: Mel Gorman --- mm/page_alloc.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6f0753f..30d5093 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -488,7 +488,6 @@ static inline void __free_one_page(struct page *page, */ static inline void free_page_mlock(struct page *page) { - __ClearPageMlocked(page); __dec_zone_page_state(page, NR_MLOCK); __count_vm_event(UNEVICTABLE_MLOCKFREED); } @@ -558,7 +557,7 @@ static void __free_pages_ok(struct page *page, unsigned int order) unsigned long flags; int i; int bad = 0; - int clearMlocked = PageMlocked(page); + int wasMlocked = TestClearPageMlocked(page); kmemcheck_free_shadow(page, order); @@ -576,7 +575,7 @@ static void __free_pages_ok(struct page *page, unsigned int order) kernel_map_pages(page, 1 << order, 0); local_irq_save(flags); - if (unlikely(clearMlocked)) + if (unlikely(wasMlocked)) free_page_mlock(page); __count_vm_events(PGFREE, 1 << order); free_one_page(page_zone(page), page, order, @@ -1022,7 +1021,7 @@ static void free_hot_cold_page(struct page *page, int cold) struct zone *zone = page_zone(page); struct per_cpu_pages *pcp; unsigned long flags; - int clearMlocked = PageMlocked(page); + int wasMlocked = TestClearPageMlocked(page); kmemcheck_free_shadow(page, 0); @@ -1041,7 +1040,7 @@ static void free_hot_cold_page(struct page *page, int cold) pcp = &zone_pcp(zone, get_cpu())->pcp; set_page_private(page, get_pageblock_migratetype(page)); local_irq_save(flags); - if (unlikely(clearMlocked)) + if (unlikely(wasMlocked)) free_page_mlock(page); __count_vm_event(PGFREE); -- 1.6.3 -- 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/