Messages in this thread | | | Date | Fri, 27 Sep 2002 19:04:06 -0700 (PDT) | From | Andre Hedrick <> | Subject | Re: Sleeping function called from illegal context... |
| |
No SLEEPING under a KMALLOC on a spinlock while calling request_irq is not the brightest thing ever done!
So your finger pointing stinks!
See in 2.4-ac there is a stub to indicate the brokeness.
int init_irq (ide_hwif_t *hwif) { unsigned long flags; unsigned int index; ide_hwgroup_t *hwgroup, *new_hwgroup; ide_hwif_t *match = NULL;
#if 0 /* Allocate the buffer and no sleep allowed */ new_hwgroup = kmalloc(sizeof(ide_hwgroup_t),GFP_ATOMIC); #else /* Allocate the buffer and potentially sleep first */ new_hwgroup = kmalloc(sizeof(ide_hwgroup_t),GFP_KERNEL); #endif
#ifndef __IRQ_HELL_SPIN save_and_cli(flags); #else spin_lock_irqsave(&io_request_lock, flags); #endif
<snip>
if (request_irq(hwif->irq,&ide_intr,sa,hwif->name,hwgroup)) { if (!match) kfree(hwgroup); #ifndef __IRQ_HELL_SPIN restore_flags(flags); #else spin_unlock_irqrestore(&io_request_lock, flags); #endif return 1; }
<snip>
/* all CPUs; safe now that hwif->hwgroup is set up */ #ifndef __IRQ_HELL_SPIN restore_flags(flags); #else spin_unlock_irqrestore(&io_request_lock, flags); #endif
See in trying to move to a spinlock it goes totally south. So now that you know the where, and why ... please go fix. See I am off working with AC on the issues for 2.4.
Also with PREMPT, bah never mind.
Regards,
Andre Hedrick LAD Storage Consulting Group
On Fri, 27 Sep 2002, Andrew Morton wrote:
> Greg KH wrote: > > > > So I got bold and enabled CONFIG_PREEMPT in 2.5.39, and got the > > following message at boot time: > > > > Sleeping function called from illegal context at slab.c:1374 > > c12a5ea8 c0117a26 c0296260 c0298202 0000055e c1283060 c013ab4f c0298202 > > 0000055e c03b668c 00000002 00000003 c01ff5ec c03b668c 00000042 c12838e0 > > c12838e0 c12838e0 00000246 cfdee214 c0207830 04000000 c03b65f0 c0109be2 > > Call Trace: > > [<c0117a26>]__might_sleep+0x56/0x5d > > [<c013ab4f>]kmalloc+0x4f/0x330 > > [<c01ff5ec>]piix_tune_chipset+0x33c/0x350 > > [<c0207830>]ide_intr+0x0/0x320 > > [<c0109be2>]request_irq+0x52/0xa0 > > [<c0200a33>]init_irq+0x263/0x400 > > [<c0207830>]ide_intr+0x0/0x320 > > [<c0200edc>]hwif_init+0x10c/0x260 > > [<c02006ad>]probe_hwif_init+0x1d/0x70 > > [<c02121d1>]ide_setup_pci_device+0x41/0x70 > > [<c01ff7a5>]piix_init_one+0x35/0x40 > > [<c010511b>]init+0x8b/0x250 > > [<c0105090>]init+0x0/0x250 > > [<c01055f9>]kernel_thread_helper+0x5/0xc > > > > Everyone will get this. It's IDE's init_irq() function doing > unsafe things inside ide_lock. > > It'll be quite harmless at boot-time, but it'd be nice to get > it fixed up. > - > 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/ >
- 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/
| |