lis_free_irq() bug?

[e***@netscape.net]

Hello,

There seems to be a bug in lis_free_irq().

lis_spin_lock_irqsave(&lis_incr_lock, &psw) ;
for (; dv != NULL; dv = dv->link)
{
if (dv->dev_id == dev_id)
{
dv->handler = NULL ; <-------------- handler removed (A1)
dv->dev_id = NULL ;
dv->irq = 0 ;
lis_spin_unlock_irqrestore(&lis_incr_lock, &psw) ;
free_irq(irq, dv) ; <------------------------------- irq freed (A2)
return ;
}
}
lis_spin_unlock_irqrestore(&lis_incr_lock, &psw) ;


whereas:

static irqreturn_t lis_khandler(int irq, void *dev_id, struct pt_regs *regs) {
lis_devid_t *dv = (lis_devid_t *) dev_id ;
return(dv->handler(irq, dv->dev_id, regs)) ; <---------- handler can be called here (B1)
}



The problem is that if irq kicks in before it is released at (A2) but after handler is NULLed at (A1)
and lis_khandler() is called, it will fail at (B1) since dv->handler is NULL already.

Also, the dv structure that is allocated and linked to the list in lis_request_irq()
is not unlinked and freed in lis_free_irq().

I'm thinking how to fix this.

Any suggestions ?

thanks,
--
Eugene


___________________________________________________
Try the New Netscape Mail Today!
Virtually Spam-Free | More Storage | Import Your Contact List
http://mail.netscape.com

[Steve Schefter]

Post by e***@netscape.net
There seems to be a bug in lis_free_irq().
<snip>
The problem is that if irq kicks in before it is released at (A2) but
after handler is NULLed at (A1)
and lis_khandler() is called, it will fail at (B1) since dv->handler is NULL already.

With a quick look at the code, I would agree that the free_irq() call
should be moved up to before the handler is NULLed and that the dv
structure should be freed (as is done in lis_free_devid_list()).
Thanks for sharing.

Just one additional note on this in case you discovered this while
chasing down an interrupt problem: The hardware should be programmed
to no longer generate an interrupt _before_ lis_free_irq() is called.
If that is done, then that bug is only a problem when there are
shared interrupts. If that's not done, then there can still be
interrupt issues (unserviced IRQs) even after this is fixed.

Regards,
Steve

------------------------------------------------------------------------
Steve Schefter phone: [phone] x26
The Software Group Limited fax: [phone]
642 Welham Road, email: ***@wanware.com
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com