lkml.org 
[lkml]   [2002]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:29    [W:4.132 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site