This program causes an instant panic for me:
#include <sys/mman.h>
int main(int argc, char **argv)
{
munmap((char *)(((unsigned long)&argc) & ~4095), 4096*2);
return 0;
}
I'm not sure if setting the signal handler is necessary or not. My
environment is largeish, so the stack is 2 pages; you might need to
adjust it.
There's a message on the console saying something like "panic: bad pgd:
0x00000e13". It was a bit too quick to see.
Plain 2.6.10 segfaults as expected; I haven't tried -mm1 to see what it
does.
Config attached.
J
On Mon, 2005-01-10 at 16:01 -0800, Jeremy Fitzhardinge wrote:
> I'm not sure if setting the signal handler is necessary or not.
The first version of this code set a SIGSEGV handler, but the panic
happens without it.
J
On Mon, Jan 10, 2005 at 04:01:58PM -0800, Jeremy Fitzhardinge wrote:
> This program causes an instant panic for me:
> #include <sys/mman.h>
> int main(int argc, char **argv)
> {
> munmap((char *)(((unsigned long)&argc) & ~4095), 4096*2);
>
> return 0;
> }
> I'm not sure if setting the signal handler is necessary or not. My
> environment is largeish, so the stack is 2 pages; you might need to
> adjust it.
> There's a message on the console saying something like "panic: bad pgd:
> 0x00000e13". It was a bit too quick to see.
> Plain 2.6.10 segfaults as expected; I haven't tried -mm1 to see what it
> does.
> Config attached.
$ grep -nr pgd_ERROR .
./arch/i386/kernel/vm86.c:151: pgd_ERROR(*pgd);
./arch/arm/mm/fault-armv.c:67: pgd_ERROR(*pgd);
./arch/sh/mm/init.c:94: pgd_ERROR(*pgd);
./arch/m68k/atari/stram.c:679: pgd_ERROR(*dir);
./arch/ppc64/mm/init.c:327: pgd_ERROR(*dir);
./arch/parisc/kernel/pci-dma.c:206: pgd_ERROR(*dir);
./arch/parisc/mm/kmap.c:116: pgd_ERROR(*dir);
./mm/swapfile.c:530: pgd_ERROR(*pgd);
./mm/msync.c:106: pgd_ERROR(*pgd);
./mm/memory.c:162: pgd_ERROR(*pgd);
./mm/memory.c:446: pgd_ERROR(*src_pgd);
./mm/memory.c:580: pgd_ERROR(*pgd);
./mm/vmalloc.c:95: pgd_ERROR(*pgd);
./mm/mprotect.c:100: pgd_ERROR(*pgd);
(includes etc.)
Anyway, it's blatant pagetable corruption. Does binary searching -mm2
reveal anything?
-- wli
Jeremy Fitzhardinge <[email protected]> wrote:
>
> This program causes an instant panic for me:
>
> #include <sys/mman.h>
>
> int main(int argc, char **argv)
> {
> munmap((char *)(((unsigned long)&argc) & ~4095), 4096*2);
>
> return 0;
> }
I dont' seem to be able to get it to do anything bad at all, with current
-linus or with the current -mm lineup. Can you retest -mm3 when it's
cooked?
Jeremy Fitzhardinge <[email protected]> writes:
> This program causes an instant panic for me:
>
> #include <sys/mman.h>
>
> int main(int argc, char **argv)
> {
> munmap((char *)(((unsigned long)&argc) & ~4095), 4096*2);
>
> return 0;
> }
I think Linus already fixed that. Can you try the latest -BK?
It's a fallout of the new clear_page_tables()
-Andi
On Mon, Jan 10, 2005 at 04:01:58PM -0800, Jeremy Fitzhardinge wrote:
> This program causes an instant panic for me:
> #include <sys/mman.h>
> int main(int argc, char **argv)
> {
> munmap((char *)(((unsigned long)&argc) & ~4095), 4096*2);
> return 0;
> }
> Plain 2.6.10 segfaults as expected; I haven't tried -mm1 to see what it
> does.
I get an instant reboot with 2.6.10-mm2 and 2.6.10-mm1 with one page.
2.6.10-rc3-mm1 just segfaults as expected.
--
Frank - my stupid blog: http://00f.net