Re[2]: problem in tcp_v4_synq_add ?

Viorel Canja, Softwin
2004-03-10T11:43:06Z

Hello Paul,

This comment in sock.h makes things clearer :

397 /* The syn_wait_lock is necessary only to avoid tcp_get_info having
398 * to grab the main lock sock while browsing the listening hash
399 * (otherwise it's deadlock prone).
400 * This lock is acquired in read mode only from tcp_get_info() and
401 * it's acquired in write mode _only_ from code that is actively
402 * changing the syn_wait_queue. All readers that are holding
403 * the master sock lock don't need to grab this lock in read mode
404 * too as the syn_wait_queue writes are always protected from
405 * the main sock lock.
406 */

best regards,
Viorel

Wednesday, March 10, 2004, 11:04:41 AM, you wrote:

PW> On Mar 9, 2004, at 20:30, David S. Miller wrote:

>> On Tue, 9 Mar 2004 13:27:41 +0200
>> "Viorel Canja, Softwin" <vcanja@bitdefender.com> wrote:
>>
>>> Shouldn't "write_lock(&tp->syn_wait_lock);" be moved before
>>> "req->dl_next = lopt->syn_table[h];" to avoid a race condition ?
>>
>> Nope, the listening socket's socket lock is held, and all things that
>> add members to these hash chains hold that lock.

PW> Is that the same as saying that the write_lock() is not needed at all?
PW> Since it is already guaranteed to be protected with a different lock?