> It looks like that ncpfs was doing WrongThing(tm) for years calling
> ->poll without kernel lock in read/write :-(
read/write lost kernel lock very recently.
It is my fault, I leaved these unlocks in poll/ioctl/close to speedup
verification of networking multithreadness.
> And what is correct cure? Add lock_kernel() around call to
> file->f_op->poll(file, &wait_table) in fs/ncpfs/sock.c:450 ?
For now yes. Or call sock->ops->poll() directly.
> 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?
All the operations not indirected via VFS i.e. socket calls
do not put any limitations. I.e. you may call sendmsg/recvmsg in the context,
which is convenient for you. Certainly, this context should not be locked 8)
VFS grabs kernel lock in all the cases but read/write.
Networking _should_ not unlock kernel in this case, certainly.
It is just stupid and dangerous. But it does unlock, it is the only
way to verify its networking correctness in current VFS environment.
> (I need not it internally
> because of there is semaphore around this code, but what lives in networking
> layer?)
You may use sock->ops->poll() directly.
Alexey Kuznetsov
-
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/