Re: [BUG][2.5.66bk9+] - tty hangings - patches, dmesg & sysctl+T info

[Roland Dreier <roland@topspin.com>]

    Andrew> Well it does look like you've hit the flush_workqueue
    Andrew> livelock.

I don't think it's really livelock.  I think it's just the fact that
his kernel (with your tty-shutdown-race-fix patch) does
del_timer_sync() without decrementing nr_queued() and so
flush_workqueue() never returns.

Still, I like the idea of this patch, since it resolves the livelock.
But I don't think the implementation is quite right.  insert_sequence
doesn't get incremented until delayed_work_timer_fn().  That means
that a driver (tty_io.c, for example) could call
schedule_delayed_work(), then call flush_scheduled_work() before
delayed_work_timer_fn() has run for that work.

In that case schedule_delayed_work() could return immediately because
insert_sequence and remove_sequence are (probably) equal.  Then
delayed_work_timer_fn() runs after the driver exits, and we're back
with the original problem (running a freed timer).

It should be pretty easy to rejigger the patch so that it works
correctly, just by moving the cwq->insert_sequence++ from
delayed_work_timer_fn() into queue_delayed_work() (right before the
add_timer(), say).  I'm still not positive that this covers
everything; I need to think a little harder.

In any case, I think we still have to do something to fix
release_dev() in tty_io.c.  It seems we should at least add the
clear_bit(TTY_DONT_FLIP, &tty->flags); however, I'm not familiar
enough with how the tty driver works to know whether TTY_DONT_FLIP
could get set again (while we're waiting for flush_scheduled_work()).
If so we would also need something along the lines of
cancel_delayed_work(&tty->flip.work).

Shawn, I think the patch I just posted a little while ago (with a
fixed cancel_delayed_work() implementation) is more likely to cure
your tty hanging right now.  However, I think something along the
lines of this patch from Andrew is a better solution in the long run.

 - Roland