1. 04 Feb, 2015 5 commits
    • Chen Gang's avatar
      net: usb: sr9700: Use 'SR_' prefix for the common register macros · 06b19b1b
      Chen Gang authored
      The commone register macors (e.g. RSR) is too commont to drivers, it may
      be conflict with the architectures (e.g. xtensa, sh).
      
      The related warnings (with allmodconfig under xtensa):
      
          CC [M]  drivers/net/usb/sr9700.o
        In file included from drivers/net/usb/sr9700.c:24:0:
        drivers/net/usb/sr9700.h:65:0: warning: "RSR" redefined
         #define RSR   0x06
         ^
        In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
                         from include/linux/bitops.h:36,
                         from include/linux/kernel.h:10,
                         from include/linux/list.h:8,
                         from include/linux/module.h:9,
                         from drivers/net/usb/sr9700.c:13:
        ./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of the previous definition
         #define RSR(v,sr) __asm__ __volatile__ ("rsr %0,"__stringify(sr) : "=a"(v));
         ^
      Signed-off-by: default avatarChen Gang <gang.chen.5i5j@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06b19b1b
    • David S. Miller's avatar
      Merge branch 'virtio_net_ufo' · 4c122f4c
      David S. Miller authored
      Vladislav Yasevich says:
      
      ====================
      Restore UFO support to virtio_net devices
      
      commit 3d0ad094
      Author: Ben Hutchings <ben@decadent.org.uk>
      Date:   Thu Oct 30 18:27:12 2014 +0000
      
          drivers/net: Disable UFO through virtio
      
      Turned off UFO support to virtio-net based devices due to issues
      with IPv6 fragment id generation for UFO packets.  The issue
      was that IPv6 UFO/GSO implementation expects the fragment id
      to be supplied in skb_shinfo().  However, for packets generated
      by the VMs, the fragment id is not supplied which causes all
      IPv6 fragments to have the id of 0.
      
      The problem is that turning off UFO support on tap/macvtap
      as well as virtio devices caused issues with migrations.
      Migrations would fail when moving a vm from a kernel supporting
      expecting UFO to work to the newer kernels that disabled UFO.
      
      This series provides a partial solution to address the migration
      issue.  The series allows us to track whether skb_shinfo()->ip6_frag_id
      has been set by treating value of 0 as unset.
      This lets GSO code to generate fragment ids if they are necessary
      (ex: packet was generated by VM or packet socket).
      
      Since v3:
        - Resolved build issue when IPv6 is a module.
        - Removed trailing white space.
      
      Since v2:
        - Rebase and rebuild to make sure everything works.  No changes
          to the patches were done.
      
      Since v1:
        - Removed the skb bit and use value of 0 as tracker.
        - Used Eric's suggestion to set fragment id as 0x80000000 if id
          generation procedure yeilded a 0 result.
        - Consolidated ipv6 id genration code.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c122f4c
    • Vlad Yasevich's avatar
      Revert "drivers/net: Disable UFO through virtio" · e3e3c423
      Vlad Yasevich authored
      This reverts commit 3d0ad094.
      
      Now that GSO functionality can correctly track if the fragment
      id has been selected and select a fragment id if necessary,
      we can re-enable UFO on tap/macvap and virtio devices.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3e3c423
    • Vlad Yasevich's avatar
      Revert "drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets" · 72f65107
      Vlad Yasevich authored
      This reverts commit 5188cd44.
      
      Now that GSO layer can track if fragment id has been selected
      and can allocate one if necessary, we don't need to do this in
      tap and macvtap.  This reverts most of the code and only keeps
      the new ipv6 fragment id generation function that is still needed.
      
      Fixes: 3d0ad094 (drivers/net: Disable UFO through virtio)
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72f65107
    • Vlad Yasevich's avatar
      ipv6: Select fragment id during UFO segmentation if not set. · 0508c07f
      Vlad Yasevich authored
      If the IPv6 fragment id has not been set and we perform
      fragmentation due to UFO, select a new fragment id.
      We now consider a fragment id of 0 as unset and if id selection
      process returns 0 (after all the pertrubations), we set it to
      0x80000000, thus giving us ample space not to create collisions
      with the next packet we may have to fragment.
      
      When doing UFO integrity checking, we also select the
      fragment id if it has not be set yet.   This is stored into
      the skb_shinfo() thus allowing UFO to function correclty.
      
      This patch also removes duplicate fragment id generation code
      and moves ipv6_select_ident() into the header as it may be
      used during GSO.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0508c07f
  2. 03 Feb, 2015 7 commits
  3. 02 Feb, 2015 1 commit
    • Eric Dumazet's avatar
      ipv4: tcp: get rid of ugly unicast_sock · bdbbb852
      Eric Dumazet authored
      In commit be9f4a44 ("ipv4: tcp: remove per net tcp_sock")
      I tried to address contention on a socket lock, but the solution
      I chose was horrible :
      
      commit 3a7c384f ("ipv4: tcp: unicast_sock should not land outside
      of TCP stack") addressed a selinux regression.
      
      commit 0980e56e ("ipv4: tcp: set unicast_sock uc_ttl to -1")
      took care of another regression.
      
      commit b5ec8eea ("ipv4: fix ip_send_skb()") fixed another regression.
      
      commit 811230cd ("tcp: ipv4: initialize unicast_sock sk_pacing_rate")
      was another shot in the dark.
      
      Really, just use a proper socket per cpu, and remove the skb_orphan()
      call, to re-enable flow control.
      
      This solves a serious problem with FQ packet scheduler when used in
      hostile environments, as we do not want to allocate a flow structure
      for every RST packet sent in response to a spoofed packet.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bdbbb852
  4. 01 Feb, 2015 2 commits
    • Eric Dumazet's avatar
      net: sched: fix panic in rate estimators · 0d32ef8c
      Eric Dumazet authored
      Doing the following commands on a non idle network device
      panics the box instantly, because cpu_bstats gets overwritten
      by stats.
      
      tc qdisc add dev eth0 root <your_favorite_qdisc>
      ... some traffic (one packet is enough) ...
      tc qdisc replace dev eth0 root est 1sec 4sec <your_favorite_qdisc>
      
      [  325.355596] BUG: unable to handle kernel paging request at ffff8841dc5a074c
      [  325.362609] IP: [<ffffffff81541c9e>] __gnet_stats_copy_basic+0x3e/0x90
      [  325.369158] PGD 1fa7067 PUD 0
      [  325.372254] Oops: 0000 [#1] SMP
      [  325.375514] Modules linked in: ...
      [  325.398346] CPU: 13 PID: 14313 Comm: tc Not tainted 3.19.0-smp-DEV #1163
      [  325.412042] task: ffff8800793ab5d0 ti: ffff881ff2fa4000 task.ti: ffff881ff2fa4000
      [  325.419518] RIP: 0010:[<ffffffff81541c9e>]  [<ffffffff81541c9e>] __gnet_stats_copy_basic+0x3e/0x90
      [  325.428506] RSP: 0018:ffff881ff2fa7928  EFLAGS: 00010286
      [  325.433824] RAX: 000000000000000c RBX: ffff881ff2fa796c RCX: 000000000000000c
      [  325.440988] RDX: ffff8841dc5a0744 RSI: 0000000000000060 RDI: 0000000000000060
      [  325.448120] RBP: ffff881ff2fa7948 R08: ffffffff81cd4f80 R09: 0000000000000000
      [  325.455268] R10: ffff883ff223e400 R11: 0000000000000000 R12: 000000015cba0744
      [  325.462405] R13: ffffffff81cd4f80 R14: ffff883ff223e460 R15: ffff883feea0722c
      [  325.469536] FS:  00007f2ee30fa700(0000) GS:ffff88407fa20000(0000) knlGS:0000000000000000
      [  325.477630] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  325.483380] CR2: ffff8841dc5a074c CR3: 0000003feeae9000 CR4: 00000000001407e0
      [  325.490510] Stack:
      [  325.492524]  ffff883feea0722c ffff883fef719dc0 ffff883feea0722c ffff883ff223e4a0
      [  325.499990]  ffff881ff2fa79a8 ffffffff815424ee ffff883ff223e49c 000000015cba0744
      [  325.507460]  00000000f2fa7978 0000000000000000 ffff881ff2fa79a8 ffff883ff223e4a0
      [  325.514956] Call Trace:
      [  325.517412]  [<ffffffff815424ee>] gen_new_estimator+0x8e/0x230
      [  325.523250]  [<ffffffff815427aa>] gen_replace_estimator+0x4a/0x60
      [  325.529349]  [<ffffffff815718ab>] tc_modify_qdisc+0x52b/0x590
      [  325.535117]  [<ffffffff8155edd0>] rtnetlink_rcv_msg+0xa0/0x240
      [  325.540963]  [<ffffffff8155ed30>] ? __rtnl_unlock+0x20/0x20
      [  325.546532]  [<ffffffff8157f811>] netlink_rcv_skb+0xb1/0xc0
      [  325.552145]  [<ffffffff8155b355>] rtnetlink_rcv+0x25/0x40
      [  325.557558]  [<ffffffff8157f0d8>] netlink_unicast+0x168/0x220
      [  325.563317]  [<ffffffff8157f47c>] netlink_sendmsg+0x2ec/0x3e0
      
      Lets play safe and not use an union : percpu 'pointers' are mostly read
      anyway, and we have typically few qdiscs per host.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Fixes: 22e0f8b9 ("net: sched: make bstats per cpu and estimator RCU safe")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d32ef8c
    • Haiyang Zhang's avatar
      hyperv: Fix the error processing in netvsc_send() · d953ca4d
      Haiyang Zhang authored
      The existing code frees the skb in EAGAIN case, in which the skb will be
      retried from upper layer and used again.
      Also, the existing code doesn't free send buffer slot in error case, because
      there is no completion message for unsent packets.
      This patch fixes these problems.
      
      (Please also include this patch for stable trees. Thanks!)
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Reviewed-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d953ca4d
  5. 31 Jan, 2015 8 commits
    • Iyappan Subramanian's avatar
      drivers: net: xgene: fix: Out of order descriptor bytes read · ecf6ba83
      Iyappan Subramanian authored
      This patch fixes the following kernel crash,
      
      	WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_input.c:3079 tcp_clean_rtx_queue+0x658/0x80c()
      	Call trace:
      	[<fffffe0000096b7c>] dump_backtrace+0x0/0x184
      	[<fffffe0000096d10>] show_stack+0x10/0x1c
      	[<fffffe0000685ea0>] dump_stack+0x74/0x98
      	[<fffffe00000b44e0>] warn_slowpath_common+0x88/0xb0
      	[<fffffe00000b461c>] warn_slowpath_null+0x14/0x20
      	[<fffffe00005b5c1c>] tcp_clean_rtx_queue+0x654/0x80c
      	[<fffffe00005b6228>] tcp_ack+0x454/0x688
      	[<fffffe00005b6ca8>] tcp_rcv_established+0x4a4/0x62c
      	[<fffffe00005bf4b4>] tcp_v4_do_rcv+0x16c/0x350
      	[<fffffe00005c225c>] tcp_v4_rcv+0x8e8/0x904
      	[<fffffe000059d470>] ip_local_deliver_finish+0x100/0x26c
      	[<fffffe000059dad8>] ip_local_deliver+0xac/0xc4
      	[<fffffe000059d6c4>] ip_rcv_finish+0xe8/0x328
      	[<fffffe000059dd3c>] ip_rcv+0x24c/0x38c
      	[<fffffe0000563950>] __netif_receive_skb_core+0x29c/0x7c8
      	[<fffffe0000563ea4>] __netif_receive_skb+0x28/0x7c
      	[<fffffe0000563f54>] netif_receive_skb_internal+0x5c/0xe0
      	[<fffffe0000564810>] napi_gro_receive+0xb4/0x110
      	[<fffffe0000482a2c>] xgene_enet_process_ring+0x144/0x338
      	[<fffffe0000482d18>] xgene_enet_napi+0x1c/0x50
      	[<fffffe0000565454>] net_rx_action+0x154/0x228
      	[<fffffe00000b804c>] __do_softirq+0x110/0x28c
      	[<fffffe00000b8424>] irq_exit+0x8c/0xc0
      	[<fffffe0000093898>] handle_IRQ+0x44/0xa8
      	[<fffffe000009032c>] gic_handle_irq+0x38/0x7c
      	[...]
      
      Software writes poison data into the descriptor bytes[15:8] and upon
      receiving the interrupt, if those bytes are overwritten by the hardware with
      the valid data, software also reads bytes[7:0] and executes receive/tx
      completion logic.
      
      If the CPU executes the above two reads in out of order fashion, then the
      bytes[7:0] will have older data and causing the kernel panic.  We have to
      force the order of the reads and thus this patch introduces read memory
      barrier between these reads.
      Signed-off-by: default avatarIyappan Subramanian <isubramanian@apm.com>
      Signed-off-by: default avatarKeyur Chudgar <kchudgar@apm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ecf6ba83
    • David S. Miller's avatar
      Merge branch 'vlan_get_protocol' · 08178e5a
      David S. Miller authored
      Toshiaki Makita says:
      
      ====================
      Fix checksum error when using stacked vlan
      
      When I was testing 802.1ad, I found several drivers don't take into
      account 802.1ad or multiple vlans when retrieving L3 (IP/IPv6) or
      L4 (TCP/UDP) protocol for checksum offload.
      
      It is mainly due to vlan_get_protocol(), which extracts ether type only
      when it is tagged with single 802.1Q. When 802.1ad is used or there are
      multiple vlans, it extracts vlan protocol and drivers cannot determine
      which L3/L4 protocol is used.
      
      Those drivers, most of which have IP_CSUM/IPV6_CSUM features, get L3/L4
      header-offset by software, so it seems that their checksum offload works
      with multiple vlans if we can parse protocols correctly.
      (They know mac header length, and probably don't care about what is in it.)
      
      And another thing, some of Intel's drivers seem to use skb->protocol where
      vlan_get_protocol() is more suitable.
      
      I tested that at least igb/igbvf on I350 works with this patch set.
      
      Note:
      We can hand a double tagged packet with CHECKSUM_PARTIAL to a HW driver
      by creating a vlan device on a bridge device and enabling vlan_filtering
      of the bridge with 802.1ad protocol.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08178e5a
    • Toshiaki Makita's avatar
      ixgbevf: Fix checksum error when using stacked vlan · 10e4fb33
      Toshiaki Makita authored
      When a skb has multiple vlans and it is CHECKSUM_PARTIAL,
      ixgbevf_tx_csum() fails to get the network protocol and checksum related
      descriptor fields are not configured correctly because skb->protocol
      doesn't show the L3 protocol in this case.
      
      Use first->protocol instead of skb->protocol to get the proper network
      protocol.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10e4fb33
    • Toshiaki Makita's avatar
      ixgbe: Fix checksum error when using stacked vlan · 0213668f
      Toshiaki Makita authored
      When a skb has multiple vlans and it is CHECKSUM_PARTIAL,
      ixgbe_tx_csum() fails to get the network protocol and checksum related
      descriptor fields are not configured correctly because skb->protocol
      doesn't show the L3 protocol in this case.
      
      Use vlan_get_protocol() to get the proper network protocol.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0213668f
    • Toshiaki Makita's avatar
      igbvf: Fix checksum error when using stacked vlan · 72b14059
      Toshiaki Makita authored
      When a skb has multiple vlans and it is CHECKSUM_PARTIAL,
      igbvf_tx_csum() fails to get the network protocol and checksum related
      descriptor fields are not configured correctly because skb->protocol
      doesn't show the L3 protocol in this case.
      
      Use vlan_get_protocol() to get the proper network protocol.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72b14059
    • Toshiaki Makita's avatar
      net: Fix vlan_get_protocol for stacked vlan · d4bcef3f
      Toshiaki Makita authored
      vlan_get_protocol() could not get network protocol if a skb has a 802.1ad
      vlan tag or multiple vlans, which caused incorrect checksum calculation
      in several drivers.
      
      Fix vlan_get_protocol() to retrieve network protocol instead of incorrect
      vlan protocol.
      
      As the logic is the same as skb_network_protocol(), create a common helper
      function __vlan_get_protocol() and call it from existing functions.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4bcef3f
    • Saran Maruti Ramanara's avatar
      net: sctp: fix passing wrong parameter header to param_type2af in sctp_process_param · cfbf654e
      Saran Maruti Ramanara authored
      When making use of RFC5061, section 4.2.4. for setting the primary IP
      address, we're passing a wrong parameter header to param_type2af(),
      resulting always in NULL being returned.
      
      At this point, param.p points to a sctp_addip_param struct, containing
      a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation
      id. Followed by that, as also presented in RFC5061 section 4.2.4., comes
      the actual sctp_addr_param, which also contains a sctp_paramhdr, but
      this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that
      param_type2af() can make use of. Since we already hold a pointer to
      addr_param from previous line, just reuse it for param_type2af().
      
      Fixes: d6de3097 ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
      Signed-off-by: default avatarSaran Maruti Ramanara <saran.neti@telus.com>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfbf654e
    • Pablo Neira's avatar
      netlink: fix wrong subscription bitmask to group mapping in · 8b7c36d8
      Pablo Neira authored
      The subscription bitmask passed via struct sockaddr_nl is converted to
      the group number when calling the netlink_bind() and netlink_unbind()
      callbacks.
      
      The conversion is however incorrect since bitmask (1 << 0) needs to be
      mapped to group number 1. Note that you cannot specify the group number 0
      (usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
      since this is rejected through -EINVAL.
      
      This problem became noticeable since 97840cb6 ("netfilter: nfnetlink:
      fix insufficient validation in nfnetlink_bind") when binding to bitmask
      (1 << 0) in ctnetlink.
      Reported-by: default avatarAndre Tomt <andre@tomt.net>
      Reported-by: default avatarIvan Delalande <colona@arista.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b7c36d8
  6. 30 Jan, 2015 2 commits
  7. 29 Jan, 2015 15 commits
    • Li Wei's avatar
      ipv4: Don't increase PMTU with Datagram Too Big message. · 3cdaa5be
      Li Wei authored
      RFC 1191 said, "a host MUST not increase its estimate of the Path
      MTU in response to the contents of a Datagram Too Big message."
      Signed-off-by: default avatarLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3cdaa5be
    • David S. Miller's avatar
      Merge branch 'arm-build-fixes' · a1a0b558
      David S. Miller authored
      Arnd Bergmann says:
      
      ====================
      net: driver fixes from arm randconfig builds
      
      These four patches are fallout from test builds on ARM. I have a
      few more of them in my backlog but have not yet confirmed them
      to still be valid.
      
      The first three patches are about incomplete dependencies on
      old drivers. One could backport them to the beginning of time
      in theory, but there is little value since nobody would run into
      these problems.
      
      The final patch is one I had submitted before together with the
      respective pcmcia patch but forgot to follow up on that. It's
      still a valid but relatively theoretical bug, because the previous
      behavior of the driver was just as broken as what we have in
      mainline.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1a0b558
    • Arnd Bergmann's avatar
      net: am2150: fix nmclan_cs.c shared interrupt handling · 96a30175
      Arnd Bergmann authored
      A recent patch tried to work around a valid warning for the use of a
      deprecated interface by blindly changing from the old
      pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().
      
      This driver has an interrupt handler that is not currently aware
      of shared interrupts, but can be easily converted to be.
      At the moment, the driver reads the interrupt status register
      repeatedly until it contains only zeroes in the interesting bits,
      and handles each bit individually.
      
      This patch adds the missing part of returning IRQ_NONE in case none
      of the bits are set to start with, so we can move on to the next
      interrupt source.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 5f5316fc ("am2150: Update nmclan_cs.c to use update PCMCIA API")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96a30175
    • Arnd Bergmann's avatar
      net: lance,ni64: don't build for ARM · e9b106b8
      Arnd Bergmann authored
      The ni65 and lance ethernet drivers manually program the ISA DMA
      controller that is only available on x86 PCs and a few compatible
      systems. Trying to build it on ARM results in this error:
      
      ni65.c: In function 'ni65_probe1':
      ni65.c:496:62: error: 'DMA1_STAT_REG' undeclared (first use in this function)
           ((inb(DMA1_STAT_REG) >> 4) & 0x0f)
                                                                    ^
      ni65.c:496:62: note: each undeclared identifier is reported only once for each function it appears in
      ni65.c:497:63: error: 'DMA2_STAT_REG' undeclared (first use in this function)
           | (inb(DMA2_STAT_REG) & 0xf0);
      
      The DMA1_STAT_REG and DMA2_STAT_REG registers are only defined for
      alpha, mips, parisc, powerpc and x86, although it is not clear
      which subarchitectures actually have them at the correct location.
      
      This patch for now just disables it for ARM, to avoid randconfig
      build errors. We could also decide to limit it to the set of
      architectures on which it does compile, but that might look more
      deliberate than guessing based on where the drivers build.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9b106b8
    • Arnd Bergmann's avatar
      net: wan: add missing virt_to_bus dependencies · 303c28d8
      Arnd Bergmann authored
      The cosa driver is rather outdated and does not get built on most
      platforms because it requires the ISA_DMA_API symbol. However
      there are some ARM platforms that have ISA_DMA_API but no virt_to_bus,
      and they get this build error when enabling the ltpc driver.
      
      drivers/net/wan/cosa.c: In function 'tx_interrupt':
      drivers/net/wan/cosa.c:1768:3: error: implicit declaration of function 'virt_to_bus'
         unsigned long addr = virt_to_bus(cosa->txbuf);
         ^
      
      The same problem exists for the Hostess SV-11 and Sealevel Systems 4021
      drivers.
      
      This adds another dependency in Kconfig to avoid that configuration.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      303c28d8
    • Arnd Bergmann's avatar
      net: cs89x0: always build platform code if !HAS_IOPORT_MAP · fc9a5707
      Arnd Bergmann authored
      The cs89x0 driver can either be built as an ISA driver or a platform
      driver, the choice is controlled by the CS89x0_PLATFORM Kconfig
      symbol. Building the ISA driver on a system that does not have
      a way to map I/O ports fails with this error:
      
      drivers/built-in.o: In function `cs89x0_ioport_probe.constprop.1':
      :(.init.text+0x4794): undefined reference to `ioport_map'
      :(.init.text+0x4830): undefined reference to `ioport_unmap'
      
      This changes the Kconfig logic to take that option away and
      always force building the platform variant of this driver if
      CONFIG_HAS_IOPORT_MAP is not set. This is the only correct
      choice in this case, and it avoids the build error.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc9a5707
    • Florian Westphal's avatar
      ppp: deflate: never return len larger than output buffer · e2a4800e
      Florian Westphal authored
      When we've run out of space in the output buffer to store more data, we
      will call zlib_deflate with a NULL output buffer until we've consumed
      remaining input.
      
      When this happens, olen contains the size the output buffer would have
      consumed iff we'd have had enough room.
      
      This can later cause skb_over_panic when ppp_generic skb_put()s
      the returned length.
      Reported-by: default avatarIain Douglas <centos@1n6.org.uk>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2a4800e
    • David S. Miller's avatar
      Merge branch 'netns' · d445d63b
      David S. Miller authored
      Nicolas Dichtel says:
      
      ====================
      netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
      
      When one of these attributes is set, the netdevice is created into the netns
      pointed by IFLA_NET_NS_[PID|FD] (see the call to rtnl_create_link() in
      rtnl_newlink()). Let's call this netns the dest_net. After this creation, if the
      newlink handler exists, it is called with a netns argument that points to the
      netns where the netlink message has been received (called src_net in the code)
      which is the link netns.
      Hence, with one of these attributes, it's possible to create a x-netns
      netdevice.
      
      Here is the result of my code review:
      - all ip tunnels (sit, ipip, ip6_tunnels, gre[tap][v6], ip_vti[6]) does not
        really allows to use this feature: the netdevice is created in the dest_net
        and the src_net is completely ignored in the newlink handler.
      - VLAN properly handles this x-netns creation.
      - bridge ignores src_net, which seems fine (NETIF_F_NETNS_LOCAL is set).
      - CAIF subsystem is not clear for me (I don't know how it works), but it seems
        to wrongly use src_net. Patch #1 tries to fix this, but it was done only by
        code review (and only compile-tested), so please carefully review it. I may
        miss something.
      - HSR subsystem uses src_net to parse IFLA_HSR_SLAVE[1|2], but the netdevice has
        the flag NETIF_F_NETNS_LOCAL, so the question is: does this netdevice really
        supports x-netns? If not, the newlink handler should use the dest_net instead
        of src_net, I can provide the patch.
      - ieee802154 uses also src_net and does not have NETIF_F_NETNS_LOCAL. Same
        question: does this netdevice really supports x-netns?
      - bonding ignores src_net and flag NETIF_F_NETNS_LOCAL is set, ie x-netns is not
        supported. Fine.
      - CAN does not support rtnl/newlink, ok.
      - ipvlan uses src_net and does not have NETIF_F_NETNS_LOCAL. After looking at
        the code, it seems that this drivers support x-netns. Am I right?
      - macvlan/macvtap uses src_net and seems to have x-netns support.
      - team ignores src_net and has the flag NETIF_F_NETNS_LOCAL, ie x-netns is not
        supported. Ok.
      - veth uses src_net and have x-netns support ;-) Ok.
      - VXLAN didn't properly handle this. The link netns (vxlan->net) is the src_net
        and not dest_net (see patch #2). Note that it was already possible to create a
        x-netns vxlan before the commit f01ec1c0 ("vxlan: add x-netns support")
        but the nedevice remains broken.
      
      To summarize:
       - CAIF patch must be carefully reviewed
       - for HSR, ieee802154, ipvlan: is x-netns supported?
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d445d63b
    • Nicolas Dichtel's avatar
      vxlan: setup the right link netns in newlink hdlr · 33564bbb
      Nicolas Dichtel authored
      Rename the netns to src_net to avoid confusion with the netns where the
      interface stands. The user may specify IFLA_NET_NS_[PID|FD] to create
      a x-netns netndevice: IFLA_NET_NS_[PID|FD] points to the netns where the
      netdevice stands and src_net to the link netns.
      
      Note that before commit f01ec1c0 ("vxlan: add x-netns support"), it was
      possible to create a x-netns vxlan netdevice, but the netdevice was not
      operational.
      
      Fixes: f01ec1c0 ("vxlan: add x-netns support")
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33564bbb
    • Nicolas Dichtel's avatar
      caif: remove wrong dev_net_set() call · 8997c27e
      Nicolas Dichtel authored
      src_net points to the netns where the netlink message has been received. This
      netns may be different from the netns where the interface is created (because
      the user may add IFLA_NET_NS_[PID|FD]). In this case, src_net is the link netns.
      
      It seems wrong to override the netns in the newlink() handler because if it
      was not already src_net, it means that the user explicitly asks to create the
      netdevice in another netns.
      
      CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
      CC: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
      Fixes: 8391c4aa ("caif: Bugfixes in CAIF netdevice for close and flow control")
      Fixes: c4125400 ("caif-hsi: Add rtnl support")
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8997c27e
    • karl beldan's avatar
      lib/checksum.c: fix build for generic csum_tcpudp_nofold · 9ce35779
      karl beldan authored
      Fixed commit added from64to32 under _#ifndef do_csum_ but used it
      under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
      robot reported TILEGX's). Move from64to32 under the latter.
      
      Fixes: 150ae0e9 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarKarl Beldan <karl.beldan@rivierawaves.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ce35779
    • Eric Dumazet's avatar
      tcp: ipv4: initialize unicast_sock sk_pacing_rate · 811230cd
      Eric Dumazet authored
      When I added sk_pacing_rate field, I forgot to initialize its value
      in the per cpu unicast_sock used in ip_send_unicast_reply()
      
      This means that for sch_fq users, RST packets, or ACK packets sent
      on behalf of TIME_WAIT sockets might be sent to slowly or even dropped
      once we reach the per flow limit.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: 95bd09eb ("tcp: TSO packets automatic sizing")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      811230cd
    • karl beldan's avatar
      lib/checksum.c: fix carry in csum_tcpudp_nofold · 150ae0e9
      karl beldan authored
      The carry from the 64->32bits folding was dropped, e.g with:
      saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1,
      csum_tcpudp_nofold returned 0 instead of 1.
      Signed-off-by: default avatarKarl Beldan <karl.beldan@rivierawaves.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      150ae0e9
    • Roopa Prabhu's avatar
      bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify · 59ccaaaa
      Roopa Prabhu authored
      Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081
      
      This patch avoids calling rtnl_notify if the device ndo_bridge_getlink
      handler does not return any bytes in the skb.
      
      Alternately, the skb->len check can be moved inside rtnl_notify.
      
      For the bridge vlan case described in 92081, there is also a fix needed
      in bridge driver to generate a proper notification. Will fix that in
      subsequent patch.
      
      v2: rebase patch on net tree
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59ccaaaa
    • David S. Miller's avatar
      Merge branch 'tcp_stretch_acks' · 95224ac1
      David S. Miller authored
      Neal Cardwell says:
      
      ====================
      fix stretch ACK bugs in TCP CUBIC and Reno
      
      This patch series fixes the TCP CUBIC and Reno congestion control
      modules to properly handle stretch ACKs in their respective additive
      increase modes, and in the transitions from slow start to additive
      increase.
      
      This finishes the project started by commit 9f9843a7 ("tcp:
      properly handle stretch acks in slow start"), which fixed behavior for
      TCP congestion control when handling stretch ACKs in slow start mode.
      
      Motivation: In the Jan 2015 netdev thread 'BW regression after "tcp:
      refine TSO autosizing"', Eyal Perry documented a regression that Eric
      Dumazet determined was caused by improper handling of TCP stretch
      ACKs.
      
      Background: LRO, GRO, delayed ACKs, and middleboxes can cause "stretch
      ACKs" that cover more than the RFC-specified maximum of 2
      packets. These stretch ACKs can cause serious performance shortfalls
      in common congestion control algorithms, like Reno and CUBIC, which
      were designed and tuned years ago with receiver hosts that were not
      using LRO or GRO, and were instead ACKing every other packet.
      
      Testing: at Google we have been using this approach for handling
      stretch ACKs for CUBIC datacenter and Internet traffic for several
      years, with good results.
      
      v2:
       * fixed return type of tcp_slow_start() to be u32 instead of int
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95224ac1