Messages in this thread | | | Date | Thu, 7 Sep 2000 20:49:37 +0200 | From | Henner Eisen <> | Subject | Q: sock output serialization |
| |
Hi,
Is the following fix clean or are there better solutions?
There is a race condition in the Linux X.25 protocol stack. The stack has an x25_kick() function which dequeues as many skbŽs from sk->write_queue as the send windows allows and sends them downwards.
This kick function is called from send_msg() as well as (when an acknowledge arrives) from the input path of the socket code. The latter is usually called from NET_RX_SOFTIRQ and might therfore interrupt an x25_kick() executed on behalf of send_msg(). (This is a problem because it could mess up packet order which needs to be preserved with X.25).
The fix I came up with consists of replacing current x25_kick() by inlined __x25_kick() and defining a new x25_kick() which wraps the old function as follows:
atomic_inc(&sk->protinfo.x25->kick_it); if((atomic_read(&sk->protinfo.x25->kick_it)) != 1) return; do { __x25_kick(sk); } while (!atomic_dec_and_test(&sk->protinfo.x25->kick_it));
This makes __x25_kick single threaded per socket, the first thread in __x25_kick() will also perform the work for possible other threads which have tried to interrupt the first thread.
Is this a proper approach or are there better solutions (e.g. more SMP friendly, less overhead on certain hardware arch)?
What about 2.2.x? This should also work for 2.2.x, but for 2.2.x I could also wrap __x25_kick() inside {start,stop}_bh_atomic(), I guess.
Henner
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |