- 14 Nov, 2013 40 commits
-
-
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:David S. Miller <davem@davemloft.net>
-
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 <johannes.berg@intel.com> 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:Eric Dumazet <edumazet@google.com> 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:
Dave Jones <davej@redhat.com> Cc: Yuchung Cheng <ycheng@google.com> Acked-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:
Veaceslav Falico <vfalico@redhat.com> Signed-off-by:
-
Eric Dumazet authored
After commit c9eeec26 ("tcp: TSQ can use a dynamic limit"), several users reported throughput regressions, notably on mvneta and wifi adapters. 802.11 AMPDU requires a fair amount of queueing to be effective. This patch partially reverts the change done in tcp_write_xmit() so that the minimal amount is sysctl_tcp_limit_output_bytes. It also remove the use of this sysctl while building skb stored in write queue, as TSO autosizing does the right thing anyway. Users with well behaving NICS and correct qdisc (like sch_fq), can then lower the default sysctl_tcp_limit_output_bytes value from 128KB to 8KB. This new usage of sysctl_tcp_limit_output_bytes permits each driver authors to check how their driver performs when/if the value is set to a minimum of 4KB. Normally, line rate for a single TCP flow should be possible, but some drivers rely on timers to perform TX completion and too long TX completion delays prevent reaching full throughput. Fixes: c9eeec26 ("tcp: TSQ can use a dynamic limit") Signed-off-by:
Sujith Manoharan <sujith@msujith.org> Reported-by:
Arnaud Ebalard <arno@natisbad.org> Tested-by:
-
David S. Miller authored
Ben Hutchings says: ==================== net_tstamp: Validate hwtstamp_config completely before applying it This series fixes very similar bugs in 6 implementations of SIOCSHWTSTAMP. ==================== Signed-off-by: -
Ben Hutchings authored
hwtstamp_ioctl() should validate all fields of hwtstamp_config before making any changes. Currently it sets the TX configuration before validating the rx_filter field. Untested as I don't have a cross-compiler to hand. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
Ben Hutchings authored
cpsw_hwtstamp_ioctl() should validate all fields of hwtstamp_config, and the hardware version, before making any changes. Currently it sets the TX configuration before validating the rx_filter field or that the hardware supports timestamping. Also correct the error code for hardware versions that don't support timestamping. ENOTSUPP is used by the NFS implementation and is not part of userland API; we want EOPNOTSUPP (which glibc also calls ENOTSUP, with one 'P'). Untested as I don't have a cross-compiler to hand. Signed-off-by:
Mugunthan V N <mugunthanvnm@gmail.com> Signed-off-by:
-
Ben Hutchings authored
stmmac_hwtstamp_ioctl() should validate all fields of hwtstamp_config before making any changes. Currently it sets the TX configuration before validating the rx_filter field. Compile-tested only. Signed-off-by:
-
Ben Hutchings authored
hwtstamp_ioctl() should validate all fields of hwtstamp_config before making any changes. Currently it sets the TX configuration before validating the rx_filter field. Compile-tested only. Signed-off-by:
-
Ben Hutchings authored
e1000e_hwtstamp_ioctl() should validate all fields of hwtstamp_config before making any changes. Currently it copies the configuration to the e1000_adapter structure before validating it at all. Change e1000e_config_hwtstamp() to take a pointer to the hwstamp_config and to copy the config after validating it. Compile-tested only. Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Ben Hutchings authored
tg3_hwtstamp_ioctl() should validate all fields of hwtstamp_config before making any changes. Currently it sets the TX configuration before validating the rx_filter field. Compile-tested only. Signed-off-by:
Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by:
-
Toshiaki Makita authored
We currently don't call br_vlan_flush() when deleting a bridge, which leads to memory leak if br->vlan_info is allocated. Steps to reproduce: while : do brctl addbr br0 bridge vlan add dev br0 vid 10 self brctl delbr br0 done We can observe the cache size of corresponding slab entry (as kmalloc-2048 in SLUB) is increased. kmemleak output: unreferenced object 0xffff8800b68a7000 (size 2048): comm "bridge", pid 2086, jiffies 4295774704 (age 47.656s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 48 9b 36 00 88 ff ff .........H.6.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815eb6ae>] kmemleak_alloc+0x4e/0xb0 [<ffffffff8116a1ca>] kmem_cache_alloc_trace+0xca/0x220 [<ffffffffa03eddd6>] br_vlan_add+0x66/0xe0 [bridge] [<ffffffffa03e543c>] br_setlink+0x2dc/0x340 [bridge] [<ffffffff8150e481>] rtnl_bridge_setlink+0x101/0x200 [<ffffffff8150d9d9>] rtnetlink_rcv_msg+0x99/0x260 [<ffffffff81528679>] netlink_rcv_skb+0xa9/0xc0 [<ffffffff8150d938>] rtnetlink_rcv+0x28/0x30 [<ffffffff81527ccd>] netlink_unicast+0xdd/0x190 [<ffffffff8152807f>] netlink_sendmsg+0x2ff/0x740 [<ffffffff814e8368>] sock_sendmsg+0x88/0xc0 [<ffffffff814e8ac8>] ___sys_sendmsg.part.14+0x298/0x2b0 [<ffffffff814e91de>] __sys_sendmsg+0x4e/0x90 [<ffffffff814e922e>] SyS_sendmsg+0xe/0x10 [<ffffffff81601669>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by:
-
Toshiaki Makita authored
We should call vlan_vid_del for all vids at nbp_vlan_flush to prevent vid_info->refcount from being leaked when detaching a bridge port. Signed-off-by:
-
Toshiaki Makita authored
We should use wrapper functions vlan_vid_[add/del] instead of ndo_vlan_rx_[add/kill]_vid. Otherwise, we might be not able to communicate using vlan interface in a certain situation. Example of problematic case: vconfig add eth0 10 brctl addif br0 eth0 bridge vlan add dev eth0 vid 10 bridge vlan del dev eth0 vid 10 brctl delif br0 eth0 In this case, we cannot communicate via eth0.10 because vlan 10 is filtered by NIC that has the vlan filtering feature. Signed-off-by:
-
Daniel Borkmann authored
Use msecs_to_jiffies, for these calculations as different HZ considerations are taken into account for conversion of the timer shot, and also it makes the code more readable. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Daniel Borkmann authored
We only call that in functions annotated with __init, so add __init prefix in prandom_start_seed_timer() as well, so that the kernel can make use of this hint and we can possibly free up resources after it's usage. And since it's an internal function rename it to __prandom_start_seed_timer(). Signed-off-by:
-
Jason Wang authored
We currently use hdr_len as a hint of head length which is advertised by guest. But when guest advertise a very big value, it can lead to an 64K+ allocating of kmalloc() which has a very high possibility of failure when host memory is fragmented or under heavy stress. The huge hdr_len also reduce the effect of zerocopy or even disable if a gso skb is linearized in guest. To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the head, which guarantees an order 0 allocation each time. Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Jason Wang authored
We currently use hdr_len as a hint of head length which is advertised by guest. But when guest advertise a very big value, it can lead to an 64K+ allocating of kmalloc() which has a very high possibility of failure when host memory is fragmented or under heavy stress. The huge hdr_len also reduce the effect of zerocopy or even disable if a gso skb is linearized in guest. To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the head, which guarantees an order 0 allocation each time. Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Dan Carpenter authored
We assume that "mp->phy" can be NULL a couple lines before the dereference. Fixes: 1cce16d3 ('net: mv643xx_eth: Add missing phy_addr_set in DT mode') Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Dan Carpenter authored
This is harmless but cdc_ncm_setup() returns negative error codes truncated to u8 values. There is only one caller and treats all non-zero returns as errors but doesn't store the the return code. So the code works correctly but it's messy and upsets the static checkers. Signed-off-by:
-
Alexei Starovoitov authored
commit 06a23fe3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()") and refactoring 64261f23 ("dev: move skb_scrub_packet() after eth_type_trans()") are forcing pkt_type to be PACKET_HOST when skb traverses veth. which means that ip forwarding will kick in inside netns even if skb->eth->h_dest != dev->dev_addr Fix order of eth_type_trans() and skb_scrub_packet() in dev_forward_skb() and in ip_tunnel_rcv() Fixes: 06a23fe3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()") CC: Isaku Yamahata <yamahatanetdev@gmail.com> CC: Maciej Zenczykowski <zenczykowski@gmail.com> CC: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
Felix Fietkau authored
Since commit 7b0c5f21 "sierra_net: keep status interrupt URB active", sierra_net triggers status interrupt polling before the net_device is opened (in order to properly receive the sync message response). To be able to receive further interrupts, the interrupt urb needs to be re-submitted, so this patch removes the bogus check for netif_running(). Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Tested-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Veaceslav Falico authored
Currently the ARP monitoring is not supported with 802.3ad, and it's prohibited to use it via the module params. However we still can set it afterwards via sysfs, cause we only check for *LB modes there. To fix this - add a check for 802.3ad mode in bonding_store_arp_interval. CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
-
