Re[2]: problem in tcp_v4_synq_add ?

[Viorel Canja, Softwin]

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@xxxxxxxxxxxxxxx> 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?

PW> Cheers,
PW> Paul


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/