> The n_tty line discipline uses an atomic test and set flag to send the
> throttle first and then the unthrottle, but my driver actually
> receives them in the other order. It appears to me that there is no
> mechanism in place to prevent this race if the throttling code and the
> unthrottling code are running on different processors.
We stripped a ton of old big kernel locking out of n_tty recently and it
sounds like that problem was missed. The fact nobody uses n_tty at high
speed but uses ppp probably also hid it.
> easily have misunderstood how it fits together. Is it a problem in
> the line discipline, my driver, or me?
The ldisc
My first thought would be to make the throttle() path in n_tty do
something conceptually like:
if(test_and_set_bit()) {
ldisc->throttle();
if (!test_bit())
ldisc->unthrottle();
}
That would mean we relaxed the previous (intended) behaviour of matched
pairs but avoids adding a lot of locking horrors and scaling fun.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
