Hello!
> 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.
Alas, I did not understand...
Where bh protection exists, any more protection is redundant now. Right?
Do you really want to say that tcp sk list may be walked safely
without bh_atomic?
The last thing looks impossible: seems, tcp sockets are removed by bh,
so that bh protection is necessary in any case. Or it is already wrong?
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
