lkml.org 
[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQ: 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/

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