lkml.org 
[lkml]   [1999]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] __lock_sock race condition in 2.3.18*
Date
Hello!

> I don't dislike very much the lhash sleep even now as the lhash loop may
> be slowww (lots of sprintf) while under multpile syn flooding attack and
> while under heavy network load with a long backlog of sockets waiting to
> be accepted. I like the other processor to not spin when possible while I
> am looking at the netstat information. I don't think the lhash_user check
> will add a significative overhead to the common case (when luser = 0). If
> you think it's adding a a singificative overhread I'll agree to remove it
> of course.

It will spin in any case. The first thing in tcp_lhash_wlock() is write_lock.

At least current implementation is good only to allow to sleep under
lock. If you do not sleep, it gives no advantages at all.

You are right in general. /proc/net/tcp and other /proc/net/* are
toys for children. I would not allow to access them on loaded servers.
I remember as old times each access /proc/net/tcp generated overruns
on all serial lines 8)8) Anyone may curse reading /dev/kmem, but it is really
the only working method appropirate for adult men yet 8)8)

Alexey

-
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.050 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site