[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectQ: sock output serialization

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.036 / U:3.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site