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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:31 EST