In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> 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?
Currently it is redundant (because the giant kernel lock protects against
other threads), but I think it is still a good idea to add lock_sock (which
is cheap because the global bh lock is never contended) to
prepare for multi threaded socket calls in 2.3. Networking already does
more locking than it really needs currently just to prepare for this event.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
