[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131218092815.GA3505@order.stressinduktion.org>
Date: Wed, 18 Dec 2013 10:28:15 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Ding Tianhong <dingtianhong@...wei.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>, yoshfuji@...ux-ipv6.org,
joe@...ches.com, vfalico@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: neighbour: add neighbour dead check for neigh_timer_handler()
On Wed, Dec 18, 2013 at 04:57:01PM +0800, Ding Tianhong wrote:
> On 2013/12/18 16:41, Hannes Frederic Sowa wrote:
> > On Wed, Dec 18, 2013 at 04:19:43PM +0800, Ding Tianhong wrote:
> >> 0xffffffff812f8e29 <neigh_timer_handler+265>: mov 0xe8(%rbx),%rax
> >> 0xffffffff812f8e30 <neigh_timer_handler+272>: mov %rbp,%rsi
> >> 0xffffffff812f8e33 <neigh_timer_handler+275>: mov %rbx,%rdi
> >> 0xffffffff812f8e36 <neigh_timer_handler+278>: callq *0x8(%rax) <-----crash
> >> /usr/src/linux/net/core/neighbour.c: 877
> >> 0xffffffff812f8e39 <neigh_timer_handler+281>: lea 0x3c(%rbx),%rax
> >
> > For me it looks like this:
> >
> > %rax is neigh->ops and the function pointer solicit is NULL and causes the the
> > page fault.
> >
> >
> yes, it is. So I was trying to find the situation that may free the neighbour when
> the timer is running, but I could not yet.
Hm. Ok. It is actually ops which is NULL, not the function pointer, may bad.
Could you try to follow param or table links and check if this is an arp or
ndisc one? Maybe some interactions with arp.c or ndisc.c causes this bug?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists