From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
linux-kernel@vger.kernel.org
Subject: Re: BUG] Strange oopses in 2.6.30
Date: Sat, 20 Jun 2009 16:40:12 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0906201626270.5322@sister.anvils> (raw)
In-Reply-To: <1245506908.6327.36.camel@localhost>
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] [<c04cd26a>] ? printk+0x18/0x1e
> > [ 34.544059] [<c018f065>] bad_page+0xd5/0x140
> > [ 34.544064] [<c0190097>] free_hot_cold_page+0x1e7/0x280
> > [ 34.544069] [<c0193682>] ? release_pages+0x92/0x1b0
> > [ 34.544074] [<c0190155>] __pagevec_free+0x25/0x30
> > [ 34.544078] [<c0193758>] release_pages+0x168/0x1b0
> > [ 34.544084] [<c0193cf3>] ? lru_add_drain+0x53/0xd0
> > [ 34.544088] [<c01ab7d4>] free_pages_and_swap_cache+0x84/0xa0
> > [ 34.544093] [<c019ff5d>] unmap_vmas+0x73d/0x760
> > [ 34.544099] [<c016480e>] ? lock_release_non_nested+0x15e/0x270
> > [ 34.544104] [<c01a43b5>] exit_mmap+0xb5/0x1b0
> > [ 34.544109] [<c0138666>] mmput+0x36/0xc0
> > [ 34.544113] [<c013c874>] exit_mm+0xe4/0x120
> > [ 34.544117] [<c0175539>] ? acct_collect+0x139/0x180
> > [ 34.544122] [<c013e889>] do_exit+0x6b9/0x720
> > [ 34.544142] [<c01bcac2>] ? vfs_write+0x122/0x180
> > [ 34.544146] [<c01bbda0>] ? do_sync_write+0x0/0x110
> > [ 34.544151] [<c013e920>] do_group_exit+0x30/0x90
> > [ 34.544156] [<c013e993>] sys_exit_group+0x13/0x20
> > [ 34.544161] [<c01039e8>] 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 <hannes@cmpxchg.org>
To: Peter Chubb <peter.chubb@nicta.com.au>
Cc: <linux-kernel@vger.kernel.org>, <mel@csn.ul.ie>, <akpm@linux-foundation.org>
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:
> [<c134a67c>] ? printk+0xf/0x13
> [<c10774dc>] bad_page+0xc9/0xe2
> [<c1078041>] free_hot_cold_page+0x5c/0x204
> [<c1078206>] __pagevec_free+0x1d/0x25
> [<c107ac3e>] release_pages+0x14e/0x18e)
> [<c108ef8a>] free_pages_and_swap_cache+0x69/0x82
> [<c1089458>] exit_mmap+0xf6/0x11f
> [<c102afcd>] mmput+0x39/0xaf
> [<c102e534>] exit_mm+0xe5/0xed
> [<c102fa66>] do_exit+0x13f/0x578
> [<c102fefd>] do_group_exit+0x5e/0x85
> [<c102ff37>] sys_exit_group+0x13/0x17
> [<c10031ef>] 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 <hannes@cmpxchg.org>
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 <peter.chubb@nicta.com.au>
Debugged-by: Peter Chubb <peter.chubb@nicta.com.au>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
---
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
next prev parent reply other threads:[~2009-06-20 15:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-19 21:48 Maxim Levitsky
2009-06-20 14:08 ` BUG] " Maxim Levitsky
2009-06-20 15:27 ` BUG: Bad page state [was: Strange oopses in 2.6.30] Jiri Slaby
2009-06-20 15:44 ` Maxim Levitsky
2009-06-22 2:39 ` KOSAKI Motohiro
2009-06-22 7:42 ` Pekka Enberg
2009-06-22 20:55 ` Mel Gorman
2009-06-22 9:16 ` Mel Gorman
2009-06-22 16:02 ` Lee Schermerhorn
2009-06-22 20:53 ` Mel Gorman
2009-06-23 11:11 ` KOSAKI Motohiro
2009-06-29 8:41 ` Mel Gorman
2009-06-29 10:18 ` Johannes Weiner
2009-06-29 10:37 ` Mel Gorman
2009-06-30 0:31 ` KOSAKI Motohiro
2009-06-30 15:11 ` Mel Gorman
2009-06-30 16:34 ` Mel Gorman
2009-06-30 23:45 ` KOSAKI Motohiro
2009-06-23 11:04 ` KOSAKI Motohiro
2009-06-20 15:40 ` Hugh Dickins [this message]
2009-06-20 19:26 ` BUG] Strange oopses in 2.6.30 Mel Gorman
2009-06-20 23:01 ` Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0906201626270.5322@sister.anvils \
--to=hugh.dickins@tiscali.co.uk \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=mel@csn.ul.ie \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®