From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org, kernel@avr32linux.org, linux-mm@kvack.org
Subject: Re: [BUG 2.6.30] Bad page map in process
Date: Fri, 10 Jul 2009 19:34:06 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0907101900570.27223@sister.anvils> (raw)
In-Reply-To: <Pine.LNX.4.64.0907081250110.15633@axis700.grange>
On Wed, 8 Jul 2009, Guennadi Liakhovetski wrote:
>
> with a 2.6.30 kernel with only platform-specific modifications and this
> avr32 patch:
>
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=bb6e647051a59dca5a72b3deef1e061d7c1c34da
>
> we're seeing kernel BUGs following an application segfault. Here's an
> example:
>
> [60254.432000] application[465]: segfault at 4377f876 pc 2aaabbde sp 7faa77f0 ecr 24
> [60255.396000] BUG: Bad page map in process application pte:13f26ed4 pmd:92fdd000
> [60255.404000] page:902c44c0 flags:0000002c count:1 mapcount:-1 mapping:9345765c index:5
> [60255.412000] addr:2ae4f000 vm_flags:08000075 anon_vma:(null) mapping:93454dd4 index:0
This is the first time I've seen one of these messages since putting it
into 2.6.29, and nice to see that it's doing its job: the info amidst the
data is that mapcount is -1 when it ought to be 0, and the mapping,index
of the page the pte points to doesn't match up with the mapping,index
which the vma intends at that address: probably the pte is corrupt.
I've not looked up avr32 pte layout, is 13f26ed4 good or bad?
I hope avr32 people can tell more about the likely cause.
Also, the addr mapped by this pte (2ae4f000) is not the address
which segfaulted (4377f876): it would have been satisfying if those
had matched up, but I don't think we can conclude anything from the
fact that they don't.
> [60255.420000] vma->vm_ops->fault: filemap_fault+0x0/0x26c
> [60255.424000] vma->vm_file->f_op->mmap: generic_file_readonly_mmap+0x0/0x18
> [60255.432000] Call trace: (exiting)
>
> Questions: can this BUG be caused by the segfault (it better not)?
It better not.
> If not, what can be the reason?
It looks like page table corruption.
> The problem occurs sporadically, I've only had one
> such case since yesterday. Yet one more application segfault last night
> didn't produce a BUG.
I think page table corruption is causing segfaults, and page table
corruption is causing "Bad page map"s when the app exits. Yes,
sometimes you'll see one, sometimes the other, sometimes both.
More might be learnt by comparing all the different such messages
you've seen: for example, we're now printing the "pmd" there, in
case it emerges that all such errors occur in or near the same
physical address.
> This is with a kernel configured with SLAB. With
> SLUB we also observed similar BUGs on application exit but without signal
> handling path in the backtrace. But, I think, I've had other problems with
> SLUB before, so, we switched back to SLAB for now...
I wouldn't read too much into the SLAB versus SLUB difference here,
suspect just coincidence; but I could be horribly wrong.
Hugh
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-07-10 18:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-08 11:07 [BUG 2.6.30] Bad page map in process Guennadi Liakhovetski
2009-07-08 11:23 ` Hans-Christian Egtvedt
2009-07-08 12:28 ` Guennadi Liakhovetski
2009-07-10 18:34 ` Hugh Dickins [this message]
2009-07-12 7:57 ` Haavard Skinnemoen
2009-07-12 19:59 ` Guennadi Liakhovetski
[not found] ` <1DC0FF5051B91B4D88A15F21F1A27F417ABDE6@dware1013.doorway.loc>
2009-07-13 11:14 ` SV: " Guennadi Liakhovetski
2009-07-13 11:56 ` Hugh Dickins
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.0907101900570.27223@sister.anvils \
--to=hugh.dickins@tiscali.co.uk \
--cc=g.liakhovetski@gmx.de \
--cc=kernel@avr32linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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;
as well as URLs for NNTP newsgroup(s).