- 10 Sep, 2012 2 commits
-
-
Wei Yongjun authored
The dereference should be moved below the NULL test. spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lennart Sorensen authored
I discovered I couldn't get sierra_net to work on a powerpc. Turns out the firmware attribute check assumes the system is little endian and hence fails because the attributes is a 16 bit value. Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 08 Sep, 2012 1 commit
-
-
Chema Gonzalez authored
In the current rxhash calculation function, while the sorting of the ports/addrs is coherent (you get the same rxhash for packets sharing the same 4-tuple, in both directions), ports and addrs are sorted independently. This implies packets from a connection between the same addresses but crossed ports hash to the same rxhash. For example, traffic between A=S:l and B=L:s is hashed (in both directions) from {L, S, {s, l}}. The same rxhash is obtained for packets between C=S:s and D=L:l. This patch ensures that you either swap both addrs and ports, or you swap none. Traffic between A and B, and traffic between C and D, get their rxhash from different sources ({L, S, {l, s}} for A<->B, and {L, S, {s, l}} for C<->D) The patch is co-written with Eric Dumazet <edumazet@google.com> Signed-off-by: Chema Gonzalez <chema@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 07 Sep, 2012 8 commits
-
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem John W. Linville says: ==================== Please pull these fixes intended for 3.6. There are more commits here than I would like -- I got a bit behind while I was stalking Steven Rostedt in San Diego last week... I'll slow it down after this! There are a couple of pulls here. One is from Johannes: "Please pull (according to the below information) to get a few fixes. * a fix to properly disconnect in the driver when authentication or association fails * a fix to prevent invalid information about mesh paths being reported to userspace * a memory leak fix in an nl80211 error path" The other comes via Gustavo: "A few updates for the 3.6 kernel. There are two btusb patches to add more supported devices through the new USB_VENDOR_AND_INTEFACE_INFO() macro and another one that add a new device id for a Sony Vaio laptop, one fix for a user-after-free and, finally, two patches from Vinicius to fix a issue in SMP pairing." Along with those... Arend van Spriel provides a fix for a use-after-free bug in brcmfmac. Daniel Drake avoids a hang by not trying to touch the libertas hardware duing suspend if it is already powered-down. Felix Fietkau provides a batch of ath9k fixes that adress some potential problems with power settings, as well as a fix to avoid a potential interrupt storm. Gertjan van Wingerde provides a register-width fix for rt2x00, and a rt2x00 fix to prevent incorrectly detecting the rfkill status. He also provides a device ID patch. Hante Meuleman gives us three brcmfmac fixes, one that properly initializes a command structure, one that fixes a race condition that could lose usb requests, and one that removes some log spam. Marc Kleine-Budde offers an rt2x00 fix for a voltage setting on some specific devices. Mohammed Shafi Shajakhan sent an ath9k fix to avoid a crash related to using timers that aren't allocated when 2 wire bluetooth coexistence hardware is in use. Sergei Poselenov changes rt2800usb to do some validity checking for received packets, avoiding crashes on an ARM Soc. Stone Piao gives us an mwifiex fix for an incorrectly set skb length value for a command buffer. All of these are localized to their specific drivers, and relatively small. The power-related patches from Felix are bigger than I would like, but I merged them in consideration of their isolation to ath9k and the sensitive nature of power settings in wireless devices. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jean Delvare authored
It doesn't seem this spinlock was properly initialized. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
In UDP recvmsg(), we miss an increase of UDP_MIB_INERRORS if the copy of skb to userspace failed for whatever reason. Reported-by: Shawn Bohrer <sbohrer@rgmadvisors.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eugenia Emantayev authored
If mlx4_cmd_init() failed, the init_one function returned success, although no resources were opened. Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aviad Yehezkel authored
The order of operations was wrong on the teardown flow. Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Aviad Yehezkel authored
The search for promisc entries was always done on the first port, While the addition is done on the correct port. This lead to resource leackage of promisc entries on the second port and brought to a state where we could no longer enter to promiscuous mode after enough iterations of "ifconfig promisc" on the second port. Fix that by using the correct port when searching. Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com> Signed-off-by: Aviad Yehezkel <aviadye@mellanox.com> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hadar Hen Zion authored
Since VFs may be mapped to VMs which aren't trusted entities, flow steering rules attached through the wrapper on behalf of VFs must be checked to make sure that their L2 specification relate to MAC address assigned to that VF, and add L2 specification if its missing. Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hadar Hen Zion authored
To allow for usage of the flow steering Firmware structures in more locations over the driver, such as the resource tracker, move them from mcg.c to common header files. Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 05 Sep, 2012 24 commits
-
-
Santiago Leon authored
This patch fixes a bug found by Nish Aravamudan (https://lkml.org/lkml/2012/5/15/220) where the driver is not following the spec (it is not aligning the rx buffer on a 16-byte boundary) and the hypervisor aborts the registration, making the device unusable. The fix follows BenH's recommendation (https://lkml.org/lkml/2012/7/20/461) to replace the kmalloc+map for a single call to dma_alloc_coherent() because that function always aligns to a 16-byte boundary. The stable trees will run into this bug whenever the rx buffer kmalloc call returns something not aligned on a 16-byte boundary. Cc: <stable@vger.kernel.org> Signed-off-by: Santiago Leon <santil@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Julian Anastasov authored
commit 144d56e9 ("tcp: fix possible socket refcount problem") is missing the IPv6 part. As tcp_release_cb is shared by both protocols we should hold sock reference for the TCP_MTU_REDUCED_DEFERRED bit. Signed-off-by: Julian Anastasov <ja@ssi.bg> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://gitorious.org/linux-can/linux-canDavid S. Miller authored
Marc Kleine-Budde says: ==================== this patch is for the v3.6 release cycle. Benoît Locher fixed a repeated frame bug in the mcp251x driver. He implemented the workaround suggested by the errata sheet. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Drake authored
When the interface is down, the hardware is powered off. However, the suspend handler currently tries to send host sleep commands (when wakeup params are set) in this configuration, causing a system hang when going into suspend (the commands will never complete). Avoid this by detecting this situation and simply returning from the suspend handler without doing anything special. Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sergei Poselenov authored
On our system (ARM Cortex-M3 SOC running linux-2.6.33) frequent crashes were observed in the rt2800usb module because of the invalid length of the received packet (3392, 46920...). This patch adds the sanity check on the packet legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone() so that the bad packet condition would be noticed. The fix was tested on the latest compat-wireless-3.5.1-1-snpc. Cc: stable@vger.kernel.org Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
We need to program the rfkill switch GPIO pin direction to input at device initialization time, not only when the interface is brought up. Doing this only when the interface is brought up could lead to rfkill detecting the switch is turned on erroneously and inability to create the interface and bringing it up. Reported-and-tested-by: Andreas Messer <andi@bastelmap.de> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
The register is 16 bits wide, not 32. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
This is an RT3572 based device. Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
The function brcmf_cfg80211_get_station requests the RSSI from the device. The complete structure used needs to be cleared before sending the request to firmware. Otherwise the request fails filling the logs with "Could not get rssi (-2)" messages. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
On both rx and tx there is was a race condition on the queueing of usb requests. When for example frame gets submitted it is possible that complete function gets called even before usb_submit_urb() returns. As a result it is possible that usb requests get losts, which was noticed on OMAP4 pandaboard platform. This patch fixes the race condition. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
URB_ZERO_PACKET should only be set or bulk OUT and this condition is checked with a WARN_ON in usb_submit_urb(). This patch fixes brcmfmac to get rid of this warning filling the logs. Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
The USB part of the brcmfmac did a dev_kfree_skb() that resulted in a warning in net/core/skbuff.c: Jul 11 04:53:33 lb-bun-10 kernel: [53282.667745] WARNING: at net/core/skbuff.c:490 skb_release_head_state+0xcc/0xe0() The brcmutil modules provides brcmu_pkt_buf_free_skb() which takes the context into account. This patch makes use of this function instead of dev_kfree_skb(). Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
Generic timers for BTCOEX functionality is applicable only for 3 WIRE BTCOEX (and MCI) chipsets. Hence btcoex->no_stomp_timer is allocated only 3 WIRE btcoex chipsets and in all the other cases its NULL. Make sure we stop the generic timer only if 'btcoex->hw_timer_enabled' is true(only if its up and running) Fixes the following crash [68757.020454] BUG: unable to handle kernel NULL pointer dereference at 0000000c [68757.020916] IP: [<f9b055c3>] ath9k_hw_gen_timer_stop+0x13/0x80 [ath9k_hw] [68757.021251] *pde = 00000000 [68757.024384] EIP: 0060:[<f9b055c3>] EFLAGS: 00010082 CPU: 0 [68757.024384] EIP is at ath9k_hw_gen_timer_stop+0x13/0x80 [ath9k_hw] [68757.024384] EAX: d32d0000 EBX: d32d0000 ECX: 00000000 EDX: 00000000 [68757.024384] ESI: e67c24c0 EDI: 00000296 EBP: e137be2c ESP: e137be20 [68757.024384] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [68757.024384] CR0: 8005003b CR2: 0000000c CR3: 00b99000 CR4: 000407d0 [68757.024384] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [68757.024384] DR6: ffff0ff0 DR7: 00000400 [68757.024384] Process kworker/u:2 (pid: 8917, ti=e137a000 task=ea7a6860 task.ti=e137a000) [68757.024384] Stack: [68757.024384] c06c4676 d32d0000 e67c24c0 e137be38 f81c9590 e67c1ca0 e137be40 f81c95d9 [68757.024384] e137be64 f81cd1c5 00000246 00000002 d32d0000 e67c05e0 e67c1ca0 e67c05e0 [68757.024384] 00000000 e137beac f81cdfa0 e137be84 00000246 00000246 e67c1ca0 e67c1ca0 [68757.024384] Call Trace: [68757.024384] [<c06c4676>] ? _raw_spin_lock_irqsave+0x86/0xa0 [68757.024384] [<f81c9590>] ath9k_gen_timer_stop+0x10/0x40 [ath9k] [68757.024384] [<f81c95d9>] ath9k_btcoex_stop_gen_timer+0x19/0x20 [ath9k] [68757.024384] [<f81cd1c5>] ath9k_ps_restore+0x85/0x110 [ath9k] [68757.024384] [<f81cdfa0>] ath9k_config+0x220/0x520 [ath9k] [68757.024384] [<f81cd47d>] ? ath9k_flush+0x15d/0x1b0 [ath9k] [68757.024384] [<f85c7ca5>] ieee80211_hw_config+0x135/0x2c0 [mac80211] [68757.024384] [<f860e3c8>] ieee80211_dynamic_ps_enable_work+0x198/0x5f0 [mac80211] Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Cc: Bala Shanmugam <bkamatch@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
This feature had been disabled in ath9k because the code to support it was incomplete, but now the code is in sync with the internal QCA codebase, so it's time to enable it. On many newer devices, the calibration is assumed to be done with PA linearization enabled. Tests with a particular AR933x device showed that the signal emitted at full power was highly distorted and unreliable with PA linearization disabled. With this patch, the signal becomes clear and stability is improved. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Before PAPRD training can run, the card needs to have sent a packet for thermal calibration. Sending a dummy packet with the PAPRD training flag set causes a crash under some circumstance. Fix the code by replacing the dummy tx with a delay that waits for a real packet tx to have occurred. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Support for it is incomplete Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Re-train if the calibrated PA linearization curve is out of bounds (affects AR933x and AR9485). Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
That predistortion type is not supported Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The interrupt is no longer handling it. While it shouldn't fire (wraparound is highly unlikely), the consequences would be fatal (interrupt storm). Disable the interrupt to prevent that from happening. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Marc Kleine-Budde authored
According to the vendor driver v2.6.0.1, during the rf register init the SRAM voltage should be increased to 1.35V and after 1ms decreased back to 1.2V. This patch adds the field setting of LDO_CFG0_LDO_CORE_VLEVEL accordingly. Cc: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stone Piao authored
When we send a command to firmware, we assumed that cmd_size will be always less than or equal to the structure size of host_cmd_ds_command. However, this is no longer true after we added AP support. There are some AP commands that Custom IE TLVs are included in command buffer, hence the cmd_size gets enlarged by the TLV data. We need to increase the skb length for the extra data. Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
-
LEO Airwarosu Yoichi Shinoda authored
Various small fixes for net/mac80211/cfg.c:mpath_set_pinfo(): Initialize *pinfo before filling members in, handle MESH_PATH_RESOLVED correctly, and remove bogus assignment; result in correct display of FLAGS values and meaningful EXPTIME for expired paths in iw utility. Signed-off-by: Yoichi Shinoda <shinoda@jaist.ac.jp> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 04 Sep, 2012 5 commits
-
-
Eric Dumazet authored
While investigating l2tp bug, I hit a bug in eth_type_trans(), because not enough bytes were pulled in skb head. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wu Fengguang authored
In znet_probe(), strncmp() may access beyond 0x100000 and trigger the below oops in kvm. Fix it by limiting the loop under 0x100000-8. I suspect the limit could be further decreased to 0x100000-sizeof(struct netidblk), however no datasheet at hand.. [ 3.744312] BUG: unable to handle kernel paging request at 80100000 [ 3.746145] IP: [<8119d12a>] strncmp+0xc/0x20 [ 3.747446] *pde = 01d10067 *pte = 00100160 [ 3.747493] Oops: 0000 [#1] DEBUG_PAGEALLOC [ 3.747493] Pid: 1, comm: swapper Not tainted 3.6.0-rc1-00018-g57bfc0a7 #73 Bochs Bochs [ 3.747493] EIP: 0060:[<8119d12a>] EFLAGS: 00010206 CPU: 0 [ 3.747493] EIP is at strncmp+0xc/0x20 [ 3.747493] EAX: 800fff4e EBX: 00000006 ECX: 00000006 EDX: 814d2bb9 [ 3.747493] ESI: 80100000 EDI: 814d2bba EBP: 8e03dfa0 ESP: 8e03df98 [ 3.747493] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 3.747493] CR0: 8005003b CR2: 80100000 CR3: 016f7000 CR4: 00000690 [ 3.747493] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 3.747493] DR6: ffff0ff0 DR7: 00000400 [ 3.747493] Process swapper (pid: 1, ti=8e03c000 task=8e040000 task.ti=8e03c000) [ 3.747493] Stack: [ 3.747493] 800fffff 00000000 8e03dfb4 816a1376 00000006 816a134a 00000000 8e03dfd0 [ 3.747493] 816819b5 816ed1c0 8e03dfe4 00000006 00000123 816ed604 8e03dfe4 81681b29 [ 3.747493] 00000000 81681a5b 00000000 00000000 8134e542 00000000 00000000 00000000 [ 3.747493] Call Trace: [ 3.747493] [<816a1376>] znet_probe+0x2c/0x26b [ 3.747493] [<816a134a>] ? dnet_driver_init+0xf/0xf [ 3.747493] [<816819b5>] do_one_initcall+0x6a/0x110 [ 3.747493] [<81681b29>] kernel_init+0xce/0x14b Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steffen Klassert authored
ESN for esp is defined in RFC 4303. This RFC assumes that the sequence number counters are always up to date. However, this is not true if an async crypto algorithm is employed. If the sequence number counters are not up to date on sequence number check, we may incorrectly update the upper 32 bit of the sequence number. This leads to a DOS. We workaround this by comparing the upper sequence number, (used for authentication) with the upper sequence number computed after the async processing. We drop the packet if these numbers are different. To do this, we introduce a recheck function that does this check in the ESN case. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Fixes following lockdep splat : [ 1614.734896] ============================================= [ 1614.734898] [ INFO: possible recursive locking detected ] [ 1614.734901] 3.6.0-rc3+ #782 Not tainted [ 1614.734903] --------------------------------------------- [ 1614.734905] swapper/11/0 is trying to acquire lock: [ 1614.734907] (slock-AF_INET){+.-...}, at: [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.734920] [ 1614.734920] but task is already holding lock: [ 1614.734922] (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0 [ 1614.734932] [ 1614.734932] other info that might help us debug this: [ 1614.734935] Possible unsafe locking scenario: [ 1614.734935] [ 1614.734937] CPU0 [ 1614.734938] ---- [ 1614.734940] lock(slock-AF_INET); [ 1614.734943] lock(slock-AF_INET); [ 1614.734946] [ 1614.734946] *** DEADLOCK *** [ 1614.734946] [ 1614.734949] May be due to missing lock nesting notation [ 1614.734949] [ 1614.734952] 7 locks held by swapper/11/0: [ 1614.734954] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff81592801>] __netif_receive_skb+0x251/0xd00 [ 1614.734964] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff815d319c>] ip_local_deliver_finish+0x4c/0x4e0 [ 1614.734972] #2: (rcu_read_lock){.+.+..}, at: [<ffffffff8160d116>] icmp_socket_deliver+0x46/0x230 [ 1614.734982] #3: (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0 [ 1614.734989] #4: (rcu_read_lock){.+.+..}, at: [<ffffffff815da240>] ip_queue_xmit+0x0/0x680 [ 1614.734997] #5: (rcu_read_lock_bh){.+....}, at: [<ffffffff815d9925>] ip_finish_output+0x135/0x890 [ 1614.735004] #6: (rcu_read_lock_bh){.+....}, at: [<ffffffff81595680>] dev_queue_xmit+0x0/0xe00 [ 1614.735012] [ 1614.735012] stack backtrace: [ 1614.735016] Pid: 0, comm: swapper/11 Not tainted 3.6.0-rc3+ #782 [ 1614.735018] Call Trace: [ 1614.735020] <IRQ> [<ffffffff810a50ac>] __lock_acquire+0x144c/0x1b10 [ 1614.735033] [<ffffffff810a334b>] ? check_usage+0x9b/0x4d0 [ 1614.735037] [<ffffffff810a6762>] ? mark_held_locks+0x82/0x130 [ 1614.735042] [<ffffffff810a5df0>] lock_acquire+0x90/0x200 [ 1614.735047] [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.735051] [<ffffffff810a69ad>] ? trace_hardirqs_on+0xd/0x10 [ 1614.735060] [<ffffffff81749b31>] _raw_spin_lock+0x41/0x50 [ 1614.735065] [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.735069] [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core] [ 1614.735075] [<ffffffffa014f7f2>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth] [ 1614.735079] [<ffffffff81595112>] dev_hard_start_xmit+0x502/0xa70 [ 1614.735083] [<ffffffff81594c6e>] ? dev_hard_start_xmit+0x5e/0xa70 [ 1614.735087] [<ffffffff815957c1>] ? dev_queue_xmit+0x141/0xe00 [ 1614.735093] [<ffffffff815b622e>] sch_direct_xmit+0xfe/0x290 [ 1614.735098] [<ffffffff81595865>] dev_queue_xmit+0x1e5/0xe00 [ 1614.735102] [<ffffffff81595680>] ? dev_hard_start_xmit+0xa70/0xa70 [ 1614.735106] [<ffffffff815b4daa>] ? eth_header+0x3a/0xf0 [ 1614.735111] [<ffffffff8161d33e>] ? fib_get_table+0x2e/0x280 [ 1614.735117] [<ffffffff8160a7e2>] arp_xmit+0x22/0x60 [ 1614.735121] [<ffffffff8160a863>] arp_send+0x43/0x50 [ 1614.735125] [<ffffffff8160b82f>] arp_solicit+0x18f/0x450 [ 1614.735132] [<ffffffff8159d9da>] neigh_probe+0x4a/0x70 [ 1614.735137] [<ffffffff815a191a>] __neigh_event_send+0xea/0x300 [ 1614.735141] [<ffffffff815a1c93>] neigh_resolve_output+0x163/0x260 [ 1614.735146] [<ffffffff815d9cf5>] ip_finish_output+0x505/0x890 [ 1614.735150] [<ffffffff815d9925>] ? ip_finish_output+0x135/0x890 [ 1614.735154] [<ffffffff815dae79>] ip_output+0x59/0xf0 [ 1614.735158] [<ffffffff815da1cd>] ip_local_out+0x2d/0xa0 [ 1614.735162] [<ffffffff815da403>] ip_queue_xmit+0x1c3/0x680 [ 1614.735165] [<ffffffff815da240>] ? ip_local_out+0xa0/0xa0 [ 1614.735172] [<ffffffff815f4402>] tcp_transmit_skb+0x402/0xa60 [ 1614.735177] [<ffffffff815f5a11>] tcp_retransmit_skb+0x1a1/0x620 [ 1614.735181] [<ffffffff815f7e93>] tcp_retransmit_timer+0x393/0x960 [ 1614.735185] [<ffffffff815fce23>] ? tcp_v4_err+0x163/0x6b0 [ 1614.735189] [<ffffffff815fd317>] tcp_v4_err+0x657/0x6b0 [ 1614.735194] [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230 [ 1614.735199] [<ffffffff8160d19e>] icmp_socket_deliver+0xce/0x230 [ 1614.735203] [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230 [ 1614.735208] [<ffffffff8160d464>] icmp_unreach+0xe4/0x2c0 [ 1614.735213] [<ffffffff8160e520>] icmp_rcv+0x350/0x4a0 [ 1614.735217] [<ffffffff815d3285>] ip_local_deliver_finish+0x135/0x4e0 [ 1614.735221] [<ffffffff815d319c>] ? ip_local_deliver_finish+0x4c/0x4e0 [ 1614.735225] [<ffffffff815d3ffa>] ip_local_deliver+0x4a/0x90 [ 1614.735229] [<ffffffff815d37b7>] ip_rcv_finish+0x187/0x730 [ 1614.735233] [<ffffffff815d425d>] ip_rcv+0x21d/0x300 [ 1614.735237] [<ffffffff81592a1b>] __netif_receive_skb+0x46b/0xd00 [ 1614.735241] [<ffffffff81592801>] ? __netif_receive_skb+0x251/0xd00 [ 1614.735245] [<ffffffff81593368>] process_backlog+0xb8/0x180 [ 1614.735249] [<ffffffff81593cf9>] net_rx_action+0x159/0x330 [ 1614.735257] [<ffffffff810491f0>] __do_softirq+0xd0/0x3e0 [ 1614.735264] [<ffffffff8109ed24>] ? tick_program_event+0x24/0x30 [ 1614.735270] [<ffffffff8175419c>] call_softirq+0x1c/0x30 [ 1614.735278] [<ffffffff8100425d>] do_softirq+0x8d/0xc0 [ 1614.735282] [<ffffffff8104983e>] irq_exit+0xae/0xe0 [ 1614.735287] [<ffffffff8175494e>] smp_apic_timer_interrupt+0x6e/0x99 [ 1614.735291] [<ffffffff81753a1c>] apic_timer_interrupt+0x6c/0x80 [ 1614.735293] <EOI> [<ffffffff810a14ad>] ? trace_hardirqs_off+0xd/0x10 [ 1614.735306] [<ffffffff81336f85>] ? intel_idle+0xf5/0x150 [ 1614.735310] [<ffffffff81336f7e>] ? intel_idle+0xee/0x150 [ 1614.735317] [<ffffffff814e6ea9>] cpuidle_enter+0x19/0x20 [ 1614.735321] [<ffffffff814e7538>] cpuidle_idle_call+0xa8/0x630 [ 1614.735327] [<ffffffff8100c1ba>] cpu_idle+0x8a/0xe0 [ 1614.735333] [<ffffffff8173762e>] start_secondary+0x220/0x222 Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-