Hello all,
I was looking through the networking code in 2.6.1 kernel and it seems
to me there could be a problem in tcp_ipv4.c in function tcp_v4_synq_add :
904 static void tcp_v4_synq_add(struct sock *sk, struct open_request *req)
905 {
906 struct tcp_opt *tp = tcp_sk(sk);
907 struct tcp_listen_opt *lopt = tp->listen_opt;
908 u32 h = tcp_v4_synq_hash(req->af.v4_req.rmt_addr, req->rmt_port, lopt->hash_rnd);
909
910 req->expires = jiffies + TCP_TIMEOUT_INIT;
911 req->retrans = 0;
912 req->sk = NULL;
913 req->dl_next = lopt->syn_table[h];
914
915 write_lock(&tp->syn_wait_lock);
916 lopt->syn_table[h] = req;
917 write_unlock(&tp->syn_wait_lock);
918
919 tcp_synq_added(sk);
920 }
Shouldn't "write_lock(&tp->syn_wait_lock);" be moved before
"req->dl_next = lopt->syn_table[h];" to avoid a race condition ?
I am new to the linux kernel so it is likely that I am missing
something. What am I missing ?
Thanks in advance,
Viorel
On Tue, 9 Mar 2004 13:27:41 +0200
"Viorel Canja, Softwin" <[email protected]> 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.
On Mar 9, 2004, at 20:30, David S. Miller wrote:
> On Tue, 9 Mar 2004 13:27:41 +0200
> "Viorel Canja, Softwin" <[email protected]> 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.
Is that the same as saying that the write_lock() is not needed at all?
Since it is already guaranteed to be protected with a different lock?
Cheers,
Paul
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" <[email protected]> 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
On Wed, 10 Mar 2004 10:04:41 +0100
Paul Wagland <[email protected]> wrote:
> > Nope, the listening socket's socket lock is held, and all things that
> > add members to these hash chains hold that lock.
>
> Is that the same as saying that the write_lock() is not needed at all?
> Since it is already guaranteed to be protected with a different lock?
Also not true, as other pieces of code traverse the list as a reader
without holding the listening sockets lock.