Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Fri, 3 Sep 1999 19:56:43 MET-1 | Subject | 2.3.16, SMP & ncpfs |
| |
Hi, every time I try to access (read or write, ls is OK) file on ncpfs, I get (over IPX kernel lives, over IP(UDP) kernel stops calling bh's :-( ):
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/
| |