Messages in this thread Patch in this message | ![/](/images/icornerl.gif) | | Subject | Re: [OOPS][2.5.66bk3+] run_timer_softirq - IRQ Mishandlings - New OOPS w/ timer | From | Roland Dreier <> | Date | 30 Mar 2003 16:00:51 -0800 |
| |
> --- 25/drivers/char/tty_io.c~a 2003-03-30 15:12:37.000000000 -0800 > +++ 25-akpm/drivers/char/tty_io.c 2003-03-30 15:16:59.000000000 -0800 > @@ -1288,6 +1288,8 @@ static void release_dev(struct file * fi > /* > * Make sure that the tty's task queue isn't activated. > */ > + clear_bit(TTY_DONT_FLIP, &tty->flags); > + del_timer_sync(&tty->flip.work.timer); > flush_scheduled_work(); I'm confused by this for two reasons:
First, from looking at workqueue.c (especially the comment in queue_delayed_work() that says "Increase nr_queued so that the flush function knows that there's something pending."), it seems like flush_scheduled_work() should wait until even delayed work is done. Given that, I don't think the del_timer_sync() should be there -- wouldn't flush_scheduled_work() block forever, since nr_queued can never reach 0 now?
(I guess I'm assuming the real race is that tty_io.c calls schedule_delayed_work() between flush_scheduled_work() and release_mem() in release_dev())
Second, I don't see how it's _ever_ safe to call flush_scheduled_work(). The comment in workqueue.c before flush_workqueue() says "NOTE: if work is being added to the queue constantly by some other context then this function might block indefinitely." But flush_scheduled_work() is flushing the keventd_wq, which other code will definitely add work to. If we're unlucky, flush_scheduled_work() could block forever. Am I just being paranoid?
- 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/
| ![\](/images/icornerr.gif) |