Re: [Xen-devel] BUG: unable to handle kernel NULL pointer dereference - xen_spin_lock_flags

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.12 at 16:37, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2012-02-14 at 15:28 +0000, Christopher S. Aker wrote:
>> On 2/14/12 5:09 AM, Ian Campbell wrote:
>> > I suspect this must be&netbk->net_schedule_list_lock but I don't see
>> > how that can ever be NULL nor does the offset appear to be 0x474, at
>> > least in my tree -- although that may depend on debug options.
>> >
>> > Are you rebooting guests or plug/unplugging vifs while this is going on?
>> 
>> Sorry - I'm relaying some of this on behalf of another team member.
>> 
>> The dom0 insta-panics when running iperf and then bringing a vif down 
>> (for a network rules rebuild).  We've only been able to trigger it when 
>> the dom0 is dealing with a boatload of packets.  So, it smells like a 
>> race between the vif being marked down, and something thinking it can 
>> still deliver packets to it...
>> 
>> root@dom0# ip link set vif2.0 down (return = BOOM)
>> br0: port 4(vif2.0) entering forwarding state
>> BUG: unable to handle kernel NULL pointer dereference at 00000474
>> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
>> ...
> 
> I wonder if this is related to the discussion in
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00981.html 
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00985.html 
> 
> Jan, do you recall what you did about that issue?

I did what I indicated we were asked at that time - add a safety
check to start_xmit() (which xen-netback appears to have too,
albeit in a slightly different form). Also, start_xmit() doesn't
appear on the call stack Christopher sent.

> Is it as simple as moving the call to netif_stop_queue(dev) in
> xenvif_close before the carrier check?

As said back then, it would appear to be more consistent, but
you're much more of an expert here than I am. We continue
to have netif_stop_queue() after the carrier check in our trees,
without anyone having reported a problem like this since we
did the above adjustment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel