* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
@ 2001-09-08 23:11 Manfred Spraul
2001-09-09 3:44 ` Robert Love
0 siblings, 1 reply; 11+ messages in thread
From: Manfred Spraul @ 2001-09-08 23:11 UTC (permalink / raw)
To: Roger Larsson; +Cc: linux-kernel, Robert Love, nigel
> This is interesting. [Assumes UP Athlon - correct]
> Note that all BUGs out in highmem.h:95 (kmap_atomic)
> and that test is only on if you have enabled HIGHMEM_DEBUG
> [my analyze is done with a 2.4.10-pre2 kernel, but I checked with
> later patches and I do not think they fix it either...]
>
> The preemptive kernel puts more SMP stress on the kernel than
> running with multiple CPUs.
>
> So this might be a potential bug in the kernel proper, running with
> a SMP computer.
No.
It seems to be a missing ctx_sw_off() in highmem.h:
kmap_atomic uses a per-cpu variable, thus ctx_sw_off() is needed in
kmap_atomic, and ctx_sw_on() in kunmap_atomic().
--
Manfred
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-08 23:11 [SMP lock BUG?] Re: Feedback on preemptible kernel patch Manfred Spraul
@ 2001-09-09 3:44 ` Robert Love
2001-09-09 7:38 ` Manfred Spraul
[not found] ` <001a01c1390262c7f30/mnt/sendme10411ac@local>
0 siblings, 2 replies; 11+ messages in thread
From: Robert Love @ 2001-09-09 3:44 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Roger Larsson, linux-kernel, nigel
On Sat, 2001-09-08 at 19:11, Manfred Spraul wrote:
> No.
> It seems to be a missing ctx_sw_off() in highmem.h:
> kmap_atomic uses a per-cpu variable, thus ctx_sw_off() is needed in
> kmap_atomic, and ctx_sw_on() in kunmap_atomic().
in my tree, kmap_atomic and kunmap_atomic are just defined to
kmap/kunmap. are you suggesting something like this?
#define kmap_atomic(page,idx) ctx_sw_off(); kmap(page);
#define kunmap_atomic(page,idx) ctx_sw_on(); kunmap(page);
--
Robert M. Love
rml at ufl.edu
rml at tech9.net
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-09 3:44 ` Robert Love
@ 2001-09-09 7:38 ` Manfred Spraul
[not found] ` <001a01c1390262c7f30/mnt/sendme10411ac@local>
1 sibling, 0 replies; 11+ messages in thread
From: Manfred Spraul @ 2001-09-09 7:38 UTC (permalink / raw)
To: Robert Love; +Cc: Roger Larsson, linux-kernel, nigel
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
> #define kmap_atomic(page,idx) ctx_sw_off(); kmap(page);
> #define kunmap_atomic(page,idx) ctx_sw_on(); kunmap(page);
>
No. kmap_atomic is called from interrupt context, and kmap calls
schedule().
I thought about the attached patch (completely untested).
--
Manfred
[-- Attachment #2: patch-untested --]
[-- Type: application/octet-stream, Size: 438 bytes --]
--- highmem.h.prev Sun Sep 9 08:59:04 2001
+++ highmem.h Sun Sep 9 09:00:07 2001
@@ -88,6 +88,7 @@
if (page < highmem_start_page)
return page_address(page);
+ ctx_sw_off();
idx = type + KM_TYPE_NR*smp_processor_id();
vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
#if HIGHMEM_DEBUG
@@ -119,6 +120,7 @@
pte_clear(kmap_pte-idx);
__flush_tlb_one(vaddr);
#endif
+ ctx_sw_on();
}
#endif /* __KERNEL__ */
^ permalink raw reply [flat|nested] 11+ messages in thread[parent not found: <001a01c1390262c7f30/mnt/sendme10411ac@local>]
* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
[not found] ` <001a01c1390262c7f30/mnt/sendme10411ac@local>
@ 2001-09-14 9:15 ` Pavel Machek
2001-09-17 22:40 ` Manfred Spraul
2001-09-17 22:41 ` Robert Love
0 siblings, 2 replies; 11+ messages in thread
From: Pavel Machek @ 2001-09-14 9:15 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Robert Love, Roger Larsson, linux-kernel, nigel
Hi!
> > #define kmap_atomic(page,idx) ctx_sw_off(); kmap(page);
> > #define kunmap_atomic(page,idx) ctx_sw_on(); kunmap(page);
> >
> No. kmap_atomic is called from interrupt context, and kmap calls
> schedule().
>
> I thought about the attached patch (completely untested).
is it legal to kmap_atomic(a,b); kmap_atomic(c,d); kunmap_atomic(a,b); ?
If so, your patch may need some ounting....
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-14 9:15 ` Pavel Machek
@ 2001-09-17 22:40 ` Manfred Spraul
2001-09-18 0:19 ` Robert Love
2001-09-17 22:41 ` Robert Love
1 sibling, 1 reply; 11+ messages in thread
From: Manfred Spraul @ 2001-09-17 22:40 UTC (permalink / raw)
To: Pavel Machek; +Cc: Robert Love, Roger Larsson, linux-kernel, nigel
>
> is it legal to kmap_atomic(a,b); kmap_atomic(c,d); kunmap_atomic(a,b);
?
>
Yes, that's legal - just think about one kmap_atomic from process
context, and another one in irq context.
> If so, your patch may need some ounting....
> Pavel
I hope ctx_sw_off does internal counting, correct?
--
Manfred
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-17 22:40 ` Manfred Spraul
@ 2001-09-18 0:19 ` Robert Love
0 siblings, 0 replies; 11+ messages in thread
From: Robert Love @ 2001-09-18 0:19 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Pavel Machek, Roger Larsson, linux-kernel, nigel
On Mon, 2001-09-17 at 18:40, Manfred Spraul wrote:
> > is it legal to kmap_atomic(a,b); kmap_atomic(c,d); kunmap_atomic(a,b);
>
> Yes, that's legal - just think about one kmap_atomic from process
> context, and another one in irq context.
>
> > If so, your patch may need some ounting....
> > Pavel
>
> I hope ctx_sw_off does internal counting, correct?
yes, ctx_sw_off atomically increments a counter and ctx_sw_on
atomic_dec_and_test()s it.
--
Robert M. Love
rml at ufl.edu
rml at tech9.net
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-14 9:15 ` Pavel Machek
2001-09-17 22:40 ` Manfred Spraul
@ 2001-09-17 22:41 ` Robert Love
1 sibling, 0 replies; 11+ messages in thread
From: Robert Love @ 2001-09-17 22:41 UTC (permalink / raw)
To: Pavel Machek; +Cc: Manfred Spraul, Roger Larsson, linux-kernel, nigel
On Fri, 2001-09-14 at 05:15, Pavel Machek wrote:
> is it legal to kmap_atomic(a,b); kmap_atomic(c,d); kunmap_atomic(a,b); ?
> If so, your patch may need some ounting....
ctx_sw_on and ctx_sw_off use a recursive spinlock, so the calls to
kunmap_atomic won't drop the slock until the last call.
--
Robert M. Love
rml at ufl.edu
rml at tech9.net
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Feedback on preemptible kernel patch
@ 2001-09-08 17:33 Arjan Filius
2001-09-08 20:58 ` [SMP lock BUG?] " Roger Larsson
0 siblings, 1 reply; 11+ messages in thread
From: Arjan Filius @ 2001-09-08 17:33 UTC (permalink / raw)
To: Robert Love; +Cc: linux-kernel
Hello Robert,
I tried 2.4.10-pre4 with patch-rml-2.4.10-pre4-preempt-kernel-1.
But it seems to hit highmem (see below) (i do have 1.5GB ram)
2.4.10-pre4 plain runs just fine.
With the kernel option mem=850M the patched kernel boots an seems to run
fine. However i didn't do any stress testing yet, but i still notice
hickups while playing mp3 files at -10 nice level with mpg123 on a 1.1GHz
Athlon, and removing for example a _large_ file (reiser-on-lvm).
My syslog output with highmem:
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010282
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: 080bdd5c ecx: f5764260 edx: f4d4c000
Sep 8 18:10:16 sjoerd kernel: esi: c26cca60 edi: ffffffff ebp: c26ca134 esp: f4d4dec8
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process S11dhcpd (pid: 2507, stackpage=f4d4d000)
Sep 8 18:10:16 sjoerd kernel: Stack: c0210bd2 c0210cc0 0000005f 080bdd5c f5805f00 ffffffff 00000001 c012437d
Sep 8 18:10:16 sjoerd kernel: f5805f00 f4d49a00 080bdd5c f4c822f4 55d54065 f4d4c000 f4d49a00 f5805f00
Sep 8 18:10:16 sjoerd kernel: f5805f1c c0111a17 f5805f00 f4d49a00 080bdd5c 00000001 f4d4c000 00000007
Sep 8 18:10:16 sjoerd kernel: Call Trace: [handle_mm_fault+141/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64] [do_exit+595/640]
Sep 8 18:10:16 sjoerd kernel: [error_code+52/64]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
Sep 8 18:10:16 sjoerd kernel: MAC unknown INTRUDERS?? (tf) IN=eth0 OUT= MAC= SRC=192.168.0.5 DST=192.168.0.255 LEN=241 TOS=0x02 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=221
Sep 8 18:10:16 sjoerd kernel: MAC unknown INTRUDERS?? (tf) IN=eth0 OUT= MAC= SRC=192.168.0.5 DST=192.168.0.255 LEN=96 TOS=0x02 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=137 LEN=76
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_anonymous_page+130/368]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010286
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: 080c501c ecx: f5764260 edx: f4d4c000
Sep 8 18:10:16 sjoerd kernel: esi: c26c4fec edi: f5805f00 ebp: f4d497c0 esp: f4d4dea0
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process dhcpd (pid: 2508, stackpage=f4d4d000)
Sep 8 18:10:16 sjoerd kernel: Stack: c0210bd2 c0210cc0 0000005f 080c501c f4d497c0 f5805f00 00000001 c012420f
Sep 8 18:10:16 sjoerd kernel: f5805f00 f4d497c0 f4c63314 00000001 080c501c 080c501c f5805f00 ffffffff
Sep 8 18:10:16 sjoerd kernel: 00000001 c012434e f5805f00 f4d497c0 080c501c 00000001 f4c63314 f4d4c000
Sep 8 18:10:16 sjoerd kernel: Call Trace: [do_no_page+47/272] [handle_mm_fault+94/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [do_munmap+86/640]
Sep 8 18:10:16 sjoerd kernel: [fput+116/224] [do_brk+176/368] [sys_brk+187/240] [error_code+52/64]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_anonymous_page+130/368]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010282
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: 40017000 ecx: f5735f7c edx: f4c88000
Sep 8 18:10:16 sjoerd kernel: esi: c26c9298 edi: f5805d80 ebp: f4c945c0 esp: f4c89dc8
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process python (pid: 2456, stackpage=f4c89000)
Sep 8 18:10:16 sjoerd kernel: Stack: c0210bd2 c0210cc0 0000005f 40017000 f4c945c0 f5805d80 00000001 c012420f
Sep 8 18:10:16 sjoerd kernel: f5805d80 f4c945c0 f4c9c05c 00000001 40017000 40017000 f5805d80 ffffffff
Sep 8 18:10:16 sjoerd kernel: 00000001 c012434e f5805d80 f4c945c0 40017000 00000001 f4c9c05c f4c88000
Sep 8 18:10:16 sjoerd kernel: Call Trace: [do_no_page+47/272] [handle_mm_fault+94/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [block_read_full_page+240/688]
Sep 8 18:10:16 sjoerd kernel: [error_code+52/64] [file_read_actor+113/224] [do_generic_file_read+505/1344] [generic_file_read+99/128] [file_read_actor+0/224] [sys_read+150/208]
Sep 8 18:10:16 sjoerd kernel: [system_call+51/56]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010282
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: bffff960 ecx: f5764260 edx: f4ce4000
Sep 8 18:10:16 sjoerd kernel: esi: c26d04d0 edi: ffffffff ebp: c26ca4a8 esp: f4ce5ec8
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process rc (pid: 2514, stackpage=f4ce5000)
Sep 8 18:10:16 sjoerd kernel: Stack: c0210bd2 c0210cc0 0000005f bffff960 f5805780 ffffffff 00000001 c012437d
Sep 8 18:10:16 sjoerd kernel: f5805780 f4c54dc0 bffff960 f4ca8ffc 55e30065 f4ce4000 f4c54dc0 f5805780
Sep 8 18:10:16 sjoerd kernel: f580579c c0111a17 f5805780 f4c54dc0 bffff960 00000001 f4ce4000 00000007
Sep 8 18:10:16 sjoerd kernel: Call Trace: [handle_mm_fault+141/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64] [do_exit+595/640]
Sep 8 18:10:16 sjoerd kernel: [error_code+52/64]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[filemap_nopage+300/1344]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010282
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: 00000001 ecx: f5764260 edx: f4c3e000
Sep 8 18:10:16 sjoerd kernel: esi: c297ac20 edi: 00000015 ebp: c270df9c esp: f4c3fb30
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process ncpserv (pid: 2513, stackpage=f4c3f000)
Sep 8 18:10:16 sjoerd kernel: Stack: c02110b2 c0211160 0000005f 40016000 f4c54f00 f4c62140 00000001 00000019
Sep 8 18:10:16 sjoerd kernel: f7af9960 f74f7a24 f74f7980 f4db9c40 c0124252 f4c54f00 40016000 00000001
Sep 8 18:10:16 sjoerd kernel: 400162a8 f4c62140 ffffffff 00000001 c012434e f4c62140 f4c54f00 400162a8
Sep 8 18:10:16 sjoerd kernel: Call Trace: [do_no_page+114/272] [handle_mm_fault+94/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [file_read_actor+177/224]
Sep 8 18:10:16 sjoerd kernel: [update_atime+68/80] [do_generic_file_read+1333/1344] [do_munmap+86/640] [update_atime+68/80] [error_code+52/64] [clear_user+46/64]
Sep 8 18:10:16 sjoerd kernel: [padzero+28/32] [load_elf_interp+619/704] [load_elf_binary+1959/2704] [load_elf_binary+0/2704] [nfsd:__insmod_nfsd_O/lib/modules/2.4.10-pre4/kernel/fs/nfsd/nfsd+-13721617/96] [search_binary_handler+152/496]
Sep 8 18:10:16 sjoerd kernel: [do_execve+380/496] [do_execve+403/496] [sys_execve+47/96] [system_call+51/56]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
Sep 8 18:10:16 sjoerd kernel: LOOUT REJECT TCP IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=356 TOS=0x02 PREC=0x00 TTL=64 ID=32512 PROTO=TCP SPT=32775 DPT=15607 WINDOW=32767 RES=0x00 ACK PSH FIN URGP=0
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010282
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: 080b170c ecx: f4ce4260 edx: f5946000
Sep 8 18:10:16 sjoerd kernel: esi: c26dec2c edi: ffffffff ebp: c26ca2cc esp: f5947ec8
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process rc (pid: 156, stackpage=f5947000)
Sep 8 18:10:16 sjoerd kernel: Stack: c0210bd2 c0210cc0 0000005f 080b170c f752a080 ffffffff 00000001 c012437d
Sep 8 18:10:16 sjoerd kernel: f752a080 f75282c0 080b170c f59de2c4 56197065 f5946000 f75282c0 f752a080
Sep 8 18:10:16 sjoerd kernel: f752a09c c0111a17 f752a080 f75282c0 080b170c 00000001 f5946000 00000007
Sep 8 18:10:16 sjoerd kernel: Call Trace: [handle_mm_fault+141/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [copy_thread+136/160] [do_fork+1619/1792]
Sep 8 18:10:16 sjoerd kernel: [write_chan+0/544] [sys_fork+20/32] [error_code+52/64]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
Sep 8 18:10:16 sjoerd kernel: kernel BUG at /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95!
Sep 8 18:10:16 sjoerd kernel: invalid operand: 0000
Sep 8 18:10:16 sjoerd kernel: CPU: 0
Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
Sep 8 18:10:16 sjoerd kernel: EFLAGS: 00010282
Sep 8 18:10:16 sjoerd kernel: eax: 00000043 ebx: 080b04e0 ecx: f5735f7c edx: c299a000
Sep 8 18:10:16 sjoerd kernel: esi: c2962850 edi: ffffffff ebp: c292d82c esp: c299bec8
Sep 8 18:10:16 sjoerd kernel: ds: 0018 es: 0018 ss: 0018
Sep 8 18:10:16 sjoerd kernel: Process init (pid: 1, stackpage=c299b000)
Sep 8 18:10:16 sjoerd kernel: Stack: c0210bd2 c0210cc0 0000005f 080b04e0 f752a140 ffffffff 00000001 c012437d
Sep 8 18:10:16 sjoerd kernel: f752a140 f7528180 080b04e0 f751a2c0 5f910065 c299a000 f7528180 f752a140
Sep 8 18:10:16 sjoerd kernel: f752a15c c0111a17 f752a140 f7528180 080b04e0 00000001 c299a000 00000007
Sep 8 18:10:16 sjoerd kernel: Call Trace: [handle_mm_fault+141/224] [do_page_fault+375/1136] [do_page_fault+0/1136] [copy_thread+136/160] [do_fork+1619/1792]
Sep 8 18:10:16 sjoerd kernel: [sys_fork+20/32] [error_code+52/64]
Sep 8 18:10:16 sjoerd kernel:
Sep 8 18:10:16 sjoerd kernel: Code: 0f 0b 83 c4 0c 8b 15 e8 2f 2a c0 89 f0 2b 05 ac ba 2a c0 69
--
Arjan Filius
mailto:iafilius@xs4all.nl
^ permalink raw reply [flat|nested] 11+ messages in thread
* [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-08 17:33 Arjan Filius
@ 2001-09-08 20:58 ` Roger Larsson
2001-09-08 22:18 ` Arjan Filius
2001-09-09 14:55 ` george anzinger
0 siblings, 2 replies; 11+ messages in thread
From: Roger Larsson @ 2001-09-08 20:58 UTC (permalink / raw)
To: Arjan Filius, Robert Love; +Cc: linux-kernel, linux-mm
Hi,
This is interesting. [Assumes UP Athlon - correct]
Note that all BUGs out in highmem.h:95 (kmap_atomic)
and that test is only on if you have enabled HIGHMEM_DEBUG
[my analyze is done with a 2.4.10-pre2 kernel, but I checked with
later patches and I do not think they fix it either...]
The preemptive kernel puts more SMP stress on the kernel than
running with multiple CPUs.
So this might be a potential bug in the kernel proper, running with
a SMP computer.
If I understand the bug correctly, a process gets a page fault.
Starts to map in the page. But before the final part it checks -
and the page is already there!!! Correct?
On Saturday den 8 September 2001 19:33, Arjan Filius wrote:
> Hello Robert,
>
>
> I tried 2.4.10-pre4 with patch-rml-2.4.10-pre4-preempt-kernel-1.
> But it seems to hit highmem (see below) (i do have 1.5GB ram)
> 2.4.10-pre4 plain runs just fine.
>
> With the kernel option mem=850M the patched kernel boots an seems to run
> fine. However i didn't do any stress testing yet, but i still notice
> hickups while playing mp3 files at -10 nice level with mpg123 on a 1.1GHz
> Athlon, and removing for example a _large_ file (reiser-on-lvm).
>
> My syslog output with highmem:
>
> Sep 8 18:10:16 sjoerd kernel: kernel BUG at
> /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95! Sep 8 18:10:16 sjoerd
> kernel: invalid operand: 0000
> Sep 8 18:10:16 sjoerd kernel: CPU: 0
> Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
> [- - -]
> sjoerd kernel: Call Trace: [handle_mm_fault+141/224]
> [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64]
> [do_exit+595/640] Sep 8 18:10:16 sjoerd kernel: [error_code+52/64]
Lets look at this example. You need to add some inline functions...
handle_mm_fault
takes the mm->page_table_lock [this should prevent reschedules]
allocs pmd
allocs pte
handle_pte_fault(...)
handle_pte_fault [inline, most likely path]
pte is present
it is a write access
but the pte is not writeable - call do_wp_page
do_wp_page
plays some games with the lock...
finally calls copy_cow_page [inline] with the page_table_lock
UNLOCKED!
copy_cow_page
calls clear_user_highpage or copy_user_highpage
both clear_user_highpage and copy_user_highpage
calls kmap_atomic
kmap_atomic
page is a highmem page
but during the time this process was unlocked some other
thread has allocated the page in question... BUG out.
So somewere between the UNLOCK (might be a lot later) and the
BUG test in kmap_atomic the process running in kernel got preempted.
(most likely during the page copy since it will take some time)
Another process (thread) started to run - hit the same page fault
but succeeded in its alloc.
Back to the first process it continues, finally checks - the page
is there... and BUGS.
Note that this can happen in a pure SMP kernel.
But let the processes (threads) run on two CPUs. And let the
first get an interrupt/bh after unlock - the other can pass
and add the page before the first one can continue - same
result!
/RogerL
--
Roger Larsson
Skellefteå
Sweden
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-08 20:58 ` [SMP lock BUG?] " Roger Larsson
@ 2001-09-08 22:18 ` Arjan Filius
2001-09-09 14:55 ` george anzinger
1 sibling, 0 replies; 11+ messages in thread
From: Arjan Filius @ 2001-09-08 22:18 UTC (permalink / raw)
To: Roger Larsson; +Cc: Robert Love, linux-kernel, linux-mm
Hello Roger,
On Sat, 8 Sep 2001, Roger Larsson wrote:
> Hi,
>
> This is interesting. [Assumes UP Athlon - correct]
UP Athlon, and compiled as UP (as always).
I haven't tested my system with an SMP kernel for a long while.
> Note that all BUGs out in highmem.h:95 (kmap_atomic)
> and that test is only on if you have enabled HIGHMEM_DEBUG
It seems to be on indeed.
> [my analyze is done with a 2.4.10-pre2 kernel, but I checked with
> later patches and I do not think they fix it either...]
>
> The preemptive kernel puts more SMP stress on the kernel than
> running with multiple CPUs.
>
> So this might be a potential bug in the kernel proper, running with
> a SMP computer.
>
> If I understand the bug correctly, a process gets a page fault.
> Starts to map in the page. But before the final part it checks -
> and the page is already there!!! Correct?
ehh.. Should compiling SMP on UP (just for test) trigger this?
Greatings,
>
> On Saturday den 8 September 2001 19:33, Arjan Filius wrote:
> > Hello Robert,
> >
> >
> > I tried 2.4.10-pre4 with patch-rml-2.4.10-pre4-preempt-kernel-1.
> > But it seems to hit highmem (see below) (i do have 1.5GB ram)
> > 2.4.10-pre4 plain runs just fine.
> >
> > With the kernel option mem=850M the patched kernel boots an seems to run
> > fine. However i didn't do any stress testing yet, but i still notice
> > hickups while playing mp3 files at -10 nice level with mpg123 on a 1.1GHz
> > Athlon, and removing for example a _large_ file (reiser-on-lvm).
> >
> > My syslog output with highmem:
> >
> > Sep 8 18:10:16 sjoerd kernel: kernel BUG at
> > /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95! Sep 8 18:10:16 sjoerd
> > kernel: invalid operand: 0000
> > Sep 8 18:10:16 sjoerd kernel: CPU: 0
> > Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
> > [- - -]
> > sjoerd kernel: Call Trace: [handle_mm_fault+141/224]
> > [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64]
> > [do_exit+595/640] Sep 8 18:10:16 sjoerd kernel: [error_code+52/64]
>
> Lets look at this example. You need to add some inline functions...
>
> handle_mm_fault
> takes the mm->page_table_lock [this should prevent reschedules]
> allocs pmd
> allocs pte
> handle_pte_fault(...)
> handle_pte_fault [inline, most likely path]
> pte is present
> it is a write access
> but the pte is not writeable - call do_wp_page
> do_wp_page
> plays some games with the lock...
> finally calls copy_cow_page [inline] with the page_table_lock
> UNLOCKED!
> copy_cow_page
> calls clear_user_highpage or copy_user_highpage
> both clear_user_highpage and copy_user_highpage
> calls kmap_atomic
> kmap_atomic
> page is a highmem page
> but during the time this process was unlocked some other
> thread has allocated the page in question... BUG out.
>
> So somewere between the UNLOCK (might be a lot later) and the
> BUG test in kmap_atomic the process running in kernel got preempted.
> (most likely during the page copy since it will take some time)
>
> Another process (thread) started to run - hit the same page fault
> but succeeded in its alloc.
>
> Back to the first process it continues, finally checks - the page
> is there... and BUGS.
>
> Note that this can happen in a pure SMP kernel.
>
> But let the processes (threads) run on two CPUs. And let the
> first get an interrupt/bh after unlock - the other can pass
> and add the page before the first one can continue - same
> result!
>
> /RogerL
>
>
--
Arjan Filius
mailto:iafilius@xs4all.nl
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-08 20:58 ` [SMP lock BUG?] " Roger Larsson
2001-09-08 22:18 ` Arjan Filius
@ 2001-09-09 14:55 ` george anzinger
2001-09-09 22:25 ` Arjan Filius
1 sibling, 1 reply; 11+ messages in thread
From: george anzinger @ 2001-09-09 14:55 UTC (permalink / raw)
To: Roger Larsson; +Cc: Arjan Filius, Robert Love, linux-kernel, linux-mm
If the page it is the correct one, when it is found mapped, the code
should just exit, not BUG() IHMO.
George
Roger Larsson wrote:
>
> Hi,
>
> This is interesting. [Assumes UP Athlon - correct]
> Note that all BUGs out in highmem.h:95 (kmap_atomic)
> and that test is only on if you have enabled HIGHMEM_DEBUG
> [my analyze is done with a 2.4.10-pre2 kernel, but I checked with
> later patches and I do not think they fix it either...]
>
> The preemptive kernel puts more SMP stress on the kernel than
> running with multiple CPUs.
>
> So this might be a potential bug in the kernel proper, running with
> a SMP computer.
>
> If I understand the bug correctly, a process gets a page fault.
> Starts to map in the page. But before the final part it checks -
> and the page is already there!!! Correct?
>
> On Saturday den 8 September 2001 19:33, Arjan Filius wrote:
> > Hello Robert,
> >
> >
> > I tried 2.4.10-pre4 with patch-rml-2.4.10-pre4-preempt-kernel-1.
> > But it seems to hit highmem (see below) (i do have 1.5GB ram)
> > 2.4.10-pre4 plain runs just fine.
> >
> > With the kernel option mem=850M the patched kernel boots an seems to run
> > fine. However i didn't do any stress testing yet, but i still notice
> > hickups while playing mp3 files at -10 nice level with mpg123 on a 1.1GHz
> > Athlon, and removing for example a _large_ file (reiser-on-lvm).
> >
> > My syslog output with highmem:
> >
> > Sep 8 18:10:16 sjoerd kernel: kernel BUG at
> > /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95! Sep 8 18:10:16 sjoerd
> > kernel: invalid operand: 0000
> > Sep 8 18:10:16 sjoerd kernel: CPU: 0
> > Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
> > [- - -]
> > sjoerd kernel: Call Trace: [handle_mm_fault+141/224]
> > [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64]
> > [do_exit+595/640] Sep 8 18:10:16 sjoerd kernel: [error_code+52/64]
>
> Lets look at this example. You need to add some inline functions...
>
> handle_mm_fault
> takes the mm->page_table_lock [this should prevent reschedules]
> allocs pmd
> allocs pte
> handle_pte_fault(...)
> handle_pte_fault [inline, most likely path]
> pte is present
> it is a write access
> but the pte is not writeable - call do_wp_page
> do_wp_page
> plays some games with the lock...
> finally calls copy_cow_page [inline] with the page_table_lock
> UNLOCKED!
> copy_cow_page
> calls clear_user_highpage or copy_user_highpage
> both clear_user_highpage and copy_user_highpage
> calls kmap_atomic
> kmap_atomic
> page is a highmem page
> but during the time this process was unlocked some other
> thread has allocated the page in question... BUG out.
>
> So somewere between the UNLOCK (might be a lot later) and the
> BUG test in kmap_atomic the process running in kernel got preempted.
> (most likely during the page copy since it will take some time)
>
> Another process (thread) started to run - hit the same page fault
> but succeeded in its alloc.
>
> Back to the first process it continues, finally checks - the page
> is there... and BUGS.
>
> Note that this can happen in a pure SMP kernel.
>
> But let the processes (threads) run on two CPUs. And let the
> first get an interrupt/bh after unlock - the other can pass
> and add the page before the first one can continue - same
> result!
>
> /RogerL
>
> --
> Roger Larsson
> Skellefteå
> Sweden
> -
> 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/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [SMP lock BUG?] Re: Feedback on preemptible kernel patch
2001-09-09 14:55 ` george anzinger
@ 2001-09-09 22:25 ` Arjan Filius
0 siblings, 0 replies; 11+ messages in thread
From: Arjan Filius @ 2001-09-09 22:25 UTC (permalink / raw)
To: george anzinger; +Cc: Roger Larsson, Robert Love, linux-kernel, linux-mm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 4086 bytes --]
Hi,
On Sun, 9 Sep 2001, george anzinger wrote:
> If the page it is the correct one, when it is found mapped, the code
> should just exit, not BUG() IHMO.
I'll try the ac10 +preempt, see what happens.
>
> George
>
>
> Roger Larsson wrote:
> >
> > Hi,
> >
> > This is interesting. [Assumes UP Athlon - correct]
> > Note that all BUGs out in highmem.h:95 (kmap_atomic)
> > and that test is only on if you have enabled HIGHMEM_DEBUG
> > [my analyze is done with a 2.4.10-pre2 kernel, but I checked with
> > later patches and I do not think they fix it either...]
> >
> > The preemptive kernel puts more SMP stress on the kernel than
> > running with multiple CPUs.
> >
> > So this might be a potential bug in the kernel proper, running with
> > a SMP computer.
> >
> > If I understand the bug correctly, a process gets a page fault.
> > Starts to map in the page. But before the final part it checks -
> > and the page is already there!!! Correct?
> >
> > On Saturday den 8 September 2001 19:33, Arjan Filius wrote:
> > > Hello Robert,
> > >
> > >
> > > I tried 2.4.10-pre4 with patch-rml-2.4.10-pre4-preempt-kernel-1.
> > > But it seems to hit highmem (see below) (i do have 1.5GB ram)
> > > 2.4.10-pre4 plain runs just fine.
> > >
> > > With the kernel option mem=850M the patched kernel boots an seems to run
> > > fine. However i didn't do any stress testing yet, but i still notice
> > > hickups while playing mp3 files at -10 nice level with mpg123 on a 1.1GHz
> > > Athlon, and removing for example a _large_ file (reiser-on-lvm).
> > >
> > > My syslog output with highmem:
> > >
> > > Sep 8 18:10:16 sjoerd kernel: kernel BUG at
> > > /usr/src/linux-2.4.10-pre4/include/asm/highmem.h:95! Sep 8 18:10:16 sjoerd
> > > kernel: invalid operand: 0000
> > > Sep 8 18:10:16 sjoerd kernel: CPU: 0
> > > Sep 8 18:10:16 sjoerd kernel: EIP: 0010:[do_wp_page+636/1088]
> > > [- - -]
> > > sjoerd kernel: Call Trace: [handle_mm_fault+141/224]
> > > [do_page_fault+375/1136] [do_page_fault+0/1136] [__mmdrop+58/64]
> > > [do_exit+595/640] Sep 8 18:10:16 sjoerd kernel: [error_code+52/64]
> >
> > Lets look at this example. You need to add some inline functions...
> >
> > handle_mm_fault
> > takes the mm->page_table_lock [this should prevent reschedules]
> > allocs pmd
> > allocs pte
> > handle_pte_fault(...)
> > handle_pte_fault [inline, most likely path]
> > pte is present
> > it is a write access
> > but the pte is not writeable - call do_wp_page
> > do_wp_page
> > plays some games with the lock...
> > finally calls copy_cow_page [inline] with the page_table_lock
> > UNLOCKED!
> > copy_cow_page
> > calls clear_user_highpage or copy_user_highpage
> > both clear_user_highpage and copy_user_highpage
> > calls kmap_atomic
> > kmap_atomic
> > page is a highmem page
> > but during the time this process was unlocked some other
> > thread has allocated the page in question... BUG out.
> >
> > So somewere between the UNLOCK (might be a lot later) and the
> > BUG test in kmap_atomic the process running in kernel got preempted.
> > (most likely during the page copy since it will take some time)
> >
> > Another process (thread) started to run - hit the same page fault
> > but succeeded in its alloc.
> >
> > Back to the first process it continues, finally checks - the page
> > is there... and BUGS.
> >
> > Note that this can happen in a pure SMP kernel.
> >
> > But let the processes (threads) run on two CPUs. And let the
> > first get an interrupt/bh after unlock - the other can pass
> > and add the page before the first one can continue - same
> > result!
> >
> > /RogerL
> >
> > --
> > Roger Larsson
> > Skellefteå
> > Sweden
> > -
> > 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/
>
--
Arjan Filius
mailto:iafilius@xs4all.nl
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-09-18 0:18 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-08 23:11 [SMP lock BUG?] Re: Feedback on preemptible kernel patch Manfred Spraul
2001-09-09 3:44 ` Robert Love
2001-09-09 7:38 ` Manfred Spraul
[not found] ` <001a01c1390262c7f30/mnt/sendme10411ac@local>
2001-09-14 9:15 ` Pavel Machek
2001-09-17 22:40 ` Manfred Spraul
2001-09-18 0:19 ` Robert Love
2001-09-17 22:41 ` Robert Love
-- strict thread matches above, loose matches on Subject: below --
2001-09-08 17:33 Arjan Filius
2001-09-08 20:58 ` [SMP lock BUG?] " Roger Larsson
2001-09-08 22:18 ` Arjan Filius
2001-09-09 14:55 ` george anzinger
2001-09-09 22:25 ` Arjan Filius
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox