- 18 Nov, 2013 1 commit
-
-
Ma JieYue authored
There was a bug in xennet_alloc_rx_buffers, when allocating page or sk_buff failed, and at the same time rx_batch queue not empty, the rx_refill_timer timer won't be scheduled. If finally the remaining request buffers in rx ring less than what backend driver expected, the backend driver would think of rx ring as full and start dropping packets. In such situation, there is no way for the netfront driver to recover automatically, so that the device can not work properly. The patch fixes the problem by always scheduling rx_refill_timer timer when alloc_page or __netdev_alloc_skb fails, no matter whether rx_batch queue is empty or not. It ensures that the rx ring request buffers will finally meet the backend needs. Signed-off-by:
Ma JieYue <jieyue.majy@alibaba-inc.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 16 Nov, 2013 5 commits
-
-
David S. Miller authored
Currently pskb_trim_rcsum() just balks on CHECKSUM_COMPLETE packets and remarks them as CHECKSUM_NONE, forcing a software checksum validation later. We have all of the mechanics available to fixup the skb->csum value, even for complicated fragmented packets, via the helpers skb_checksum() and csum_sub(). So just use them. Based upon a suggestion by Herbert Xu. Signed-off-by: -
Eric Dumazet authored
For performance reasons, sch_fq tried hard to not setup timers for every sent packet, using a quantum based heuristic : A delay is setup only if the flow exhausted its credit. Problem is that application limited flows can refill their credit for every queued packet, and they can evade pacing. This problem can also be triggered when TCP flows use small MSS values, as TSO auto sizing builds packets that are smaller than the default fq quantum (3028 bytes) This patch adds a 40 ms delay to guard flow credit refill. Fixes: afe4fd06 ("pkt_sched: fq: Fair Queue packet scheduler") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Eric Dumazet authored
Commit 7eec4174 ("pkt_sched: fq: fix non TCP flows pacing") obsoleted TCA_FQ_FLOW_DEFAULT_RATE without notice for the users. Suggested by David Miller Signed-off-by:
-
Johannes Berg authored
Now that the ops assignment is just two variables rather than a long list iteration etc., there's no reason to separately export __genl_register_family() and __genl_register_family_with_ops(). Unify the two functions into __genl_register_family() and make genl_register_family_with_ops() call it after assigning the ops. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Petko Manolov authored
The diff is against latest 'net' repository; Signed-off-by:
Petko Manolov <petkan@nucleusys.com> Signed-off-by:
-
- 15 Nov, 2013 7 commits
-
-
Daniel Mack authored
During resume, use for_each_slave to walk the slaves of the cpsw, and soft-reset each of them. This prevents oopses if there is only one slave configured. Signed-off-by:
Daniel Mack <zonque@gmail.com> Acked-by:
Mugunthan V N <mugunthanvnm@gmail.com> Signed-off-by:
-
David S. Miller authored
Michal Kubecek says: ==================== macvlan: disable LRO on lowerdev instead of a macvlan A customer of ours encountered a problem with LRO on an ixgbe network card. Analysis showed that it was a known conflict of forwarding and LRO but the forwarding was enabled in an LXC container where only a macvlan was, not the ethernet device itself. I believe the solution is exactly the same as what we do for "normal" (802.1q) VLAN devices: if dev_disable_lro() is called for such device, LRO is disabled on the underlying "real" device instead. v2: adapt to changes merged from net-next v3: use BUG() in macvlan_dev_real_dev() if compiled without macvlan ==================== Signed-off-by: -
Michal Kubeček authored
A macvlan device has always LRO disabled so that calling dev_disable_lro() on it does nothing. If we need to disable LRO e.g. because - the macvlan device is inserted into a bridge - IPv6 forwarding is enabled for it - it is in a different namespace than lowerdev and IPv4 forwarding is enabled in it we need to disable LRO on its underlying device instead (as we do for 802.1q VLAN devices). v2: use newly introduced netif_is_macvlan() Signed-off-by:Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Michal Kubeček authored
Introduce helper function macvlan_dev_real_dev which returns the underlying device of a macvlan device, similar to vlan_dev_real_dev() for 802.1q VLAN devices. v2: IFF_MACVLAN flag and equivalent of is_macvlan_dev() were introduced in the meantime v3: do BUG() if compiled without macvlan support Signed-off-by:
-
Wang Weidong authored
I met a Bug when I add ip target with the wrong ip address: echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target the wrong ip address will transfor to 245.245.245.244 and add to the ip target success, it is uncorrect, so I add checks to avoid adding wrong address. The in4_pton() will set wrong ip address to 0.0.0.0, it will return by the next check and will not add to ip target. v2 According Veaceslav's opinion, simplify the code. v3 According Veaceslav's opinion, add broadcast check and make a micro definition to package it. v4 Solve the problem of the format which David point out. Suggested-by:
Veaceslav Falico <vfalico@redhat.com> Suggested-by:
Ding Tianhong <dingtianhong@huawei.com> Signed-off-by:
-
Jukka Rissanen authored
If priority/traffic class field in IPv6 header is set (seen when using ssh), the uncompression sets the TC and Flow fields incorrectly. Example: This is IPv6 header of a sent packet. Note the priority/TC (=1) in the first byte. 00000000: 61 00 00 00 00 2c 06 40 fe 80 00 00 00 00 00 00 00000010: 02 02 72 ff fe c6 42 10 fe 80 00 00 00 00 00 00 00000020: 02 1e ab ff fe 4c 52 57 This gets compressed like this in the sending side 00000000: 72 31 04 06 02 1e ab ff fe 4c 52 57 ec c2 00 16 00000010: aa 2d fe 92 86 4e be c6 .... In the receiving end, the packet gets uncompressed to this IPv6 header 00000000: 60 06 06 02 00 2a 1e 40 fe 80 00 00 00 00 00 00 00000010: 02 02 72 ff fe c6 42 10 fe 80 00 00 00 00 00 00 00000020: ab ff fe 4c 52 57 ec c2 First four bytes are set incorrectly and we have also lost two bytes from destination address. The fix is to switch the case values in switch statement when checking the TC field. Signed-off-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by:
-
Erik Hugne authored
This fixes the following Smatch warning: net/tipc/link.c:2364 tipc_link_recv_fragment() warn: variable dereferenced before check '*head' (see line 2361) A null pointer might be passed to skb_try_coalesce if a malicious sender injects orphan fragments on a link. Signed-off-by:Erik Hugne <erik.hugne@ericsson.com> Signed-off-by:
-
- 14 Nov, 2013 27 commits
-
-
Eric Dumazet authored
ip4_datagram_connect() being called from process context, it should use IP_INC_STATS() instead of IP_INC_STATS_BH() otherwise we can deadlock on 32bit arches, or get corruptions of SNMP counters. Fixes: 584bdf8c ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP") Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Geyslan G. Bem authored
If 'hsr_get_node_data()' returns error, going directly to 'fail' label doesn't free the memory pointed by 'skb_out'. Signed-off-by:
Geyslan G. Bem <geyslan@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessDavid S. Miller authored
John W. Linville says: ==================== pull request: wireless 2013-11-14 Please pull this batch of fixes intended for the 3.13 stream! Amitkumar Karwar offers a quartet of mwifiex fixes, including an endian fix and three fixes for invalid memory access. Avinash Patil trims the packet length value for packets received from an SDIO interface. Colin Ian King fixes a NULL pointer dereference in the rtlwifi efuse code. Dan Carpenter cleans-up an mwifiex integer underflow, a potential libertas oops, a memory corrupion bug in wcn36xx, and a locking issue also in wcn36xx. Dan Williams helps prism54 devices to avoid being misclassified as Ethernet devices. Felipe Pena fixes a couple of typo errors, one in rt2x00 and the other in rtlwifi. Janusz Dziedzic corrects a pair of DFS-related problems in ath9k. Larry Finger patches three rtlwifi drivers to correctly report signal strength even for an unassociated AP. Mark Cave-Ayland rewrites some endian-illiterate packet type extraction code in rtlwifi. Stanislaw Gruszka addresses an rt2x00 regression related to setting HT station WCID and AMPDU density parameters. Sujith Manoharan corrects the initvals settings for AR9485. Ujjal Roy patches an obscure bit of code in mwifiex that was using the wrong definition of eth_hdr when briding patches in AP mode. Wei Yongjun fixes a couple of bugs: one is a return code handling bug in libertas; and, the other is a locking issue in wcn36xx. ==================== Signed-off-by: -
Michael Dalton authored
Commit 2613af0e ("virtio_net: migrate mergeable rx buffers to page frag allocators") changed the mergeable receive buffer size from PAGE_SIZE to MTU-size. However, the merge buffer size does not take into account the size of the virtio-net header. Consequently, packets that are MTU-size will take two buffers intead of one (to store the virtio-net header), substantially decreasing the throughput of MTU-size traffic due to TCP window / SKB truesize effects. This commit changes the mergeable buffer size to include the virtio-net header. The buffer size is cacheline-aligned because skb_page_frag_refill will not automatically align the requested size. Benchmarks taken from an average of 5 netperf 30-second TCP_STREAM runs between two QEMU VMs on a single physical machine. Each VM has two VCPUs and vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup cpuset, using cgroups to ensure that other processes in the system will not be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to force MTU-sized packets on the receiver. next-net trunk before 2613af0e (PAGE_SIZE buf): 3861.08Gb/s net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s net-next trunk w/ size fix (MTU 1500 - packet fits in one buf): 6445.44Gb/s Suggested-by:
Eric Northup <digitaleric@google.com> Signed-off-by:
Michael Dalton <mwdalton@google.com> Acked-by:
-
Chris Metcalf authored
In af3e095a, Erik Jacobsen fixed one type of unaligned access bug for ia64 by converting a 64-bit write to use put_unaligned(). Unfortunately, since gcc will convert a short memset() to a series of appropriately-aligned stores, the problem is now visible again on tilegx, where the memset that zeros out proc_event is converted to three 64-bit stores, causing an unaligned access panic. A better fix for the original problem is to ensure that proc_event is aligned to 8 bytes here. We can do that relatively easily by arranging to start the struct cn_msg aligned to 8 bytes and then offset by 4 bytes. Doing so means that the immediately following proc_event structure is then correctly aligned to 8 bytes. The result is that the memset() stores are now aligned, and as an added benefit, we can remove the put_unaligned() calls in the code. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Maciej Żenczykowski authored
Initial sch_fq implementation copied code from pfifo_fast to classify a packet as a high prio packet. This clashes with setups using PRIO with say 7 bands, as one of the band could be incorrectly (mis)classified by FQ. Packets would be queued in the 'internal' queue, and no pacing ever happen for this special queue. Fixes: afe4fd06 ("pkt_sched: fq: Fair Queue packet scheduler") Signed-off-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
-
hahnjo authored
This fixes bug 62491 (https://bugzilla.kernel.org/show_bug.cgi?id=62491). After resuming some users got the following error flooding the kernel log: alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff Signed-off-by:
Jonas Hahnfeld <linux@hahnjo.de> Signed-off-by:
-
David S. Miller authored
Johannes Berg says: ==================== genetlink: reduce ops size and complexity (v2) As before - reduce the complexity and data/code size of genetlink ops by making them an array rather than a linked list. Most users already use an array thanks to genl_register_family_with_ops(), so convert the remaining ones allowing us to get rid of the list head in each op. Also make them const, this just makes sense at that point and the security people like making function pointers const as well :-) ==================== Signed-off-by: -
Johannes Berg authored
To save some space in the struct on 32-bit systems, make the flags a u8 (only 4 bits are used) and also move them to the end of the struct. This has no impact on 64-bit systems as alignment of the struct in an array uses up the space anyway. Signed-off-by:
-
Johannes Berg authored
Now that genl_ops are no longer modified in place when registering, they can be made const. This patch was done mostly with spatch: @@ identifier ops; @@ +const struct genl_ops ops[] = { ... }; (except the struct thing in net/openvswitch/datapath.c) Signed-off-by: -
Johannes Berg authored
Allow making the ops array const by not modifying the ops flags on registration but rather only when ops are sent out in the family information. No users are updated yet except for the pre_doit/post_doit calls in wireless (the only ones that exist now.) Signed-off-by:
-
Johannes Berg authored
Instead of using a linked list, use an array. This reduces the data size needed by the users of genetlink, for example in wireless (net/wireless/nl80211.c) on 64-bit it frees up over 1K of data space. Remove the attempted sending of CTRL_CMD_NEWOPS ctrl event since genl_ctrl_event(CTRL_CMD_NEWOPS, ...) only returns -EINVAL anyway, therefore no such event could ever be sent. Signed-off-by:
-
Johannes Berg authored
genl_register_ops() is still needed for internal registration, but is no longer available to users of the API. Signed-off-by:
-
Johannes Berg authored
This simplifies the code since there's no longer a need to have error handling in the registration. Unfortunately it means more extern function declarations are needed, but the overall goal would seem to justify this. Due to the removal of duplication in the netlink policies, this reduces the size of wimax by almost 1k. Signed-off-by:
-
Johannes Berg authored
This simplifies the code since there's no longer a need to have error handling in the registration. Unfortunately it means more extern function declarations are needed, but the overall goal would seem to justify this. While at it, also fix the registration error path - if the family registration failed then it shouldn't be unregistered. Signed-off-by:
-
Johannes Berg authored
This simplifies the code since there's no longer a need to have error handling in the registration. Signed-off-by:
-
Johannes Berg authored
This simplifies the code since there's no longer a need to have error handling in the registration. Signed-off-by:
-
Nicolas Dichtel authored
Bug has been introduced by commit bb814094 ("ip6tnl: allow to use rtnl ops on fb tunnel"). When ip6_tunnel.ko is unloaded, FB device is delete by rtnl_link_unregister() and then we try to use the pointer in ip6_tnl_destroy_tunnels(). Let's add an handler for dellink, which will never remove the FB tunnel. With this patch it will no more be possible to remove it via 'ip link del ip6tnl0', but it's safer. The same fix was already proposed by Willem de Bruijn <willemb@google.com> for sit interfaces. CC: Willem de Bruijn <willemb@google.com> Reported-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Nicolas Dichtel authored
addrconf_add_linklocal() already adds the link local route, so there is no reason to add it before calling this function. Signed-off-by:
-
Nicolas Dichtel authored
When a link local address was added to a sit interface, the corresponding route was not configured. This breaks routing protocols that use the link local address, like OSPFv3. To ease the code reading, I remove sit_route_add(), which only adds v4 mapped routes, and add this kind of route directly in sit_add_v4_addrs(). Thus link local and v4 mapped routes are configured in the same place. Reported-by:
Li Hongjun <hongjun.li@6wind.com> Signed-off-by:
-
Nicolas Dichtel authored
When the local IPv4 endpoint is wilcard (0.0.0.0), the prefix length is correctly set, ie 64 if the address is a link local one or 96 if the address is a v4 mapped one. But when the local endpoint is specified, the prefix length is set to 128 for both kind of address. This patch fix this wrong prefix length. Signed-off-by:
-
Dan Carpenter authored
These strings come from a copy_from_user() and there is no way to be sure they are NUL terminated. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Willem de Bruijn authored
Bug: The fallback device is created in sit_init_net and assumed to be freed in sit_exit_net. First, it is dereferenced in that function, in sit_destroy_tunnels: struct net *net = dev_net(sitn->fb_tunnel_dev); Prior to this, rtnl_unlink_register has removed all devices that match rtnl_link_ops == sit_link_ops. Commit 205983c4 added the line + sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops; which cases the fallback device to match here and be freed before it is last dereferenced. Fix: This commit adds an explicit .delllink callback to sit_link_ops that skips deallocation at rtnl_unlink_register for the fallback device. This mechanism is comparable to the one in ip_tunnel. It also modifies sit_destroy_tunnels and its only caller sit_exit_net to avoid the offending dereference in the first place. That double lookup is more complicated than required. Test: The bug is only triggered when CONFIG_NET_NS is enabled. It causes a GPF only when CONFIG_DEBUG_SLAB is enabled. Verified that this bug exists at the mentioned commit, at davem-net HEAD and at 3.11.y HEAD. Verified that it went away after applying this patch. Fixes: 205983c4 ("sit: allow to use rtnl ops on fb tunnel") Signed-off-by: -
Duan Fugang-B38611 authored
The driver fails to check the results of DMA mapping and results in the following warning: (with kernel config "CONFIG_DMA_API_DEBUG" enable) ------------[ cut here ]------------ WARNING: at lib/dma-debug.c:937 check_unmap+0x43c/0x7d8() fec 2188000.ethernet: DMA-API: device driver failed to check map error[device address=0x00000000383a8040] [size=2048 bytes] [mapped as single] Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.17-16827-g9cdb0ba-dirty #188 [<80013c4c>] (unwind_backtrace+0x0/0xf8) from [<80011704>] (show_stack+0x10/0x14) [<80011704>] (show_stack+0x10/0x14) from [<80025614>] (warn_slowpath_common+0x4c/0x6c) [<80025614>] (warn_slowpath_common+0x4c/0x6c) from [<800256c8>] (warn_slowpath_fmt+0x30/0x40) [<800256c8>] (warn_slowpath_fmt+0x30/0x40) from [<8026bfdc>] (check_unmap+0x43c/0x7d8) [<8026bfdc>] (check_unmap+0x43c/0x7d8) from [<8026c584>] (debug_dma_unmap_page+0x6c/0x78) [<8026c584>] (debug_dma_unmap_page+0x6c/0x78) from [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8) [<8038049c>] (fec_enet_rx_napi+0x254/0x8a8) from [<804dc8c0>] (net_rx_action+0x94/0x160) [<804dc8c0>] (net_rx_action+0x94/0x160) from [<8002c758>] (__do_softirq+0xe8/0x1d0) [<8002c758>] (__do_softirq+0xe8/0x1d0) from [<8002c8e8>] (do_softirq+0x4c/0x58) [<8002c8e8>] (do_softirq+0x4c/0x58) from [<8002cb50>] (irq_exit+0x90/0xc8) [<8002cb50>] (irq_exit+0x90/0xc8) from [<8000ea88>] (handle_IRQ+0x3c/0x94) [<8000ea88>] (handle_IRQ+0x3c/0x94) from [<8000855c>] (gic_handle_irq+0x28/0x5c) [<8000855c>] (gic_handle_irq+0x28/0x5c) from [<8000de00>] (__irq_svc+0x40/0x50) Exception stack(0x815a5f38 to 0x815a5f80) 5f20: 815a5f80 3b9aca00 5f40: 0fe52383 00000002 0dd8950e 00000002 81e7b080 00000000 00000000 815ac4d8 5f60: 806032ec 00000000 00000017 815a5f80 80059028 8041fc4c 60000013 ffffffff [<8000de00>] (__irq_svc+0x40/0x50) from [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0) [<8041fc4c>] (cpuidle_enter_state+0x50/0xf0) from [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c) [<8041fd94>] (cpuidle_idle_call+0xa8/0x14c) from [<8000edac>] (arch_cpu_idle+0x10/0x4c) [<8000edac>] (arch_cpu_idle+0x10/0x4c) from [<800582f8>] (cpu_startup_entry+0x60/0x130) [<800582f8>] (cpu_startup_entry+0x60/0x130) from [<80bc7a48>] (start_kernel+0x2d0/0x328) [<80bc7a48>] (start_kernel+0x2d0/0x328) from [<10008074>] (0x10008074) ---[ end trace c6edec32436e0042 ]--- Because dma-debug add new interfaces to debug dma mapping errors, pls refer to: http://lwn.net/Articles/516640/ After dma mapping, it must call dma_mapping_error() to check mapping error, otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define the mapping is not checked and dump the error msg. So,add dma_mapping_error() checking to fix the WARNING And RX DMA buffers are used repeatedly and the driver copies it into an skb, fec_enet_rx() should not map or unmap, use dma_sync_single_for_cpu()/dma_sync_single_for_device() instead of dma_map_single()/dma_unmap_single(). There have another potential issue: fec_enet_rx() passes the DMA address to __va(). Physical and DMA addresses are *not* the same thing. They may differ if the device is behind an IOMMU or bounce buffering was required, or just because there is a fixed offset between the device and host physical addresses. Also fix it in this patch. ============================================= V2: add net_ratelimit() to limit map err message. use dma_sync_single_for_cpu() instead of dma_map_single(). fix the issue that pass DMA addresses to __va() to get virture address. V1: initial send ============================================= Signed-off-by:
Fugang Duan <B38611@freescale.com> Signed-off-by:
-
Chang Xiangzhong authored
When a transport recovers due to the new coming sack, SCTP should iterate all of its transport_list to locate the __two__ most recently used transport and set to active_path and retran_path respectively. The exising code does not find the two properly - In case of the following list: [most-recent] -> [2nd-most-recent] -> ... Both active_path and retran_path would be set to the 1st element. The bug happens when: 1) multi-homing 2) failure/partial_failure transport recovers Both active_path and retran_path would be set to the same most-recent one, in other words, retran_path would not take its role - an end user might not even notice this issue. Signed-off-by:
Chang Xiangzhong <changxiangzhong@gmail.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Eric Dumazet authored
We had some reports of crashes using TCP fastopen, and Dave Jones gave a nice stack trace pointing to the error. Issue is that tcp_get_metrics() should not be called with a NULL dst Fixes: 1fe4c481 ("net-tcp: Fast Open client - cookie cache") Signed-off-by:
Yuchung Cheng <ycheng@google.com> Tested-by:
Dave Jones <davej@fedoraproject.org> Signed-off-by:
-
Nikolay Aleksandrov authored
This patch fixes two race conditions between bond_store_updelay/downdelay and bond_store_miimon which could lead to division by zero as miimon can be set to 0 while either updelay/downdelay are being set and thus miss the zero check in the beginning, the zero div happens because updelay/downdelay are stored as new_value / bond->params.miimon. Use rtnl to synchronize with miimon setting. CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: Veaceslav Falico <vfalico@redhat.com> Signed-off-by:
Nikolay Aleksandrov <nikolay@redhat.com> Acked-by:
-
