>Hello!
>
>> The real problem I had in fixing this is that tcp_get_info() it's _not_
>> buggy and instead it's doing the right thing.
>
>Actually, it was buggy, because locking socket while holding hash lock
>is no-no-no.
Of course I agree it's buggy ;), I exaggerate in the above description.
What I meant is that _only_ for the locking order is buggy. What I meant
is that it's not a race but that it was only a genuine clean deadlock
condition.
So basically for this reason it wasn't trivial to fix (any possible fix
would impact other part of code or tcp_get_info would been unreliable).
>BTW you can kill lhash sleep lock now. rwlock is enough.
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.
Andrea
-
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/