cp:
vana kernel: kernel BUG at /usr/src/linus/linux-2.3.16/include/asm/smplock.h:53!
vana kernel: invalid operand: 0000
vana kernel: CPU: 0
vana kernel: EIP: 0010:[sock_poll+36/112]
vana kernel: EFLAGS: 00010282
vana kernel: eax: 00000044 ebx: c6e32000 ecx: 00000012 edx: 00000038
vana kernel: esi: c6c09540 edi: 0000003c ebp: c6c09540 esp: c6e33e70
vana kernel: ds: 0018 es: 0018 ss: 0018
vana kernel: Process cp (pid: 888, stackpage=c6e33000)
vana kernel: Stack: 00000035 00000214 00000214 d286720c c6c09540 c6e33ef8 c793dc00 c6f1f000
vana kernel: 00000200 c793dc00 00003000 c6e32000 00000000 00000000 00000000 00000000
vana kernel: 00000000 00000005 0000003c c6f1f000 c0000000 c5fde90c 0008e000 00000000
vana kernel: Call Trace: [d_alloc+24/336] [sys_write+210/244] [system_call+52/56]
vana kernel: Code: 0f 0b 83 c4 0c 8d 76 00 ff 4b 30 79 09 f0 0f ba 35 60 36 1e
copy in mc:
vana kernel: kernel BUG at /usr/src/linus/linux-2.3.16/include/asm/smplock.h:53!
vana kernel: invalid operand: 0000
vana kernel: CPU: 1
vana kernel: EIP: 0010:[sock_poll+36/112]
vana kernel: EFLAGS: 00010282
vana kernel: eax: 00000044 ebx: c6e84000 ecx: 0000004a edx: 00000000
vana kernel: esi: c021bb00 edi: 0000003c ebp: c021bb00 esp: c6e85e70
vana kernel: ds: 0018 es: 0018 ss: 0018
vana kernel: Process mc (pid: 426, stackpage=c6e85000)
vana kernel: Stack: 00000035 00000414 00000414 d286720c c021bb00 c6e85ef8 c25c5000 c07ac000
vana kernel: 00000400 c25c5000 0000000e c6e84000 00000000 00000000 00000000 00000000
vana kernel: 00000000 00000005 0000003c c07ac000 c0000000 cfe473bc 00000001 cff87000
vana kernel: Call Trace: [con_flush_chars+18/24] [con_write+35/44] [sys_write+210/244] [system_call+52/56]
vana kernel: Code: 0f 0b 83 c4 0c 8d 76 00 ff 4b 30 79 09 f0 0f ba 35 60 36 1e
It looks like that ncpfs was doing WrongThing(tm) for years calling
->poll without kernel lock in read/write :-( So now it was revealed.
And what is correct cure? Add lock_kernel() around call to
file->f_op->poll(file, &wait_table) in fs/ncpfs/sock.c:450 ? If we
have correct poll now, we should go opposite way, but currently it is
impossible to call poll without holding kernel lock. Is it correct?
And, if I'm talking about it, can I call poll/sendmsg/recvmsg without
kernel lock in 2.2.x or should I obtain one? (I need not it internally
because of there is semaphore around this code, but what lives in networking
layer?)
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
P.S.: So please, do not use ncpfs on 2.3.16 SMP systems... On older systems
it should not hurt because of ncpfs is sole owner of socket in question
and does only send/poll/receive on that.
P.P.S.: Why call trace looks like it looks? It does not make any sense
to me that we came from d_alloc to sock_poll...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/