RE: bug seen with dynticks from CONFIG_HARDIRQS_SW_RESEND

[Woodruff, Richard]

> On Wed, 2007-05-16 at 18:20 -0500, Woodruff, Richard wrote:
> > The crashes were because the frame pointer per_cpu____irq_regs value
was
> > 0.  That code does a user_mode(get_irq_regs()).  Currently regs is
set
> > only upon real hardware entry on an irq.
> >
> > The crash path shows resend_irqs() could be called with in a context
> > where set_irq_regs() was not executed.  In one specific case this
was
> > from
> >
softirq->tasklet_action(resend_tasklet)->resend_irqs->handle_level_irq->
> > handle_IRQ_event->...->profile_tick.
> >
> > It seems anyone calling kernel/irq/manage.c:enable_irq() at the
wrong
> > time can trigger this crash.
> 
> which code is disabling / enabling the timer interrupt ?

- No one in this case is calling enable_irq(#timer). The failure is
triggered from a non-tick-related enable_irq(#x). The function
handle_IRQ_event() always calls handle_dynamic_tick(). Thus every real
interrupt or fake interrupt though resend_irq will touch the timer code
paths.

To better describe:
  -0- Users space does an ioctl to driver
  -1- This driver calls enable_irq(#x)
  -2- This triggers a check_irq_resend()
  -3- This causes a tasklet schedule of the resend_tasklet for #x
  -4- This driver later does a spin_unlock_bh
  -5- This triggers a check for softirq/tasklets
  -6- The resend_tasklet is run and calls desc->handle_irq
  -7- This calls handle_level_irq
  -8- This calls handle_IRQ_event
  -9- This first calls handle_dynamic_tick
  -A- This will call though the ticker code to tick update
  -B- Finally you die in profile_tick.
  -C- Boom in dereference of 0 from user_mode(regs)

As there was no real interrupt the frame marker for irq_regs was not set
and the system dies.  Entry was via trap from the ioctl, not irq do_irq.

A dummy non-zero frame allows it to work but doesn't give true
profiling.  The resend path seems generally unsafe today.  Why not set
it on traps?

Regards,
Richard W.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/