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

["Shawn Starr" <spstarr@sh0n.net>]

drivers/char/tty_io.c - Only

I bet it's this function, there's only a kfree, not destruction of any
timers.

Added this rebuilt kernel waiting :-)

Shawn.

----- Original Message -----
From: "Roland Dreier" <roland@topspin.com>
To: "Shawn Starr" <spstarr@sh0n.net>
Cc: "Andrew Morton" <akpm@digeo.com>; <rml@tech9.net>;
<linux-kernel@vger.kernel.org>
Sent: Sunday, March 30, 2003 4:02 PM
Subject: Re: [OOPS][2.5.66bk3+] run_timer_softirq - IRQ Mishandlings - New
OOPS w/ timer


>     Shawn> Function found was: delayed_work_timer_fn
>     Shawn> (kernel/workqueue.c)
>
> It looks to me like something is calling schedule_delayed_work()
> (which calls queue_delayed_work(), which starts a timer) and then
> freeing the work_struct before it's executed.
>
> Here's a list of places that use schedule_delayed_work() where the
> work_struct might be kmalloc()ed.  Are you using any of these drivers?
> (Obviously you're using tty_io, so that bears some looking at)
>
>     drivers/char/cyclades.c
>     drivers/char/mxser.c
>     drivers/char/tty_io.c
>     drivers/isdn/i4l/isdn_tty.c
>     drivers/message/fusion/mptlan.c
>     drivers/net/hamradio/baycom_epp.c
>     drivers/net/plip.c
>     drivers/scsi/imm.c
>     drivers/scsi/ppa.c
>
> If tty_io.c is the problem, then maybe something like the patch below
> will find the culprit.
>
>   - Roland
>
> ===== drivers/char/tty_io.c 1.68 vs edited =====
> --- 1.68/drivers/char/tty_io.c Thu Mar 27 21:15:44 2003
> +++ edited/drivers/char/tty_io.c Sun Mar 30 12:51:00 2003
> @@ -169,6 +169,10 @@
>
>  static inline void free_tty_struct(struct tty_struct *tty)
>  {
> + if (timer_pending(&tty->flip.work.timer)) {
> + printk(KERN_WARNING "freeing tty with pending flip work timer from
[<%p>]\n",
> +        __builtin_return_address(0));
> + }
>   kfree(tty);
>  }
>
>