lkml.org 
[lkml]   [2007]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] i386: For debugging, make the initial page table setup less forgiving.
On Fri, 13 Apr 2007 14:49:57 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:

> We just discovered that the accounting for initial memory usage
> (head.S: INIT_MAP_BEYOND_END) has been way, way off for a very long
> time. This patch makes the initial page table not round up to the
> nearest 4M boundary, but instead stop dead (and zero the rest of the
> final page table) as soon as it hits the configured limit.
>
> This patch is intended as a debugging aid. If it goes into the
> kernel, it should go in at the very beginning of a review cycle, as it
> may very well expose real failures (without Jeremy's patch to fix the
> accounting, it *will* crash.)
>
> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>
> diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
> index 3fa7f93..db6735a 100644
> --- a/arch/i386/kernel/head.S
> +++ b/arch/i386/kernel/head.S
> @@ -131,15 +131,27 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
> movl %ecx,page_pde_offset(%edx) /* Store kernel PDE entry */
> addl $4,%edx
> movl $1024, %ecx
> + /*
> + * End condition: we must map up to and including
> + * INIT_MAP_BEYOND_END bytes beyond the end of our
> + * own page tables; 0x1000 is the size of the page
> + * table were about to write, and +0x007 is the
> + * attribute bits.
> + */
> + leal (INIT_MAP_BEYOND_END+0x1000+0x007)(%edi),%ebp
> 11:
> stosl
> addl $0x1000,%eax
> - loop 11b
> - /* End condition: we must map up to and including INIT_MAP_BEYOND_END */
> - /* bytes beyond the end of our own page tables; the +0x007 is the attribute bits */
> - leal (INIT_MAP_BEYOND_END+0x007)(%edi),%ebp
> cmpl %ebp,%eax
> - jb 10b
> + jae 12f
> + loop 11b
> + jmp 10b
> +12:
> + /* Clear the remainder of the last page table */
> + decl %ecx
> + xorl %eax,%eax
> + rep; stosl
> +
> movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
>
> xorl %ebx,%ebx /* This is the boot CPU (BSP) */

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

BUG: unable to handle kernel paging request at virtual address c084fa8c
printing eip:
c0174c46
*pde = 0042a027
*pte = 00000000
Oops: 0002 [#1]
Modules linked in: ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs button battery asus_acpi ac nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss sr_mod snd_pcm cdrom ieee80211 ieee80211_crypt snd_timer piix snd soundcore snd_page_alloc i2c_i801 generic i2c_core pcspkr ext3 jbd ide_disk ide_core
CPU: 0
EIP: 0060:[<c0174c46>] Not tainted VLI
EFLAGS: 00010212 (2.6.21-rc7 #13)
EIP is at __block_prepare_write+0x246/0x445
eax: 00000000 ebx: c084f000 ecx: 0000015d edx: 00000574
esi: 00000000 edi: c084fa8c ebp: 00000000 esp: f51e3bc8
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process growfiles (pid: 2913, ti=f51e2000 task=f5f31340 task.ti=f51e2000)
Stack: c08317b8 00000001 0000000a 00000000 c08317f0 f6c0f9b0 00000980 00000574
f58953d8 00000000 c10109e0 f7dbb0d8 00005e1a 00000000 00001000 c08317b8
f51e3c24 fffff000 00000000 01000286 00001000 00001000 0000000a f58953d8
Call Trace:
[<c0174e67>] block_prepare_write+0x22/0x30
[<f8b853b8>] ext3_get_block+0x0/0xd0 [ext3]
[<f8b866e2>] ext3_prepare_write+0x0/0x151 [ext3]
[<f8b86778>] ext3_prepare_write+0x96/0x151 [ext3]
[<f8b853b8>] ext3_get_block+0x0/0xd0 [ext3]
[<f8b866e2>] ext3_prepare_write+0x0/0x151 [ext3]
[<c0142832>] generic_file_buffered_write+0x26d/0x5eb
[<c024d691>] ata_altstatus+0x1d/0x24
[<c011e314>] current_fs_time+0x37/0x3c
[<c0143096>] __generic_file_aio_write_nolock+0x4e6/0x562
[<f8b91728>] ext3_permission+0x0/0xa [ext3]
[<c02e3322>] __mutex_lock_slowpath+0x1ac/0x1b4
[<c0143173>] generic_file_aio_write+0x61/0xc1
[<f8b82dfc>] ext3_file_write+0x24/0x90 [ext3]
[<c015a444>] do_sync_write+0xc7/0x10a
[<c012907c>] autoremove_wake_function+0x0/0x35
[<c015a37d>] do_sync_write+0x0/0x10a
[<c015ac89>] vfs_write+0xa8/0x155
[<c015b1c5>] sys_write+0x41/0x67
[<c0163e2a>] sys_fcntl64+0x7d/0x87
[<c0103b68>] syscall_call+0x7/0xb
=======================
Code: fa ff 80 7c 24 4f 00 89 c3 74 2f 8b 54 24 50 2b 94 24 80 00 00 00 8b 84 24 80 00 00 00 89 d1 89 54 24 1c c1 e9 02 8d 3c 03 89 f0 <f3> ab f6 c2 02 74 02 66 ab f6 c2 01 74 01 aa 80 7c 24 4e 00 74
EIP: [<c0174c46>] __block_prepare_write+0x246/0x445 SS:ESP 0068:f51e3bc8
note: growfiles[2913] exited with preempt_count 1
BUG: unable to handle kernel paging request at virtual address c0850048


Dropped, with alacrity, at 4:47AM. More care and better testing and
reviewing, please.
-
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/

\
 
 \ /
  Last update: 2007-04-25 13:51    [W:0.083 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site