Re: [OOPS][2.5.66bk3+] run_timer_softirq - IRQ Mishandlings - New OOPS w/ timer

[Roland Dreier <roland@topspin.com>]

  > --- 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