Re: [2.6.0-test-9] natsemi oops

Re: [2.6.0-test-9] natsemi oops

[Manfred Spraul]

[netdev added to cc list: it looks like a module refcount bug with ipx]

David Liontooth wrote:

>The natsemi oops is triggered in 2.6.0-test9 too. 
>
>kernel BUG at include/linux/module.h:296
>  
>
That's BUG_ON(module_refcount(module) == 0) in __module_get. I doubt 
that the natsemi driver has anything to do with the bug, it looks like a 
bug in the ipx core.

>Everything freezes. 
>
>Am I the only one to get this? 
>
>I don't know when it started, but 2.5.69 has no problems.
>  
>
My guess: 2.5.69 has no bug check. It will oops with the right timing of 
rmmod and a packet arrival.

>Cheers,
>David
>
>
>----- Original Message -----
>From: "David Liontooth" <liontooth@post.com>
>Date: Mon, 20 Oct 2003 21:05:13 -0500
>To: linux-kernel@vger.kernel.org
>Subject: Re: [2.6.0-test-7] natsemi oops
>
>  
>
>>Correction: I get the oops also when natsemi is compiled as a module. 
>>It is triggered not when the module is loaded, but when it is used 
>>the first time. Oops (some fragments below) followed by a total freeze;
>>nothing gets logged.
>>
>>Is this a known problem? 
>>
>>Is there a workaround?
>>
>>Cheers,
>>David
>>
>>
>>----- Original Message -----
>>From: David Liontooth
>>Date: Mon, 20 Oct 2003 05:24:52 -0500
>>To: linux-kernel@vger.kernel.org
>>Subject: [2.6.0-test-7] natsemi oops
>>
>>    
>>
>>>The 2.6.0-test-7 boots fine and works great -- until I plug
>>>in the ethernet cable. Within a second I get an oops and
>>>everything freezes. Booting with "acpi=off" makes no difference.
>>>If I boot with the ethernet cable plugged in, I get to the 
>>>login prompt, and it oopses within a second. If I time it right,
>>>I can log into the machine remotely for one second before it 
>>>oopses (so the natsemi driver is working). Very reproducible! 
>>>/proc/kmsg is empty. 
>>>
>>>If I compile natsemi as a module, I don't get the oops. 
>>>However, now the driver is not working -- I can't ping out.
>>>Everything works fine in 2.5.69, which I've been running
>>>since early July.
>>>
>>>Here's some of the oops, taken by hand:
>>>
>>>Process swapper (pid: 0, threadinfo=c042a000 task c03a47a0)
>>>
>>>Stack
>>>
>>>Call trace:
>>>
>>>ipxitf_auto_create
>>>ipx_rcv
>>>netif_receive_skb
>>>process_backlog
>>>net_rx_action
>>>do_softirq
>>>do_IRQ
>>>_stext
>>>common_interrupt
>>>acpi_processor_idle
>>>cpu_idle
>>>start_kernel
>>>unknown_bootoption
>>>
>>>Kernel panic: Fatal exception in interrupt
>>>In interrupt handler -- not syncing
>>>
>>>Configuration, lspci, and dmesg attached.
>>>
>>>Cheers,
>>>David
>>>
>>>
>>>
>>>      
>>>
>><< config-2.6.0-test7-3 >>
>><< dmesg-2.6.0-test7-7 >>
>><< lspci-2.6.0-test7 >>
>>
>>-- 
>>__________________________________________________________
>>Sign-up for your own personalized E-mail at Mail.com
>>http://www.mail.com/?sr=signup
>>
>>CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
>>http://corp.mail.com/careers
>>
>>    
>>
>
>  
>

--
    Manfred

[PATCH] Fix for ipx interface module_get panic.

[Stephen Hemminger]

This is the fix for the ipx module_get oops; it has been tested by acme.
The problem was that ipx was trying to use module counts to keep from being
unloaded when it had bottom half interfaces.  And one of these interfaces
could be created automatically when packet was received and no sockets open
(module ref count was zero).

The fix is to get rid of using module ref counts to control this, and instead
cleanup the table on module exit.

diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
--- a/net/ipx/af_ipx.c	Thu Oct 30 12:01:21 2003
+++ b/net/ipx/af_ipx.c	Thu Oct 30 12:01:21 2003
@@ -326,7 +326,6 @@
 	if (intrfc->if_dev)
 		dev_put(intrfc->if_dev);
 	kfree(intrfc);
-	module_put(THIS_MODULE);
 }
 
 void ipxitf_down(struct ipx_interface *intrfc)
@@ -358,6 +357,17 @@
 	return NOTIFY_DONE;
 }
 
+
+static __exit void ipxitf_cleanup(void)
+{
+	struct ipx_interface *i, *tmp;
+
+	spin_lock_bh(&ipx_interfaces_lock);
+	list_for_each_entry_safe(i, tmp, &ipx_interfaces, node) 
+		__ipxitf_put(i);
+	spin_unlock_bh(&ipx_interfaces_lock);
+}
+
 static void ipxitf_def_skb_handler(struct sock *sock, struct sk_buff *skb)
 {
 	if (sock_queue_rcv_skb(sock, skb) < 0)
@@ -888,7 +898,6 @@
 		INIT_HLIST_HEAD(&intrfc->if_sklist);
 		atomic_set(&intrfc->refcnt, 1);
 		spin_lock_init(&intrfc->if_sklist_lock);
-		__module_get(THIS_MODULE);
 	}
 
 	return intrfc;
@@ -1979,20 +1988,12 @@
 
 static void __exit ipx_proto_finito(void)
 {
-	/*
-	 * No need to worry about having anything on the ipx_interfaces list,
-	 * when a interface is created we increment the module usage count, so
-	 * the module will only be unloaded when there are no more interfaces
-	 */
-	if (unlikely(!list_empty(&ipx_interfaces)))
-		BUG();
-	if (unlikely(!list_empty(&ipx_routes)))
-		BUG();
-
 	ipx_proc_exit();
 	ipx_unregister_sysctl();
 
 	unregister_netdevice_notifier(&ipx_dev_notifier);
+
+	ipxitf_cleanup();
 
 	unregister_snap_client(pSNAP_datalink);
 	pSNAP_datalink = NULL;