On 09/24/2012 10:02 AM, Ivo Sieben wrote:

Hi,

2012/9/20 Alan Cox [off-list ref]:

quoted

So now when the user sets tty->low_latency on these devices the machine
crashes ?

This is the wrong direction - in fact we have a pile we need to move
the other way !

If they resolve to the same thing in hard RT patches fine, that's a
different question.

Sorry, Allan you are probably right, but I don't get it...

I agree that when the tty->low_latency flag is set on these machines,
the drivers that were modified by my patch will behave differently:
they will call the flush_to_ldisc() function directly instead of using
the work queue. So that indeed introduces different functionality.

But what I don't understand is how this would cause the machine to
crash? Even when the flush_to_ldisc() function is called from hard IRQ
context this would cause no problems: the flush_to_ldisc() function
uses IRQ save spin locks instead of mutexes to protect it's critical
section. Right?

Yes, but there are deadlocks caused when low_latency is set. Simply
because flush_to_ldisc calls tty->ops->flush_chars from ldisc's
receive_buf. And some drivers take a lock there. But they already hold
the lock from the site where they call tty_schedule_flip from.

Furthermore the majority of TTY drivers currently already use the
tty_flip_buffer_push() function.

Yes, but not all call tty_flip_buffer_push correctly. If you set
low_latency for them, they explode.

regards,
-- 
js
suse labs