Re: Sleeping function called from illegal context...

[Andre Hedrick]

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 [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>