- 30 Jul, 2013 2 commits
-
-
Uwe Kleine-König authored
Don't test for having link and let hardware deal with this situation. Without this patch I see a machine running an -rt patched Linux being stuck in sch_direct_xmit when it looses link while there is still a packet to be sent. In this case the fec_enet_start_xmit routine returned NETDEV_TX_BUSY which makes the network stack reschedule the packet and so sch_direct_xmit calls fec_enet_start_xmit again. I failed to reproduce a complete hang without -rt, but I think the problem exists there, too. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Make sure the reserved fields, and padding (if any), are fully initialized. Based upon a patch by Dan Carpenter and feedback from Joe Perches. Signed-off-by:
-
- 28 Jul, 2013 9 commits
-
-
Emil Tantilov authored
This patch fixes a VT mode check to make sure VLAN filters are disabled when in promisc mode and VT is not enabled. The problem with the previous check was that: E1000_MRQC_ENABLE_VMDQ is defined as 0x00000003 but when not in VT mode: mrqc |= E1000_MRQC_ENABLE_RSS_4Q (0x00000002) So the above check will trigger regardless if VT mode is being used or not. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Jacob Keller authored
This patch fixes an issue with the 82598EB device, where lldpad is causing Tx Hangs on the card as soon as it attempts to configure DCB for the device. The adapter will continually Tx hang and reset in a loop. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Cc: Stable <stable@vger.kernel.org> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Tested-by:
Jack Morgan <jack.morgan@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
Requesting external module with cb_lock taken can result in the deadlock like showed below: [ 2458.111347] Showing all locks held in the system: [ 2458.111347] 1 lock held by NetworkManager/582: [ 2458.111347] #0: (cb_lock){++++++}, at: [<ffffffff8162bc79>] genl_rcv+0x19/0x40 [ 2458.111347] 1 lock held by modprobe/603: [ 2458.111347] #0: (cb_lock){++++++}, at: [<ffffffff8162baa5>] genl_lock_all+0x15/0x30 [ 2461.579457] SysRq : Show Blocked State [ 2461.580103] task PC stack pid father [ 2461.580103] NetworkManager D ffff880034b84500 4040 582 1 0x00000080 [ 2461.580103] ffff8800197ff720 0000000000000046 00000000001d5340 ffff8800197fffd8 [ 2461.580103] ffff8800197fffd8 00000000001d5340 ffff880019631700 7fffffffffffffff [ 2461.580103] ffff8800197ff880 ffff8800197ff878 ffff880019631700 ffff880019631700 [ 2461.580103] Call Trace: [ 2461.580103] [<ffffffff817355f9>] schedule+0x29/0x70 [ 2461.580103] [<ffffffff81731ad1>] schedule_timeout+0x1c1/0x360 [ 2461.580103] [<ffffffff810e69eb>] ? mark_held_locks+0xbb/0x140 [ 2461.580103] [<ffffffff817377ac>] ? _raw_spin_unlock_irq+0x2c/0x50 [ 2461.580103] [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 2461.580103] [<ffffffff81736398>] wait_for_completion_killable+0xe8/0x170 [ 2461.580103] [<ffffffff810b7fa0>] ? wake_up_state+0x20/0x20 [ 2461.580103] [<ffffffff81095825>] call_usermodehelper_exec+0x1a5/0x210 [ 2461.580103] [<ffffffff817362ed>] ? wait_for_completion_killable+0x3d/0x170 [ 2461.580103] [<ffffffff81095cc3>] __request_module+0x1b3/0x370 [ 2461.580103] [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 2461.580103] [<ffffffff8162c5c9>] ctrl_getfamily+0x159/0x190 [ 2461.580103] [<ffffffff8162d8a4>] genl_family_rcv_msg+0x1f4/0x2e0 [ 2461.580103] [<ffffffff8162d990>] ? genl_family_rcv_msg+0x2e0/0x2e0 [ 2461.580103] [<ffffffff8162da1e>] genl_rcv_msg+0x8e/0xd0 [ 2461.580103] [<ffffffff8162b729>] netlink_rcv_skb+0xa9/0xc0 [ 2461.580103] [<ffffffff8162bc88>] genl_rcv+0x28/0x40 [ 2461.580103] [<ffffffff8162ad6d>] netlink_unicast+0xdd/0x190 [ 2461.580103] [<ffffffff8162b149>] netlink_sendmsg+0x329/0x750 [ 2461.580103] [<ffffffff815db849>] sock_sendmsg+0x99/0xd0 [ 2461.580103] [<ffffffff810bb58f>] ? local_clock+0x5f/0x70 [ 2461.580103] [<ffffffff810e96e8>] ? lock_release_non_nested+0x308/0x350 [ 2461.580103] [<ffffffff815dbc6e>] ___sys_sendmsg+0x39e/0x3b0 [ 2461.580103] [<ffffffff810565af>] ? kvm_clock_read+0x2f/0x50 [ 2461.580103] [<ffffffff810218b9>] ? sched_clock+0x9/0x10 [ 2461.580103] [<ffffffff810bb2bd>] ? sched_clock_local+0x1d/0x80 [ 2461.580103] [<ffffffff810bb448>] ? sched_clock_cpu+0xa8/0x100 [ 2461.580103] [<ffffffff810e33ad>] ? trace_hardirqs_off+0xd/0x10 [ 2461.580103] [<ffffffff810bb58f>] ? local_clock+0x5f/0x70 [ 2461.580103] [<ffffffff810e3f7f>] ? lock_release_holdtime.part.28+0xf/0x1a0 [ 2461.580103] [<ffffffff8120fec9>] ? fget_light+0xf9/0x510 [ 2461.580103] [<ffffffff8120fe0c>] ? fget_light+0x3c/0x510 [ 2461.580103] [<ffffffff815dd1d2>] __sys_sendmsg+0x42/0x80 [ 2461.580103] [<ffffffff815dd222>] SyS_sendmsg+0x12/0x20 [ 2461.580103] [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b [ 2461.580103] modprobe D ffff88000f2c8000 4632 603 602 0x00000080 [ 2461.580103] ffff88000f04fba8 0000000000000046 00000000001d5340 ffff88000f04ffd8 [ 2461.580103] ffff88000f04ffd8 00000000001d5340 ffff8800377d4500 ffff8800377d4500 [ 2461.580103] ffffffff81d0b260 ffffffff81d0b268 ffffffff00000000 ffffffff81d0b2b0 [ 2461.580103] Call Trace: [ 2461.580103] [<ffffffff817355f9>] schedule+0x29/0x70 [ 2461.580103] [<ffffffff81736d4d>] rwsem_down_write_failed+0xed/0x1a0 [ 2461.580103] [<ffffffff810bb200>] ? update_cpu_load_active+0x10/0xb0 [ 2461.580103] [<ffffffff8137b473>] call_rwsem_down_write_failed+0x13/0x20 [ 2461.580103] [<ffffffff8173492d>] ? down_write+0x9d/0xb2 [ 2461.580103] [<ffffffff8162baa5>] ? genl_lock_all+0x15/0x30 [ 2461.580103] [<ffffffff8162baa5>] genl_lock_all+0x15/0x30 [ 2461.580103] [<ffffffff8162cbb3>] genl_register_family+0x53/0x1f0 [ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff [ 2461.580103] [<ffffffff8162d650>] genl_register_family_with_ops+0x20/0x80 [ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff [ 2461.580103] [<ffffffffa017fe84>] nl80211_init+0x24/0xf0 [cfg80211] [ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff [ 2461.580103] [<ffffffffa01dc043>] cfg80211_init+0x43/0xdb [cfg80211] [ 2461.580103] [<ffffffff810020fa>] do_one_initcall+0xfa/0x1b0 [ 2461.580103] [<ffffffff8105cb93>] ? set_memory_nx+0x43/0x50 [ 2461.580103] [<ffffffff810f75af>] load_module+0x1c6f/0x27f0 [ 2461.580103] [<ffffffff810f2c90>] ? store_uevent+0x40/0x40 [ 2461.580103] [<ffffffff810f82c6>] SyS_finit_module+0x86/0xb0 [ 2461.580103] [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b [ 2461.580103] Sched Debug Version: v0.10, 3.11.0-0.rc1.git4.1.fc20.x86_64 #1 Problem start to happen after adding net-pf-16-proto-16-family-nl80211 alias name to cfg80211 module by below commit (though that commit itself is perfectly fine): commit fb4e1568 Author: Marcel Holtmann <marcel@holtmann.org> Date: Sun Apr 28 16:22:06 2013 -0700 nl80211: Add generic netlink module alias for cfg80211/nl80211 Reported-and-tested-by:Jeff Layton <jlayton@redhat.com> Reported-by:
Richard W.M. Jones <rjones@redhat.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Frank Li authored
If the ready bit in the transmit buffer descriptor (TxBD[R]) is previously detected as not set during a prior frame transmission, then the ENET_TDAR[TDAR] bit is cleared at a later time, even if additional TxBDs were added to the ring and the ENET_TDAR[TDAR] bit is set. This results in frames not being transmitted until there is a 0-to-1 transition on ENET_TDAR[TDAR]. Workarounds: code can use the transmit frame interrupt flag (ENET_EIR[TXF]) as a method to detect whether the ENET has completed transmission and the ENET_TDAR[TDAR] has been cleared. If ENET_TDAR[TDAR] is detected as cleared when packets are queued and waiting for transmit, then a write to the TDAR bit will restart TxBD processing. This case main happen when loading is light. A ethernet package may not send out utile next package put into tx queue. How to test: while [ true ] do ping <IP> -s 10000 -w 4 ping <IP> -s 6000 -w 2 ping <IP> -s 4000 -w 2 ping <IP> -s 10000 -w 2 done You will see below result in overnight test. 6008 bytes from 10.192.242.116: seq=1 ttl=128 time=0.722 ms 4008 bytes from 10.192.242.116: seq=0 ttl=128 time=1001.008 ms 4008 bytes from 10.192.242.116: seq=1 ttl=128 time=1.010 ms 10008 bytes from 10.192.242.116: seq=0 ttl=128 time=0.896 ms After apply this patch, >1000ms delay disappear. Signed-off-by:
Frank Li <Frank.Li@freescale.com> Acked-by:
Fugang Duan <B38611@freescale.com> Signed-off-by:
-
Manish Chopra authored
o Initialize proper interrupt handler for 83xx. Signed-off-by:
Manish Chopra <manish.chopra@qlogic.com> Signed-off-by:
Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
-
Manish Chopra authored
o When configuring guest VLAN after PVID configuration, VF was loading with previously configured PVID. Clear the PVID which was previously configured before configuring guest VLAN. o Display guest VLAN when it is configured Signed-off-by:
-
Pratik Pujar authored
Operation type and command type is not set correct in back channel response. Signed-off-by:
Pratik Pujar <pratik.pujar@qlogic.com> Signed-off-by:
-
Jitendra Kalsaria authored
Work function needs to be initialized before we participate in inter device communication (IDC). Signed-off-by:
Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by:
-
David S. Miller authored
This reverts commit ebe7fdba. This change is not correct. GFP_DMA is not necessary for this device. There is some other problem causing this bug. Signed-off-by:
-
- 26 Jul, 2013 8 commits
-
-
Neil Horman authored
atl1c uses netdev_alloc_skb to refill its rx dma ring, but that call makes no guarantees about the suitability of the memory for use in DMA. As a result we've gotten reports of atl1c drivers occasionally hanging and needing to be reset: https://bugzilla.kernel.org/show_bug.cgi?id=54021 Fix this by modifying the call to use the internal version __netdev_alloc_skb, where you can set the gfp_mask explicitly to include GFP_DMA. Tested by two reporters in the above bug, who have the hardware to validate it. Both report immediate cessation of the problem with this patch Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: Jay Cliburn <jcliburn@gmail.com> CC: "David S. Miller" <davem@davemloft.net> CC: stable@vger.kernel.org Tested-by:
Luis Henriques <luis.henriques@canonical.com> Tested-by:
Vincent Alquier <vincent.alquier@gmail.com> Signed-off-by:
-
Gavin Shan authored
The patch fixes following warning. The PCI device might have been disabled somewhere else when we have EEH errors during early stage. Device tg3 disabling already-disabled device WARNING: at drivers/pci/pci.c:1403 : NIP [c00000000044fd5c] .pci_disable_device+0xcc/0xe0 LR [c00000000044fd58] .pci_disable_device+0xc8/0xe0 Call Trace: [c000003f80bc7370] [c00000000044fd58] .pci_disable_device+0xc8/0xe0 [c000003f80bc73f0] [d00000001cfe8fc0] .tg3_init_one+0x2f0/0x19f0 [tg3] [c000003f80bc74d0] [c0000000004534e8] .local_pci_probe+0x68/0xb0 [c000003f80bc7560] [c0000000004537c8] .pci_device_probe+0x198/0x1a0 [c000003f80bc7610] [c0000000004f9e98] .driver_probe_device+0xd8/0x450 [c000003f80bc76a0] [c0000000004fa3bc] .__driver_attach+0x10c/0x110 [c000003f80bc7730] [c0000000004f6e94] .bus_for_each_dev+0x94/0x100 [c000003f80bc77d0] [c0000000004f9634] .driver_attach+0x34/0x50 [c000003f80bc7850] [c0000000004f8f98] .bus_add_driver+0x288/0x380 [c000003f80bc78f0] [c0000000004fae2c] .driver_register+0x9c/0x200 [c000003f80bc7980] [c000000000453214] .__pci_register_driver+0x64/0x90 [c000003f80bc7a10] [d00000001cff7a60] .tg3_driver_init+0x2c/0x40 [tg3] [c000003f80bc7a80] [c00000000000b424] .do_one_initcall+0x144/0x1f0 [c000003f80bc7b70] [c0000000001244a0] .load_module+0x1f30/0x2700 [c000003f80bc7d40] [c000000000124e80] .SyS_finit_module+0xc0/0x110 [c000003f80bc7e30] [c000000000009dd4] syscall_exit+0x0/0x98 Reported-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Acked-by:
Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by:
-
Gavin Shan authored
While EEH error happens, we might not have network device instance (struct net_device) yet. So we can't access the instance safely and check its link state, which causes kernel crash. The patch fixes it. EEH: Frozen PE#2 on PHB#3 detected EEH: This PCI device has failed 1 times in the last hour EEH: Notify device drivers to shutdown (NULL net_device): PCI I/O error detected Unable to handle kernel paging request for data at address 0x00000048 Faulting instruction address: 0xd00000001c9387a8 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA PowerNV : NIP [d00000001c9387a8] .tg3_io_error_detected+0x78/0x2a0 [tg3] LR [d00000001c9387a4] .tg3_io_error_detected+0x74/0x2a0 [tg3] Call Trace: [c000003f93a0f960] [d00000001c9387a4] .tg3_io_error_detected+0x74/0x2a0 [tg3] [c000003f93a0fa30] [c00000000003844c] .eeh_report_error+0xac/0x120 [c000003f93a0fac0] [c0000000000371bc] .eeh_pe_dev_traverse+0x8c/0x150 [c000003f93a0fb60] [c000000000038858] .eeh_handle_normal_event+0x128/0x3d0 [c000003f93a0fbf0] [c000000000038db8] .eeh_handle_event+0x2b8/0x2c0 [c000003f93a0fc90] [c000000000038e80] .eeh_event_handler+0xc0/0x170 [c000003f93a0fd30] [c0000000000cc000] .kthread+0xf0/0x100 [c000003f93a0fe30] [c00000000000a0dc] .ret_from_kernel_thread+0x5c/0x80 Reported-by:
-
Francesco Fusco authored
When (integer) sysctl values are expressed in ms and have to be represented internally as jiffies. The msecs_to_jiffies function returns an unsigned long, which gets assigned to the integer. This patch prevents the value to be assigned if bigger than INT_MAX, done in a similar way as in cba9f3 ("Range checking in do_proc_dointvec_(userhz_)jiffies_conv"). Signed-off-by:Francesco Fusco <ffusco@redhat.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: linux-kernel@vger.kernel.org Signed-off-by:
-
Francesco Fusco authored
Without this patch, the fields app_solicit, gc_thresh1, gc_thresh2, gc_thresh3, proxy_qlen, ucast_solicit, mcast_solicit could have assumed negative values when setting large numbers. Signed-off-by:
-
Maxime Ripard authored
The EMAC driver can't work without its associated PHY driver. Reflect this in the Kconfig options by selecting it. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Maxime Ripard authored
Signed-off-by:
-
Eric Dumazet authored
usbnet doesn't support yet SG, so drivers should not advertise SG or TSO capabilities, as they allow TCP stack to build large TSO packets that need to be linearized and might use order-5 pages. This adds an extra copy overhead and possible allocation failures. Current code ignore skb_linearize() return code so crashes are even possible. Best is to not pretend SG/TSO is supported, and add this again when/if usbnet really supports SG for devices who could get a performance gain. Based on a prior patch from Freddy Xin <freddy@asix.com.tw> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
- 25 Jul, 2013 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessDavid S. Miller authored
John W. Linville says: ==================== This is another batch of fixes intended for the 3.11 stream. FWIW, this is the first request with fixes from the mac80211 and iwlwifi trees as well. Regarding the mac80211 bits, Johannes says: "Here I have a fix for RSSI thresholds in mesh, two minstrel fixes from Felix, an nl80211 fix from Michal and four various fixes I did myself." As for the iwlwifi bits, Johannes says: "Here I have a fix for debugfs directory creation (causing a spurious error message), two scanning fixes from David Spinadel, an LED fix and two patches related to a BA session problem that eventually caused firmware crashes from Emmanuel and a small BT fix for older devices as well as a workaround for a firmware problem with APs with very small beacon intervals from myself." Along with those: Arend van Spriel addresses a lock-up and a NULL pointer dereference in brcmfmac. Daniel Drake fixes an unhandled interrupt during device tear down in mwifiex. Larry Finger corrects a wil6210 build error. Oleksij Rempel fixes two ath9k_htc problems related to keeping the driver and firmware in sync. Solomon Peachy gives us a cw1200 fix to avoid an oops in monitor mode. ==================== Signed-off-by: -
Florian Fainelli authored
build_skb() specifies that the data parameter must come from a kmalloc'd area, this is only true if frag_size equals 0, because then build_skb() will use kzsize(data) to figure out the actual data size. Update the comment to reflect that special condition. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Emilio López authored
The current timeout check is comparing two constant values, so it won't ever detect a timeout. This patch reworks the affected code a bit so it has a chance at detecting timeouts correctly. Signed-off-by:
Emilio López <emilio@elopez.com.ar> Acked-by:
-
Hannes Frederic Sowa authored
Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer which leads to a panic (from Srivatsa S. Bhat): BUG: unable to handle kernel paging request at ffff882018552020 IP: [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6] PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter +ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4 Hardware name: IBM -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012 Workqueue: netns cleanup_net task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000 RIP: 0010:[<ffffffffa0366b02>] [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6] RSP: 0018:ffff881039367bd8 EFLAGS: 00010286 RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200 RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68 RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222 R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040 R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0 Stack: ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000 ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0 ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0 Call Trace: [<ffffffffa034d9d1>] rawv6_close+0x21/0x40 [ipv6] [<ffffffff815bdecb>] inet_release+0xfb/0x220 [<ffffffff815bddf2>] ? inet_release+0x22/0x220 [<ffffffffa032686f>] inet6_release+0x3f/0x50 [ipv6] [<ffffffff8151c1d9>] sock_release+0x29/0xa0 [<ffffffff81525520>] sk_release_kernel+0x30/0x70 [<ffffffffa034f14b>] icmpv6_sk_exit+0x3b/0x80 [ipv6] [<ffffffff8152fff9>] ops_exit_list+0x39/0x60 [<ffffffff815306fb>] cleanup_net+0xfb/0x1a0 [<ffffffff81075e3a>] process_one_work+0x1da/0x610 [<ffffffff81075dc9>] ? process_one_work+0x169/0x610 [<ffffffff81076390>] worker_thread+0x120/0x3a0 [<ffffffff81076270>] ? process_one_work+0x610/0x610 [<ffffffff8107da2e>] kthread+0xee/0x100 [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70 [<ffffffff8162a99c>] ret_from_fork+0x7c/0xb0 [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70 Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65 RIP [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6] RSP <ffff881039367bd8> CR2: ffff882018552020 Reported-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Tested-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
- 24 Jul, 2013 5 commits
-
-
Jerry Snitselaar authored
With the <= max condition in the for loop, it will be always go 1 element further than needed. If the condition for the while loop is never met, then max is MAX_STAT_DEPTH, and for loop will walk off the end of nodesizes[]. Signed-off-by:
Jerry Snitselaar <jerry.snitselaar@oracle.com> Acked-by:
-
Dan Carpenter authored
We can't dereference "ent" after passing it to free_cmd(). Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Lekensteyn authored
The work queue is initialised in rtl_open (when the interface goes up), but canceled in rtl_remove_one (when the PCI device gets removed). If the network interface is not brought up, then the work queue struct is not initialised. When the device is removed, the attempt to cancel the uninitialised work queue causes a lockdep warning. This patch fixes the issue by moving cancel_work_sync to rtl_close (to match rtl_open). (Note that rtl_close is also called via unregister_netdev in rtl_remove_one.) Signed-off-by:
Peter Wu <lekensteyn@gmail.com> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
-
Fabio Estevam authored
Add MODULE_ALIAS, so that auto module loading can work. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
- 23 Jul, 2013 1 commit
-
-
Ben Hutchings authored
Received packets are only scattered if this is enabled in both the matching filter and the receiving queue. This was not being done for filters inserted for RFS, so any packet requiring more than a single descriptor was dropped. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
- 22 Jul, 2013 11 commits
-
-
Jiri Slaby authored
Since 4bb16672 (build some drivers only when compile-testing), PTP_1588_CLOCK_PCH depends on (X86 || COMPILE_TEST). But PCH_GBE selects PTP_1588_CLOCK_PCH without depending on x86. Fix this by adding the same dependency here. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by: <fengguang.wu@intel.com> [intel's build test robot] Cc: "David S. Miller" <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: netdev@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: kbuild-all@01.org Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller authored
Pablo Neira Ayuso says: ==================== The following patchset contains Netfilter fixes for your net tree, they are: * Fix potential NULL dereference in the socket match if revision 0 is used, from Eric Dumazet. * Fix missing expectation NAT initialization that results in dumping the NAT part via ctnetlink, thus leading to problems in expectation synchronization through conntrackd, from myself. ==================== Signed-off-by: -
Arend van Spriel authored
To avoid ending up in a NULL-pointer access, the function brcmf_txflowblock_if() should only be called for interfaces that have a netdev associated with it. Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
If the transmit fails because there are no hanger slots or any other reason and the packet was an EAPOL packet the pending counter should be decreased although it was not transmitted so the driver does not end up in a dead-lock. Reviewed-by:
-
Larry Finger authored
Building driver wil6210 in 3.10 and 3.11 kernels yields the following errors: CC [M] drivers/net/wireless/ath/wil6210/debugfs.o drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_print_ring': drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign] false); ^ In file included from include/linux/kernel.h:13:0, from include/linux/cache.h:4, from include/linux/time.h:4, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/net/wireless/ath/wil6210/debugfs.c:17: include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *' extern void hex_dump_to_buffer(const void *buf, size_t len, ^ drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_txdesc_debugfs_show': drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign] sizeof(printbuf), false); ^ In file included from include/linux/kernel.h:13:0, from include/linux/cache.h:4, from include/linux/time.h:4, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/net/wireless/ath/wil6210/debugfs.c:17: include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *' extern void hex_dump_to_buffer(const void *buf, size_t len, ^ cc1: all warnings being treated as errors make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1 make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2 make[3]: *** [drivers/net/wireless/ath] Error 2 make[2]: *** [drivers/net/wireless] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 These errors are fixed by changing the type of the buffer from "unsigned char *" to "char *". Reported-by:Thomas Fjellstrom <thomas@fjellstrom.ca> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.10] Cc: Thomas Fjellstrom <thomas@fjellstrom.ca> Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
-
Solomon Peachy authored
In monitor mode, priv->vif is NULL, but at one point in the receive path we blindly attempt to dereference it. Add a test to prevent this. Signed-off-by:
Solomon Peachy <pizza@shaftnet.org> Signed-off-by:
-
Oleksij Rempel authored
Currently ath9k_htc will reboot firmware only if interface was ever started. Which lead to the problem in case where interface was never started but module need to be reloaded. This patch will partially fix bug "ath9k_htc: Target is unresponsive" https://github.com/qca/open-ath9k-htc-firmware/issues/1 Reproduction case: - plug adapter - make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter. - rmmod ath9k_htc; sleep 1; modprobe ath9k_htc Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Oleksij Rempel authored
Currently we configure harwdare and clock, only after interface start. In this case, if we reload module or reboot PC without configuring adapter, firmware will freeze. There is no software way to reset adpter. This patch add initial configuration and set it in disabled state, to avoid this freeze. Behaviour of this patch should be similar to: ifconfig wlan0 up; ifconfig wlan0 down. Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1Tested-by:
Bo Shi <cnshibo@gmail.com> Signed-off-by:
-
Daniel Drake authored
During tear down (e.g. mwifiex_sdio_remove during system suspend), mwifiex left IRQs enabled for a significant period of time when it was unable to handle them correctly. This caused interrupt storms and interfered with the bluetooth interface on the same SDIO card. Solve this by disabling interrupts at the point when they can no longer be handled correctly, which is at the start of mwifiex_remove_card(). For cleanliness, we now enable interrupts in the mwifiex_add_card() path, to be symmetrical with the disabling of interrupts. We also couple the registration of the sdio IRQ handler with the actual enable/disable of interrupts at the hardware level. I also removed a write to this register in mwifiex_init_sdio which seemed pointless and won't cause any ill effects now that we only register the SDIO IRQ handler when we are ready to accept interrupts. Includes some corrections from Amitkumar Karwar. Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
-
-
