- 25 Jun, 2014 3 commits
-
-
Thadeu Lima de Souza Cascardo authored
Commit 3f85944f ("net: Add sysfs file for port number") introduce dev_port to network devices. cxgb4 adapters have multiple ports on the same PCI function, and used dev_id to identify those ports. That use was removed by commit 8c367fcb ("cxgb4: Do not set net_device::dev_id to VI index"), since dev_id should be used only when devices share the same MAC address. Using dev_port for cxgb4 allows different ports on the same PCI function to be identified. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wei Liu authored
The original code uses netdev->real_num_tx_queues to bookkeep number of queues and invokes netif_set_real_num_tx_queues to set the number of queues. However, netif_set_real_num_tx_queues doesn't allow real_num_tx_queues to be smaller than 1, which means setting the number to 0 will not work and real_num_tx_queues is untouched. This is bogus when xenvif_free is invoked before any number of queues is allocated. That function needs to iterate through all queues to free resources. Using the wrong number of queues results in NULL pointer dereference. So we bookkeep the number of queues in xen-netback to solve this problem. This fixes a regression introduced by multiqueue patchset in 3.16-rc1. There's another bug in original code that the real number of RX queues is never set. In current Xen multiqueue design, the number of TX queues and RX queues are in fact the same. We need to set the numbers of TX and RX queues to the same value. Also remove xenvif_select_queue and leave queue selection to core driver, as suggested by David Miller. Reported-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
Wei Liu <wei.liu2@citrix.com> CC: Ian Campbell <ian.campbell@citrix.com> CC: Paul Durrant <paul.durrant@citrix.com> Signed-off-by:
-
Prashant Sreedharan authored
Commit 506724c4 "tg3: Override clock, link aware and link idle mode during NVRAM dump" changed the timeout value for nvram command execution from 100ms to 1ms. But the 1ms timeout value was only sufficient for nvram read operations but not write operations for most of the devices supported by tg3 driver. This patch sets the MAX to 50ms. Also it uses usleep_range instead of udelay. Signed-off-by:
Prashant Sreedharan <prashant@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Suggested-by:
-
- 24 Jun, 2014 1 commit
-
-
Li RongQing authored
cxgb4_netdev maybe lead to dead lock, since it uses a spin lock, and be called in both thread and softirq context, but not disable BH, the lockdep report is below; In fact, cxgb4_netdev only reads adap_rcu_list with RCU protection, so not need to hold spin lock again. ================================= [ INFO: inconsistent lock state ] 3.14.7+ #24 Tainted: G C O --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. radvd/3794 [HC0[0]:SC1[1]:HE1:SE0] takes: (adap_rcu_lock){+.?...}, at: [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4] {SOFTIRQ-ON-W} state was registered at: [<ffffffff810fca81>] __lock_acquire+0x34a/0xe48 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43 [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4] [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4] [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6] [<ffffffffa01f8df0>] addrconf_add_linklocal+0x5f/0x95 [ipv6] [<ffffffffa01fc3e9>] addrconf_notify+0x632/0x841 [ipv6] [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c [<ffffffff810e09a1>] __raw_notifier_call_chain+0x9/0xb [<ffffffff810e09b2>] raw_notifier_call_chain+0xf/0x11 [<ffffffff8151b3b7>] call_netdevice_notifiers_info+0x4e/0x56 [<ffffffff8151b3d0>] call_netdevice_notifiers+0x11/0x13 [<ffffffff8151c0a6>] netdev_state_change+0x1f/0x38 [<ffffffff8152f004>] linkwatch_do_dev+0x3b/0x49 [<ffffffff8152f184>] __linkwatch_run_queue+0x10b/0x144 [<ffffffff8152f1dd>] linkwatch_event+0x20/0x27 [<ffffffff810d7bc0>] process_one_work+0x1cb/0x2ee [<ffffffff810d7e3b>] worker_thread+0x12e/0x1fc [<ffffffff810dd391>] kthread+0xc4/0xcc [<ffffffff815dc48c>] ret_from_fork+0x7c/0xb0 irq event stamp: 3388 hardirqs last enabled at (3388): [<ffffffff810c6c85>] __local_bh_enable_ip+0xaa/0xd9 hardirqs last disabled at (3387): [<ffffffff810c6c2d>] __local_bh_enable_ip+0x52/0xd9 softirqs last enabled at (3288): [<ffffffffa01f1d5b>] rcu_read_unlock_bh+0x0/0x2f [ipv6] softirqs last disabled at (3289): [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(adap_rcu_lock); <Interrupt> lock(adap_rcu_lock); *** DEADLOCK *** 5 locks held by radvd/3794: #0: (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffffa020b85a>] rawv6_sendmsg+0x74b/0xa4d [ipv6] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff8151ac6b>] rcu_lock_acquire+0x0/0x29 #2: (rcu_read_lock){.+.+..}, at: [<ffffffffa01f4cca>] rcu_lock_acquire.constprop.16+0x0/0x30 [ipv6] #3: (rcu_read_lock){.+.+..}, at: [<ffffffff810e09b4>] rcu_lock_acquire+0x0/0x29 #4: (rcu_read_lock){.+.+..}, at: [<ffffffffa0998782>] rcu_lock_acquire.constprop.40+0x0/0x30 [cxgb4] stack backtrace: CPU: 7 PID: 3794 Comm: radvd Tainted: G C O 3.14.7+ #24 Hardware name: Supermicro X7DBU/X7DBU, BIOS 6.00 12/03/2007 ffffffff81f15990 ffff88012fdc36a8 ffffffff815d0016 0000000000000006 ffff8800c80dc2a0 ffff88012fdc3708 ffffffff815cc727 0000000000000001 0000000000000001 ffff880100000000 ffffffff81015b02 ffff8800c80dcb58 Call Trace: <IRQ> [<ffffffff815d0016>] dump_stack+0x4e/0x71 [<ffffffff815cc727>] print_usage_bug+0x1ec/0x1fd [<ffffffff81015b02>] ? save_stack_trace+0x27/0x44 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0 [<ffffffff810fc640>] mark_lock+0x11b/0x212 [<ffffffff810fca0b>] __lock_acquire+0x2d4/0xe48 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0 [<ffffffff810fbff6>] ? check_usage_forwards+0x4c/0xa6 [<ffffffff810c6c8a>] ? __local_bh_enable_ip+0xaf/0xd9 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4] [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4] [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4] [<ffffffffa09987b0>] ? rcu_lock_acquire.constprop.40+0x2e/0x30 [cxgb4] [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4] [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4] [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4] [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d [<ffffffff810e09b4>] ? raw_notifier_call_chain+0x11/0x11 [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6] [<ffffffff810fde6a>] ? trace_hardirqs_on+0xd/0xf [<ffffffffa01fb634>] addrconf_prefix_rcv+0x385/0x6ea [ipv6] [<ffffffffa0207950>] ndisc_rcv+0x9d3/0xd76 [ipv6] [<ffffffffa020d536>] icmpv6_rcv+0x592/0x67b [ipv6] [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b [<ffffffffa020df97>] ? rcu_read_unlock+0x21/0x23 [ipv6] [<ffffffff8150df52>] ? rcu_read_unlock+0x23/0x23 [<ffffffffa01f4ede>] ip6_input_finish+0x1e4/0x2fc [ipv6] [<ffffffffa01f540b>] ip6_input+0x33/0x38 [ipv6] [<ffffffffa01f5557>] ip6_mc_input+0x147/0x160 [ipv6] [<ffffffffa01f4ba3>] ip6_rcv_finish+0x7c/0x81 [ipv6] [<ffffffffa01f5397>] ipv6_rcv+0x3a1/0x3e2 [ipv6] [<ffffffff8151ef96>] __netif_receive_skb_core+0x4ab/0x511 [<ffffffff810fdc94>] ? mark_held_locks+0x71/0x99 [<ffffffff8151f0c0>] ? process_backlog+0x69/0x15e [<ffffffff8151f045>] __netif_receive_skb+0x49/0x5b [<ffffffff8151f0cf>] process_backlog+0x78/0x15e [<ffffffff8151f571>] ? net_rx_action+0x1a2/0x1cc [<ffffffff8151f47b>] net_rx_action+0xac/0x1cc [<ffffffff810c69b7>] ? __do_softirq+0xad/0x218 [<ffffffff810c69ff>] __do_softirq+0xf5/0x218 [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30 <EOI> [<ffffffff810c6bb6>] do_softirq+0x38/0x5d [<ffffffffa01f1d5b>] ? ip6_copy_metadata+0x156/0x156 [ipv6] [<ffffffff810c6c78>] __local_bh_enable_ip+0x9d/0xd9 [<ffffffffa01f1d88>] rcu_read_unlock_bh+0x2d/0x2f [ipv6] [<ffffffffa01f28b4>] ip6_finish_output2+0x381/0x3d8 [ipv6] [<ffffffffa01f49ef>] ip6_finish_output+0x6e/0x73 [ipv6] [<ffffffffa01f4a70>] ip6_output+0x7c/0xa8 [ipv6] [<ffffffff815b1bfa>] dst_output+0x18/0x1c [<ffffffff815b1c9e>] ip6_local_out+0x1c/0x21 [<ffffffffa01f2489>] ip6_push_pending_frames+0x37d/0x427 [ipv6] [<ffffffff81558af8>] ? skb_orphan+0x39/0x39 [<ffffffffa020b85a>] ? rawv6_sendmsg+0x74b/0xa4d [ipv6] [<ffffffffa020ba51>] rawv6_sendmsg+0x942/0xa4d [ipv6] [<ffffffff81584cd2>] inet_sendmsg+0x3d/0x66 [<ffffffff81508930>] __sock_sendmsg_nosec+0x25/0x27 [<ffffffff8150b0d7>] sock_sendmsg+0x5a/0x7b [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b [<ffffffff8116d756>] ? might_fault+0x9e/0xa5 [<ffffffff8116d70d>] ? might_fault+0x55/0xa5 [<ffffffff81508cb1>] ? copy_from_user+0x2a/0x2c [<ffffffff8150b70c>] ___sys_sendmsg+0x226/0x2d9 [<ffffffff810fcd25>] ? __lock_acquire+0x5ee/0xe48 [<ffffffff810fde01>] ? trace_hardirqs_on_caller+0x145/0x1a1 [<ffffffff8118efcb>] ? slab_free_hook.isra.71+0x50/0x59 [<ffffffff8115c81f>] ? release_pages+0xbc/0x181 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d [<ffffffff81115e97>] ? read_seqcount_begin.constprop.25+0x73/0x90 [<ffffffff8150c408>] __sys_sendmsg+0x3d/0x5b [<ffffffff8150c433>] SyS_sendmsg+0xd/0x19 [<ffffffff815dc53d>] system_call_fastpath+0x1a/0x1f Reported-by:Ben Greear <greearb@candelatech.com> Cc: Casey Leedom <leedom@chelsio.com> Cc: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
Li RongQing <roy.qing.li@gmail.com> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Casey Leedom <leedom@chelsio.com> Signed-off-by:
-
- 23 Jun, 2014 6 commits
-
-
Suresh Reddy authored
The driver (on PF or VF) needs to detect if the function is in qnq mode for a HW hack in be_rx_compl_get() to work. The driver queries this information using the GET_PROFILE_CONFIG cmd (since the commit below can caused this regression.) But this cmd is not available on VFs and so the VFs fail to detect qnq mode. This causes vlan traffic to not work. The fix is to use the the adapter->function_mode value queried via QUERY_FIRMWARE_CONFIG cmd on both PFs and VFs to detect the qnq mode. Also QNQ_MODE was incorrectly named FLEX10_MODE; correcting that too as the fix reads much better with the name change. Fixes: f93f160b ("refactor multi-channel config code for Skyhawk-R chip") Signed-off-by:
Suresh Reddy <Suresh.Reddy@emulex.com> Signed-off-by:
Sathya Perla <sathya.perla@emulex.com> Signed-off-by:
-
Richard Retanubun authored
Fixes commit 3be2a49e ("of: provide a binding for fixed link PHYs") Fix the parsing of the new fixed link dts bindings for duplex, pause, and asym_pause by using the correct device node pointer. Signed-off-by:
Richard Retanubun <rretanubun.work@gmail.com> Signed-off-by:
-
Phoebe Buckheister authored
Commit 8eba0eef ("at86rf230: remove irq_type in request_irq") removed the trigger configuration when requesting an irq, and instead relied on the interrupt trigger to be properly configured already. This does not seem to be an assumption that can be safely made, since boards disable all interrupt triggers on boot. On these boards, force the irq to trigger on rising edge, which is also the default for the chip. Signed-off-by:
Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by:
-
Fengguang Wu authored
drivers/net/phy/at803x.c:196:26-32: ERROR: application of sizeof to pointer sizeof when applied to a pointer typed expression gives the size of the pointer Generated by: scripts/coccinelle/misc/noderef.cocci Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Acked-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
Or Gerlitz authored
Single ported VF are currently not supported on configurations where one or both ports are IB. When we hit this case, the relevant flow in the driver didn't return error and jumped to the wrong label. Fix that. Fixes: dd41cc3b ('net/mlx4: Adapt num_vfs/probed_vf params for single port VF') Reported-by:
Shirley Ma <shirley.ma@oracle.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Ondrej Zary authored
It now takes up to 60 seconds to detect cable (un)plug on ADMtek Comet chips. That's too slow and might cause people to think that it doesn't work at all. Poll link status every 2 seconds instead of 60 for ADMtek Comet chips. That should be fast enough while not stressing the system too much. Tested with ADMtek AN983B. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
- 22 Jun, 2014 2 commits
-
-
Bjørn Mork authored
Messages from the modem exceeding 256 bytes cause communication failure. The WDM protocol is strictly "read on demand", meaning that we only poll for unread data after receiving a notification from the modem. Since we have no way to know how much data the modem has to send, we must make sure that the buffer we provide is "big enough". Message truncation does not work. Truncated messages are left unread until the modem has another message to send. Which often won't happen until the userspace application has given up waiting for the final part of the last message, and therefore sends another command. With a proper CDC WDM function there is a descriptor telling us which buffer size the modem uses. But with this vendor specific implementation there is no known way to calculate the exact "big enough" number. It is an unknown property of the modem firmware. Experience has shown that 256 is too small. The discussion of this failure ended up concluding that 512 might be too small as well. So 1024 seems like a reasonable value for now. Fixes: 41c47d8c ("net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver") Cc: Enrico Mioso <mrkiko.rs@gmail.com> Reported-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-By:
Enrico Mioso <mrkiko.rs@gmail.com> Tested-by:
-
Mugunthan V N authored
In commit 629c9a8f (drivers: net: cpsw: Add default vlan for dual emac case also), api cpsw_add_default_vlan() also changes the port vlan which is required to seperate the ports which results in the following behavior In Dual EMAC mode, when both the Etnernet connected is connected to same switch, it creates a loop in the switch and when a broadcast packet is received it is forwarded to the other port which stalls the whole switch and needs a reset/power cycle to the switch to recover. So intead of using the api, add only the default VLAN entry in dual EMAC case. Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Tested-by:
Yegor Yefremov <yegorslists@googlemail.com> Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
- 21 Jun, 2014 8 commits
-
-
David S. Miller authored
David Vrabel says: ==================== xen-netfront: fix resume regressions in 3.16-rc1 The introduction of multi-queue support to xen-netfront in 3.16-rc1, broke resume/migration. ==================== Signed-off-by: -
David Vrabel authored
When reconnecting to the backend (after a resume/migration, for example), a different number of queues may be required (since the guest may have moved to a different host with different capabilities). During the reconnection the old queues are torn down and new ones created. Introduce xennet_create_queues() and xennet_destroy_queues() that fixes three bugs during the reconnection. - The old info->queues was leaked. - The old queue's napi instances were not deleted. - The new queue's napi instances were left disabled (which meant no packets could be received). The xennet_destroy_queues() calls is deferred until the reconnection instead of the disconnection (in xennet_disconnect_backend()) because napi_disable() might sleep. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Reviewed-by:
-
David Vrabel authored
xennet_disconnect_backend() was not correctly iterating over all the queues. Signed-off-by:
-
David S. Miller authored
Daniel Mack says: ==================== Handle stuck TX queue bug in AT8030 PHY These three small patches circument a hardware bug in AT8030 PHYs that leads to stuck TX FIFO queues when the link goes away while there are pending patches in der outbound queue. This bug has been confirmed by the vendor, and their only proposed fix is to apply a hardware reset every time the link goes down. v1 -> v2: * Rename phy device callback from adjust_state to link_change_notify ==================== Signed-off-by: -
Daniel Mack authored
The AT8030 will enter a FIFO error mode if a packet is transmitted while the cable is unplugged. This hardware issue is acknowledged by the vendor, and the only proposed solution is to conduct a hardware reset via the external pin each time the link goes down. There is apparantly no way to fix up the state via the register set. This patch adds support for reading a 'reset-gpios' property from the DT node of the PHY. If present, this gpio is used to apply a hardware reset each time a 'link down' condition is detected. All relevant registers are read out before, and written back after the reset cycle. Doing this every time the link goes down might seem like overkill, but there is unfortunately no way of figuring out whether the PHY is in such a lock-up state. Hence, this is the only way of reliably fixing up things. Signed-off-by:
-
Daniel Mack authored
This removes magic values from two tables and also allows us to match against specific PHY models at runtime. Signed-off-by:
-
Daniel Mack authored
Add a notify callback to inform phy drivers when the core is about to do its link adjustment. No change for drivers that do not implement this callback. Signed-off-by:
-
Li RongQing authored
skb_cow called in vlan_reorder_header does not free the skb when it failed, and vlan_reorder_header returns NULL to reset original skb when it is called in vlan_untag, lead to a memory leak. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
- 20 Jun, 2014 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessDavid S. Miller authored
John W. Linville says: ==================== pull request: wireless 2014-06-18 Please pull this batch of fixes intended for the 3.16 stream! For the Bluetooth bits, Gustavo says: "This is our first batch of fixes for 3.16. Be aware that two patches here are not exactly bugfixes: * 71f28af57066 Bluetooth: Add clarifying comment for conn->auth_type This commit just add some important security comments to the code, we found it important enough to include it here for 3.16 since it is security related. * 9f7ec8871132 Bluetooth: Refactor discovery stopping into its own function This commit is just a refactor in a preparation for a fix in the next commit (f8680f12). All the other patches are fixes for deadlocks and for the Bluetooth protocols, most of them related to authentication and encryption." On top of that... Chin-Ran Lo fixes a problems with overlapping DMA areas in mwifiex. Michael Braun corrects a couple of issues in order to enable a new device in rt2800usb. Rafał Miłecki reverts a b43 patch that caused a regression, fixes a Kconfig typo, and corrects a frequency reporting error with the G-PHY. Stanislaw Grsuzka fixes an rfkill regression for rt2500pci, and avoids a rt2x00 scheduling while atomic BUG. Please let me know if there are problems! ==================== Signed-off-by:
-
Daniel Borkmann authored
When writing to the sysctl field net.sctp.auth_enable, it can well be that the user buffer we handed over to proc_dointvec() via proc_sctp_do_auth() handler contains something other than integers. In that case, we would set an uninitialized 4-byte value from the stack to net->sctp.auth_enable that can be leaked back when reading the sysctl variable, and it can unintentionally turn auth_enable on/off based on the stack content since auth_enable is interpreted as a boolean. Fix it up by making sure proc_dointvec() returned sucessfully. Fixes: b14878cc ("net: sctp: cache auth_enable per endpoint") Reported-by:
Florian Westphal <fwestpha@redhat.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Prashant Sreedharan authored
Commit d3f6f3a1 ("tg3: Prevent page allocation failure during TSO workaround") modified driver logic to use tg3_tso_bug() for any TSO fragment that hits hardware bug conditions thus the patch increased the scope of work for tg3_tso_bug() to cover devices that support NETIF_F_TSO6 as well. Prior to the patch, tg3_tso_bug() would only be used on devices supporting NETIF_F_TSO. A regression was introduced for IPv6 packets requiring the workaround. To properly perform GSO on SKBs with TCPV6 gso_type, we need to call skb_gso_segment() with NETIF_F_TSO6 feature flag cleared, or the function will return NULL and cause a kernel oops as tg3 is not handling a NULL return value. This patch fixes the problem. Signed-off-by:
-
Neal Cardwell authored
If there is an MSS change (or misbehaving receiver) that causes a SACK to arrive that covers the end of an skb but is less than one MSS, then tcp_match_skb_to_sack() was rounding up pkt_len to the full length of the skb ("Round if necessary..."), then chopping all bytes off the skb and creating a zero-byte skb in the write queue. This was visible now because the recently simplified TLP logic in bef1909e ("tcp: fixing TLP's FIN recovery") could find that 0-byte skb at the end of the write queue, and now that we do not check that skb's length we could send it as a TLP probe. Consider the following example scenario: mss: 1000 skb: seq: 0 end_seq: 4000 len: 4000 SACK: start_seq: 3999 end_seq: 4000 The tcp_match_skb_to_sack() code will compute: in_sack = false pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999 new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000 new_len += mss = 4000 Previously we would find the new_len > skb->len check failing, so we would fall through and set pkt_len = new_len = 4000 and chop off pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment afterward in the write queue. With this new commit, we notice that the new new_len >= skb->len check succeeds, so that we return without trying to fragment. Fixes: adb92db8 ("tcp: Make SACK code to split only at mss boundaries") Reported-by:Neal Cardwell <ncardwell@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Ilpo Jarvinen <ilpo.jarvinen@helsinki.fi> Acked-by:
-
David S. Miller authored
This reverts commit d36a4f4b. Signed-off-by:
-
- 19 Jun, 2014 2 commits
-
-
Kees Cook authored
The original checks (via sk_chk_filter) for instruction count uses ">", not ">=", so changing this in sk_convert_filter has the potential to break existing seccomp filters that used exactly BPF_MAXINSNS many instructions. Fixes: bd4cf0ed ("net: filter: rework/optimize internal BPF interpreter's instruction set") Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # v3.15+ Acked-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
Daniel Borkmann authored
sysctl handler proc_sctp_do_hmac_alg(), proc_sctp_do_rto_min() and proc_sctp_do_rto_max() do not properly reflect some error cases when writing values via sysctl from internal proc functions such as proc_dointvec() and proc_dostring(). In all these cases we pass the test for write != 0 and partially do additional work just to notice that additional sanity checks fail and we return with hard-coded -EINVAL while proc_do* functions might also return different errors. So fix this up by simply testing a successful return of proc_do* right after calling it. This also allows to propagate its return value onwards to the user. While touching this, also fix up some minor style issues. Fixes: 4f3fdf3b ("sctp: add check rto_min and rto_max in sysctl") Fixes: 3c68198e ("sctp: Make hmac algorithm selection for cookie generation dynamic") Signed-off-by:
-
- 18 Jun, 2014 7 commits
-
-
Jie Liu authored
Return the actual error code if call kset_create_and_add() failed Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
Jie Liu <jeff.liu@oracle.com> Signed-off-by:
-
Or Gerlitz authored
When the underlying device supports TCP offloads for VXLAN/UDP encapulated traffic, we need to reflect that through the hw_enc_features field of the bonding net-device. This will cause the xmit path in the core networking stack to provide bonding with encapsulated GSO frames to offload into the HW etc. Signed-off-by:
-
Mirko Lindner authored
Added FUJITSU SIEMENS A8NE-FM to the list of 32bit DMA boards >From Tomi O.: After I added an entry to this MB into the skge.c driver in order to enable the mentioned 64bit dma disable quirk, the network data corruptions ended and everything is fine again. Signed-off-by:
Mirko Lindner <mlindner@marvell.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller authored
Pablo Neira Ayuso says: ==================== netfilter fixes for net The following patchset contains netfilter updates for your net tree, they are: 1) Fix refcount leak when dumping the dying/unconfirmed conntrack lists, from Florian Westphal. 2) Fix crash in NAT when removing a netnamespace, also from Florian. 3) Fix a crash in IPVS when trying to remove an estimator out of the sysctl scope, from Julian Anastasov. 4) Add zone attribute to the routing to calculate the message size in ctnetlink events, from Ken-ichirou MATSUZAWA. 5) Another fix for the dying/unconfirmed list which was preventing to dump more than one memory page of entries (~17 entries in x86_64). 6) Fix missing RCU-safe list insertion in the rule replacement code in nf_tables. 7) Since the new transaction infrastructure is in place, we have to upgrade the chain use counter from u16 to u32 to avoid overflow after more than 2^16 rules are added. 8) Fix refcount leak when replacing rule in nf_tables. This problem was also introduced in new transaction. 9) Call the ->destroy() callback when releasing nft-xt rules to fix module refcount leaks. 10) Set the family in the netlink messages that contain set elements in nf_tables to make it consistent with other object types. 11) Don't dump NAT port information if it is unset in nft_nat. 12) Update the MAINTAINERS file, I have merged the ebtables entry into netfilter. While at it, also removed the netfilter users mailing list, the development list should be enough. ==================== 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
-
Pablo Neira Ayuso authored
Moreover, remove reference to the netfilter users mailing list, so they don't receive patches. Signed-off-by:Pablo Neira Ayuso <pablo@netfilter.org>
-
Fugang Duan authored
The commit 96c50caa (net: fec: Enable IP header hardware checksum) enable HW IP header checksum for IPV4 and IPV6, which causes IPV6 TCP/UDP cannot work. (The issue is reported by Russell King) For FEC IP header checksum function: Insert IP header checksum. This "IINS" bit is written by the user. If set, IP accelerator calculates the IP header checksum and overwrites the IINS corresponding header field with the calculated value. The checksum field must be cleared by user, otherwise the checksum always is 0xFFFF. So the previous patch clear IP header checksum field regardless of IP frame type. In fact, IP HW detect the packet as IPV6 type, even if the "IINS" bit is set, the IP accelerator is not triggered to calculates IPV6 header checksum because IPV6 frame format don't have checksum. So this results in the IPV6 frame being corrupted. The patch just add software detect the current packet type, if it is IPV6 frame, it don't clear IP header checksum field. Cc: Russell King <linux@arm.linux.org.uk> Reported-and-tested-by:
Russell King <linux@arm.linux.org.uk> Signed-off-by:
Fugang Duan <B38611@freescale.com> Signed-off-by:
-
- 17 Jun, 2014 6 commits
-
-
Jean Delvare authored
The ptp_pch driver is for a companion chip to the Intel Atom E600 series processors. These are 32-bit x86 processors so the driver is only needed on X86_32. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Richard Cochran <richardcochran@gmail.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5f, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5f ("rt2x00: Fix rfkill_polling register function.") Cc: stable@vger.kernel.org Bisected-by:
Niels <nille0386@googlemail.com> Reported-and-tested-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Support for firmware rev 508+ was added years ago, but we never noticed it reports channel in a different way for G-PHY devices. Instead of offset from 2400 MHz it simply passes channel id (AKA hw_value). So far it was (most probably) affecting monitor mode users only, but the following recent commit made it noticeable for quite everybody: commit 3afc2167 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Tue Mar 4 16:50:13 2014 +0200 cfg80211/mac80211: ignore signal if the frame was heard on wrong channel Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Cc: stable@vger.kernel.org Tested-by:
-
Michael Braun authored
The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) boots into a state that does not actually require loading a firmware file. The vendors driver finds out about this by checking a firmware state register, so this patch adds this here. Finally, with this patch applied, my wifi dongle actually becomes useful (scan + connect to wpa network works). Signed-off-by:
Michael Braun <michael-dev@fami-braun.de> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Michael Braun authored
The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) currently does not load. One thing observed is that the vendors driver detects EFUSE mode for this device, but rt2800usb does not. This is due to rt2800usb lacking a check for the firmware mode present in the vendors driver, that this patch adopts for rt2800usb. With this patch applied, the 'RF chipset' detection does no longer fail. Signed-off-by:
-
-
