Q: sock output serialization

From: Henner Eisen (eis@baty.hanse.de)
Date: Thu Sep 07 2000 - 13:49:37 EST


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:

         if((atomic_read(&sk->protinfo.x25->kick_it)) != 1) return;
         do {
         } 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.


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