Date: Thu, 15 Oct 1998 21:20:23 +0400 (MSK DST)
From: [EMAIL PROTECTED] (Alexey Kuznetsov)
It is Andi's comment and this commnet is wrong.
lock_sock() is completely inappropriate for proc.
Locking looks correct there, probably algorithm itself is wrong
(stack overrun or something similar).
I cannot reproduced this lockup.
Why not to try sysreq-p to look where it looped?
Alexey, please peruse Andi's suggested patch fix for this.
lock_sock() _is_ appropriate for the case where we walk the openreq
list of a listening socket.
Look, protection is needed from userland side of things for this case.
This is because on SMP system BH atomicity protects from addition of
openreq entries and removals due to timeouts or RST packets, but
userspace side of accepting openreq's and making them true sockets is
done at userspace context inside of lock_sock() on listener.
See? 8))) Read the code, it is good exercise, I saw you preach this
to someone else earlier today. :-)
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
