Re: [patch] __lock_sock race condition in 2.3.18*

kuznet@ms2.inr.ac.ru
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/