Messages in this thread | | | Subject | Re: [BUG][2.5.66bk9+] - tty hangings - patches, dmesg & sysctl+T info | From | Roland Dreier <> | Date | 08 Apr 2003 21:47:55 -0700 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |