On 09/24/2012 10:02 AM, Ivo Sieben wrote: > Hi, > > 2012/9/20 Alan Cox <alan@xxxxxxxxxxxxxxx>: >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
