- 26 6月, 2014 8 次提交
-
-
由 Eric Dumazet 提交于
When IP route cache had been removed in linux-3.6, we broke assumption that dst entries were all freed after rcu grace period. DST_NOCACHE dst were supposed to be freed from dst_release(). But it appears we want to keep such dst around, either in UDP sockets or tunnels. In sk_dst_get() we need to make sure dst refcount is not 0 before incrementing it, or else we might end up freeing a dst twice. DST_NOCACHE set on a dst does not mean this dst can not be attached to a socket or a tunnel. Then, before actual freeing, we need to observe a rcu grace period to make sure all other cpus can catch the fact the dst is no longer usable. Signed-off-by: NEric Dumazet <edumazet@google.com> Reported-by: NDormando <dormando@rydia.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tobias Klauser 提交于
Use kcalloc/kmalloc_array to make it clear we're allocating arrays. No integer overflow can actually happen here, since len/flen is guaranteed to be less than BPF_MAXINSNS (4096). However, this changed makes sure we're not going to get one if BPF_MAXINSNS were ever increased. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Acked-by: NDaniel Borkmann <dborkman@redhat.com> Acked-by: NAlexei Starovoitov <ast@plumgrid.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tobias Klauser 提交于
Change the order of the parameters to sk_unattached_filter_create() in the kerneldoc to reflect the order they appear in the actual function. This fix is only cosmetic, in the generated doc they still appear in the correct order without the fix. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Acked-by: NDaniel Borkmann <dborkman@redhat.com> Acked-by: NAlexei Starovoitov <ast@plumgrid.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Tobias Klauser 提交于
Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Acked-by: NDaniel Borkmann <dborkman@redhat.com> Acked-by: NAlexei Starovoitov <ast@plumgrid.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Maxime Ripard 提交于
If the mdio probe function fails in emac_open, the interrupt we just requested isn't freed. If emac_open is called again, for example because we try to set up the interface again, the kernel will oops because the interrupt wasn't properly released. Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Cc: <stable@vger.kernel.org> # 3.11+ Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
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: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Liu 提交于
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: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: NWei Liu <wei.liu2@citrix.com> CC: Ian Campbell <ian.campbell@citrix.com> CC: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Prashant Sreedharan 提交于
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: NPrashant Sreedharan <prashant@broadcom.com> Signed-off-by: NMichael Chan <mchan@broadcom.com> Suggested-by: NDavid Miller <davem@davemloft.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 6月, 2014 1 次提交
-
-
由 Li RongQing 提交于
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: NBen Greear <greearb@candelatech.com> Cc: Casey Leedom <leedom@chelsio.com> Cc: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: NLi RongQing <roy.qing.li@gmail.com> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Acked-by: NCasey Leedom <leedom@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 6月, 2014 1 次提交
-
-
由 Suresh Reddy 提交于
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: NSuresh Reddy <Suresh.Reddy@emulex.com> Signed-off-by: NSathya Perla <sathya.perla@emulex.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 23 6月, 2014 5 次提交
-
-
由 Richard Retanubun 提交于
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: NRichard Retanubun <rretanubun.work@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Phoebe Buckheister 提交于
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: NPhoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Fengguang Wu 提交于
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: NFengguang Wu <fengguang.wu@intel.com> Acked-by: NDaniel Mack <zonque@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Or Gerlitz 提交于
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: NShirley Ma <shirley.ma@oracle.com> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ondrej Zary 提交于
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: NOndrej Zary <linux@rainbow-software.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 6月, 2014 10 次提交
-
-
由 Bjørn Mork 提交于
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: NDan Williams <dcbw@redhat.com> Signed-off-by: NBjørn Mork <bjorn@mork.no> Acked-By: NEnrico Mioso <mrkiko.rs@gmail.com> Tested-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mugunthan V N 提交于
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: NMugunthan V N <mugunthanvnm@ti.com> Tested-by: NYegor Yefremov <yegorslists@googlemail.com> Tested-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net>
-
由 David Vrabel 提交于
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: NDavid Vrabel <david.vrabel@citrix.com> Reviewed-by: NWei Liu <wei.liu2@citrix.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Vrabel 提交于
xennet_disconnect_backend() was not correctly iterating over all the queues. Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Reviewed-by: NWei Liu <wei.liu2@citrix.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Mack 提交于
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: NDaniel Mack <zonque@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Mack 提交于
This removes magic values from two tables and also allows us to match against specific PHY models at runtime. Signed-off-by: NDaniel Mack <zonque@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Mack 提交于
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: NDaniel Mack <zonque@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Li RongQing 提交于
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: NLi RongQing <roy.qing.li@gmail.com> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 6月, 2014 5 次提交
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Borkmann 提交于
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: NFlorian Westphal <fwestpha@redhat.com> Signed-off-by: NDaniel Borkmann <dborkman@redhat.com> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NVlad Yasevich <vyasevich@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Prashant Sreedharan 提交于
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: NPrashant Sreedharan <prashant@broadcom.com> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neal Cardwell 提交于
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: NEric Dumazet <edumazet@google.com> Signed-off-by: NNeal 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: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
This reverts commit d36a4f4b. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 6月, 2014 7 次提交
-
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # v3.15+ Acked-by: NDaniel Borkmann <dborkman@redhat.com> Acked-by: NAlexei Starovoitov <ast@plumgrid.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Borkmann 提交于
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: NDaniel Borkmann <dborkman@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jie Liu 提交于
Return the actual error code if call kset_create_and_add() failed Cc: David S. Miller <davem@davemloft.net> Signed-off-by: NJie Liu <jeff.liu@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Or Gerlitz 提交于
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: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mirko Lindner 提交于
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: NMirko Lindner <mlindner@marvell.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net>
-
由 John W. Linville 提交于
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
-
- 18 6月, 2014 3 次提交
-
-
由 Pablo Neira Ayuso 提交于
Moreover, remove reference to the netfilter users mailing list, so they don't receive patches. Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
-
由 Fugang Duan 提交于
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: NRussell King <linux@arm.linux.org.uk> Signed-off-by: NFugang Duan <B38611@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jean Delvare 提交于
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: NJean Delvare <jdelvare@suse.de> Cc: Richard Cochran <richardcochran@gmail.com> Acked-by: NRichard Cochran <richardcochran@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-