On Mon, 29 Jan 2007 16:29:29 +1100 Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 29, 2007 at 04:17:44PM +1100, Herbert Xu wrote: > > Michal Piotrowski <[EMAIL PROTECTED]> wrote: > > > > > Jan 28 22:58:29 euridica kernel: BUG: using smp_processor_id() in > > > preemptible [00000001] code: yum-updatesd/2846 > > > Jan 28 22:58:29 euridica kernel: caller is nf_conntrack_in+0x363/0x47f > > > [nf_conntrack] > > > Jan 28 22:58:29 euridica kernel: [<c01053c6>] > > > show_trace_log_lvl+0x1a/0x2f > > > Jan 28 22:58:29 euridica kernel: [<c0105ad6>] show_trace+0x12/0x14 > > > Jan 28 22:58:29 euridica kernel: [<c0105b98>] dump_stack+0x16/0x18 > > > Jan 28 22:58:29 euridica kernel: [<c0207803>] > > > debug_smp_processor_id+0xb3/0xc8 > > > Jan 28 22:58:29 euridica kernel: [<fdbf8ad0>] > > > nf_conntrack_in+0x363/0x47f [nf_conntrack] > > > Jan 28 22:58:29 euridica kernel: [<fd9c32c4>] > > > ipv4_conntrack_local+0x53/0x5b [nf_conntrack_ipv4] > > > Jan 28 22:58:29 euridica kernel: [<c02f2286>] nf_iterate+0x36/0x67 > > > Jan 28 22:58:29 euridica kernel: [<c02f241b>] nf_hook_slow+0x52/0xbe > > > > This shouldn't have happened. nf_hook_slow calls nf_iterate and > > therefore everything under it with preemption disabled. So something > > must've reenabled it before hitting nf_conntrack_in. > > Does mm now have the preemptible RCU stuff? If so that would certainly > explain this. It does, > IIRC Ingo had made fixes for the networking stack in his rt tree since > the networking code assumes in lots of places that rcu_read_lock > disables preemption. oh. We'd better find those fixes then. I wonder what other code made that (rather hacky) assumption? I guess we have enough debug stuff in there to find out.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
