* problem in tcp_v4_synq_add ?
@ 2004-03-09 11:27 Viorel Canja, Softwin
2004-03-09 19:30 ` David S. Miller
0 siblings, 1 reply; 5+ messages in thread
From: Viorel Canja, Softwin @ 2004-03-09 11:27 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem in tcp_v4_synq_add ?
2004-03-09 11:27 problem in tcp_v4_synq_add ? Viorel Canja, Softwin
@ 2004-03-09 19:30 ` David S. Miller
2004-03-10 9:04 ` Paul Wagland
0 siblings, 1 reply; 5+ messages in thread
From: David S. Miller @ 2004-03-09 19:30 UTC (permalink / raw)
To: Viorel Canja, Softwin; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem in tcp_v4_synq_add ?
2004-03-09 19:30 ` David S. Miller
@ 2004-03-10 9:04 ` Paul Wagland
2004-03-10 11:42 ` Re[2]: " Viorel Canja, Softwin
2004-03-10 21:37 ` David S. Miller
0 siblings, 2 replies; 5+ messages in thread
From: Paul Wagland @ 2004-03-10 9:04 UTC (permalink / raw)
To: David S. Miller; +Cc: Viorel Canja, Softwin, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re[2]: problem in tcp_v4_synq_add ?
2004-03-10 9:04 ` Paul Wagland
@ 2004-03-10 11:42 ` Viorel Canja, Softwin
2004-03-10 21:37 ` David S. Miller
1 sibling, 0 replies; 5+ messages in thread
From: Viorel Canja, Softwin @ 2004-03-10 11:42 UTC (permalink / raw)
To: Paul Wagland; +Cc: David S. Miller, linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem in tcp_v4_synq_add ?
2004-03-10 9:04 ` Paul Wagland
2004-03-10 11:42 ` Re[2]: " Viorel Canja, Softwin
@ 2004-03-10 21:37 ` David S. Miller
1 sibling, 0 replies; 5+ messages in thread
From: David S. Miller @ 2004-03-10 21:37 UTC (permalink / raw)
To: Paul Wagland; +Cc: vcanja, linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-03-10 21:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-09 11:27 problem in tcp_v4_synq_add ? Viorel Canja, Softwin
2004-03-09 19:30 ` David S. Miller
2004-03-10 9:04 ` Paul Wagland
2004-03-10 11:42 ` Re[2]: " Viorel Canja, Softwin
2004-03-10 21:37 ` David S. Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).