Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: [patch] __lock_sock race condition in 2.3.18* | Date | Tue, 21 Sep 1999 21:32:03 +0400 (MSK DST) |
| |
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/
| |