problem in tcp_v4_synq_add ?

problem in tcp_v4_synq_add ?

[Viorel Canja, Softwin]

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

Re: problem in tcp_v4_synq_add ?

[David S. Miller]

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.

Re: problem in tcp_v4_synq_add ?

[Paul Wagland]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]


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.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

PW> Cheers,
PW> Paul

Re: problem in tcp_v4_synq_add ?

[David S. Miller]

On Wed, 10 Mar 2004 10:04:41 +0100
Paul Wagland <paul@wagland.net> 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.