Re: [PATCH] i386: For debugging, make the initial page table setup less forgiving.

From: Eric W. Biederman
Date: Wed Apr 25 2007 - 13:52:13 EST


"H. Peter Anvin" <hpa@xxxxxxxxx> writes:

> Andrew Morton wrote:
>
>>
>> This patch causes oopses after a minute or so running LTP's
>>
>> ./testcases/bin/growfiles -W gf16 -b -e 1 -i 0 -L 120 -u -g 4090 -T 100 -t
> 408990 -l -C 10 -c 1000 -S 10 -f Lgf02_
>>
>> on everyone's favoutite Vaio, configured with
>> http://userweb.kernel.org/~akpm/config-sony.txt
>>
>
> *BLINK*
>
> This patch only affects the initial page tables, which should have been
> thrown out *way* long ago at this point.

Yes. I noticed this was happening a few days ago.
I must not have mentioned it loudly enough.

> Yet they seem to have stuck around. This is a very bad thing on many
> levels, especially since we should have switched the kernel 1:1 area
> over to PSE pages a long time ago.

Yep. We don't continue to use the early page table pages if you
enable PAE, but otherwise we do.

Which also gives us potential permission issues with the initial page
tables.

>> BUG: unable to handle kernel paging request at virtual address c084fa8c
>> printing eip:
>> c0174c46
>> *pde = 0042a027
>> *pte = 00000000
>
> Touching a non-PSE page which is zero, and quite consistent with being a
> remnant from the original page tables.
>
> Methinks this has smoked out a bug in the initial page table setup which
> probably has been a performance roadblock for quite some time.

Yes our initial page table setup on arch/i386 is full of issues.

I'm halfway through putting together a patchset to address a
bunch of these.

I haven't yet resolved how I want to allocate the pages for the
identity mapping of the page table yet. I can't use the bootmem
allocate as it exists because that assumes the page is mapped
into the address space already.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/