Messages in this thread | | | Date | Wed, 16 Apr 2003 14:39:17 -0400 (EDT) | From | jamal <> | Subject | Re: [PATCH] qdisc oops fix |
| |
On Wed, 16 Apr 2003, Manfred Spraul wrote:
> 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? >
Catalin, Can you what kernel that is?
> >>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();
thats the one i meant.
> 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.
ok. Nice.
> > >>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. >
Probably a module. Again Catalin, run no modules.
> I'd add a > if(in_interrupt()) show_stack(NULL); > into qdisc_create_dflt(), and try to reproduce the bug without modules. >
Catalin - again instead of your fix can you please add this call?
cheers, jamal - 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/
| |