On Mon, 29 Jan 2007 16:29:29 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:

quoted text
> On Mon, Jan 29, 2007 at 04:17:44PM +1100, Herbert Xu wrote:
> > Michal Piotrowski <michal.k.k.piotrowski@gmail.com> 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,

quoted text
> 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..
-
unsubscribe notice
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/