Skip to content
Commit bbbab5ca authored by Ingo Molnar's avatar Ingo Molnar Committed by Jeff Garzik
Browse files

natsemi: fix oops, link back netdevice from private-struct

* Andrew Nelless <andrew@nelless.net> wrote:

> Hi,
>
> I booted up 2.6.24-rc1 this morning [Real early over a brew ;-)] and
> was having a problems with multiple ~5 second hangs on SATA/drive init
> (Something to do with "EH" something-or-other and resets but I'll
> email in separately about it later unless its fixed by the time I get
> the chance).
>
> Anyway, I went to fire up netconsole to get a decent log dump and hit
> across the following nasty. Netconsole works fine in 2.6.23.1 with a
> similar config and the same kernel parameters.
>
> A shot of the screen is the only method I could come up with to
> capture the log, I hope that is OK, it is pretty readable.
>
>
> The nasty:
> http://andotnet.nfshost.com/linux/2.6.24-rc1-netconsole-nullderef.jpg

the NULL dereference is here:

 (gdb) list *0xffffffff804a9504
 0xffffffff804a9504 is in natsemi_poll (drivers/net/natsemi.c:717).
 712             return count;
 713     }
 714
 715     static inline void __iomem *ns_ioaddr(struct net_device *dev)
 716     {
 717             return (void __iomem *) dev->base_addr;
 718     }
 719

which is this code from natsemi.c:

 2227            struct net_device *dev = np->dev;
 2228            void __iomem * ioaddr = ns_ioaddr(dev);
 2229            int work_done = 0;

seems like the NAPI changes in -rc1 added an np->dev field but forgot to
initialize it ...

does the patch below fix the oops for you?

	Ingo

-------------------->
Subject: natsemi: fix oops, link back netdevice from private-struct
From: Ingo Molnar <mingo@elte.hu>

this commit:

  commit bea3348e


  Author: Stephen Hemminger <shemminger@linux-foundation.org>
  Date:   Wed Oct 3 16:41:36 2007 -0700

      [NET]: Make NAPI polling independent of struct net_device objects.

added np->dev to drivers/net/natsemi.c's struct netdev_private, but
forgot to initialize that new field upon driver init. The result was
a predictable NULL dereference oops the first time the hardware
generated an interrupt.

Reported-by: default avatarAndrew Nelless <andrew@nelless.net>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
parent 0173b793
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment