lkml.org 
[lkml]   [2003]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] qdisc oops fix
    jamal wrote:

    >This is a different problem from previous one posted.
    >
    >Theres a small window (exposed given that you are provisioning a lot
    >of qdiscs and running traffic at the same time) that an incoming packet
    >interupt will cause the BUG().
    >
    >GFP_ATOMIC will fix it, but i wonder if it appropriate.
    >
    >
    This is a 2.4 kernel, correct?

    >>With many rules (~5000 classes and ~3500 qdiscs and ~50000 filters)
    >>the kernel oopses in slab.c:1128.
    >>
    This check?
    if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC)
    BUG();
    It's triggered, because someone does something like
    spin_lock_bh(&my_lock);
    p = kmalloc(,GFP_KERNEL);

    I don't like the proposed fix: usually code that calls
    kmalloc(,GFP_KERNEL) assumes that it runs at process space, e.g. uses
    semaphores, or non-bh spinlocks, etc.
    slab just happens to contain a test that complains about illegal calls.

    >>Trace; c0127e0f <kmalloc+eb/110>
    >>Trace; c01d3cac <qdisc_create_dflt+20/bc>
    >>Trace; d081ecc7 <END_OF_CODE+1054ff0f/????>
    >>Trace; c01d5265 <tc_ctl_tclass+1cd/214>
    >>Trace; d0820600 <END_OF_CODE+10551848/????>
    >>Trace; c01d27e4 <rtnetlink_rcv+298/3bc>
    >>Trace; c01d0605 <__neigh_event_send+89/1b4>
    >>Trace; c01d7cd4 <netlink_data_ready+1c/60>
    >>Trace; c01d7730 <netlink_unicast+230/278>
    >>Trace; c01d7b73 <netlink_sendmsg+1fb/20c>
    >>Trace; c01c79d5 <sock_sendmsg+69/88>
    >>Trace; c01c8b48 <sys_sendmsg+18c/1e8>
    >>Trace; c0120010 <map_user_kiobuf+8/f8>
    >>
    >>
    >>
    >>
    I don't understand the backtrace. Were any modules loaded? Perhaps
    0xd081ecc7 is a module.

    I'd add a
    if(in_interrupt()) show_stack(NULL);
    into qdisc_create_dflt(), and try to reproduce the bug without modules.

    --
    Manfred

    -
    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:34    [W:0.022 / U:31.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site