lkml.org 
[lkml]   [2003]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG][2.5.66bk9+] - tty hangings - patches, dmesg & sysctl+T info
From
Date
    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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.425 / U:1.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site