The lock_sock() this is more broken than I realized - it should actually
work fine, but for all the wrong reasons. I think I remember why it was
that way, and it's not doing a "synchronize_bh()" like I thought it was
simply because that particular work-around was done before there _was_
anything like a synchronize_bh().
What lock_sock() should really do is
atomic_inc(&sk->sock_readers);
synchronize_bh();
instead of getting the main interrupt lock. The end result is the same,
but at least this way it's clearer what it tries to do (and I can remove
the "You don't want to know" comment ;)
Anyway, UDP seems to do this all correctly, putting the UDP packet on the
backlog if the socket was locked. So I don't think there should be any
problems with packet delivery, and the lock_sock() thing is more an issue
of performance and clarity than any outright bugs as far as I can tell.
Linus
-
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.altern.org/andrebalsa/doc/lkml-faq.html