From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755447Ab0EVQCF (ORCPT ); Sat, 22 May 2010 12:02:05 -0400 Received: from ix.technologeek.org ([213.41.157.215]:51731 "EHLO sonic.technologeek.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753508Ab0EVQCA (ORCPT ); Sat, 22 May 2010 12:02:00 -0400 X-Greylist: delayed 411 seconds by postgrey-1.27 at vger.kernel.org; Sat, 22 May 2010 12:02:00 EDT From: Julien BLACHE To: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Subject: [regression] fib6_del() bug from 2.6.34-rc1 still present in 2.6.34 Date: Sat, 22 May 2010 17:55:06 +0200 Message-ID: <87632g53tx.fsf@sonic.technologeek.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, [subscribed to lkml but not netdev, Cc me on replies] I'm seeing a warning in fib6_del() that is very close to what was reported by Emil S Tantilov back in march/april for 2.6.34-rc1: It looks like there hasn't been a fix, other than what was mentioned in this thread for net-next and Emil reported that it did not fix it for him. So it looks like it's still there, alive and kicking. This is the warning I'm getting: ------------[ cut here ]------------ WARNING: at net/ipv6/ip6_fib.c:1160 fib6_del+0x506/0x5b0() Hardware name: MacBookPro2,2 Modules linked in: sco bnep rfcomm l2cap crc16 cpufreq_userspace cpufreq_powersave cpufreq_conservative nfsd nfs lockd auth_rpcgss sunrpc uinput btusb ath9k ath9k_common mac80211 ath9k_hw ath isight_firmware joydev cfg80211 i2c_i801 ohci1394 ieee1394 [last unloaded: scsi_wait_scan] Pid: 4020, comm: ifconfig Not tainted 2.6.34 #1 Call Trace: [] ? warn_slowpath_common+0x73/0xb0 [] ? fib6_del+0x506/0x5b0 [] ? __wake_up+0x43/0x70 [] ? netlink_broadcast+0x21f/0x410 [] ? __ip6_del_rt+0x4b/0x80 [] ? ip6_del_rt+0x26/0x30 [] ? __ipv6_ifa_notify+0x15f/0x200 [] ? addrconf_ifdown+0x159/0x350 [] ? addrconf_notify+0xed/0x920 [] ? lock_timer_base+0x33/0x70 [] ? mod_timer+0x11b/0x1a0 [] ? notifier_call_chain+0x46/0x70 [] ? __dev_notify_flags+0x65/0x90 [] ? dev_change_flags+0x3b/0x70 [] ? devinet_ioctl+0x602/0x750 [] ? T.945+0x1a/0x50 [] ? sock_ioctl+0x59/0x2a0 [] ? vfs_ioctl+0x35/0xd0 [] ? do_vfs_ioctl+0x88/0x570 [] ? sys_ioctl+0x49/0x80 [] ? system_call_fastpath+0x16/0x1b ---[ end trace b5a833c8e5539431 ]--- I can reliably reproduce it on both ath9k and sky2 with the following sequence: # ifconfig eth0 up # ifconfig eth0 add 2001:7a8:5dd7:123::12/64 # ifconfig eth0 down # ifconfig eth0 up # ifconfig eth0 add 2001:7a8:5dd7:123::12/64 <=== fails # ifconfig eth0 down <=== triggers the warning Note that this sequence is equivalent to: # ifup eth0 # ifdown eth0 # ifup eth0 (will fail because it cannot add the v6 address) # ifconfig eth0 down This regression breaks ifupdown as it always tries to add the v6 address when configuring the interface. It's a behaviour change compared to previous kernel versions. It looks like triggering this warning a couple times (3-4) in a row ends up locking up the machine, too. I can test patches etc. JB. -- Julien BLACHE GPG KeyID 0xF5D65169