lkml.org 
[lkml]   [1999]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] __lock_sock race condition in 2.3.18*
   From: kuznet@ms2.inr.ac.ru
Date: Mon, 20 Sep 1999 22:56:09 +0400 (MSK DST)

> Now I believe the race is in the tcp_lhash_* things but I had a
> look at them and I couldn't find anything wrong. I'll try
> again...

Let's search... Is it passive ftp? (tcp_lhash_wlock is used only
while listen() and closing listening socket)

Hmmm, Alexey consider a few things:

1) locking orders... I mean between socket lock and
lhash lock. Do you see it? I am rather certain this is a problem
even if it is not exactly the case Andrea is seeing.

I could be wrong on this one though...

2) Are you sure lhash wlock attempts (and thus potential sleeps)
cannot happen from BH context? Consider case where during user
context listening socket destruction some dangling reference
remains, BH deletes final reference and performs final listening
socket destruction. Or am I missing something?

Just some possible ideas...

Later,
David S. Miller
davem@redhat.com

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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.065 / U:0.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site