1. 21 Sep, 2015 25 commits
  2. 18 Sep, 2015 15 commits
    • Eric Dumazet's avatar
      tcp_cubic: do not set epoch_start in the future · c2e7204d
      Eric Dumazet authored
      Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
      is normally set at ACK processing time, not at send time.
      
      Doing a proper fix would need to add an additional state variable,
      and does not seem worth the trouble, given CUBIC bug has been there
      forever before Jana noticed it.
      
      Let's simply not set epoch_start in the future, otherwise
      bictcp_update() could overflow and CUBIC would again
      grow cwnd too fast.
      
      This was detected thanks to a packetdrill test Neal wrote that was flaky
      before applying this fix.
      
      Fixes: 30927520 ("tcp_cubic: better follow cubic curve after idle period")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Cc: Jana Iyengar <jri@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2e7204d
    • Taku Izumi's avatar
      fjes: fix off-by-one error at fjes_hw_update_zone_task() · adb094e5
      Taku Izumi authored
      Dan Carpenter reported off-by-one error of fjes at
      http://www.mail-archive.com/netdev@vger.kernel.org/msg77520.html
      
      Actually this is a bug.
      ep_shm_info[epidx].{es_status, zone} should be update
      inside for loop.
      
      This patch fixes this bug.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTaku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      adb094e5
    • Jiri Benc's avatar
      MAINTAINERS: remove bouncing email address for qlcnic · 6cf35642
      Jiri Benc authored
      I got this automated message from <shahed.shaikh@qlogic.com> when submitting
      a qlcnic patch:
      
      > Shahed Shaikh is no longer with QLogic. If you require assistance please
      > contact Ariel Elior Ariel.Elior@qlogic.com
      
      There's no point in having a bouncing address in MAINTAINERS.
      
      CC: Dept-GELinuxNICDev@qlogic.com
      CC: Ariel Elior <Ariel.Elior@qlogic.com>
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6cf35642
    • David S. Miller's avatar
      Merge branch 'vxlan-fixes' · 1bdc0b10
      David S. Miller authored
      Jiri Benc says:
      
      ====================
      vxlan fixes
      
      This fixes various issues with vxlan related to IPv6.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1bdc0b10
    • Jiri Benc's avatar
      bnx2x: track vxlan port count · ac7eccd4
      Jiri Benc authored
      The callback for adding vxlan port can be called with the same port for
      both IPv4 and IPv6. Do not disable the offloading when the same port for
      both protocols is added and later one of them removed.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac7eccd4
    • Jiri Benc's avatar
      be2net: allow offloading with the same port for IPv4 and IPv6 · 1e5b311a
      Jiri Benc authored
      The callback for adding vxlan port can be called with the same port for both
      IPv4 and IPv6. Do not disable the offloading if this occurs.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Acked-by: default avatarSathya Perla <sathya.perla@avagotech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e5b311a
    • Jiri Benc's avatar
      qlcnic: track vxlan port count · 378fddc2
      Jiri Benc authored
      The callback for adding vxlan port can be called with the same port for
      both IPv4 and IPv6. Do not disable the offloading when the same port for
      both protocols is added and later one of them removed.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      378fddc2
    • Jiri Benc's avatar
      vxlan: reject IPv6 addresses if IPv6 is not configured · 057ba29b
      Jiri Benc authored
      When IPv6 address is set without IPv6 configured, the vxlan socket is mostly
      treated as an IPv4 one but various lookus in fdb etc. still take the
      AF_INET6 into account. This creates incosistencies with weird consequences.
      
      Just reject IPv6 addresses in such case.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      057ba29b
    • Jiri Benc's avatar
      vxlan: set needed headroom correctly · 9dc2ad10
      Jiri Benc authored
      vxlan_setup is called when allocating the net_device, i.e. way before
      vxlan_newlink (or vxlan_dev_configure) is called. This means
      vxlan->default_dst is actually unset in vxlan_setup and the condition that
      sets needed_headroom always takes the else branch.
      
      Set the needed_headrom at the point when we have the information about
      the address family available.
      
      Fixes: e4c7ed41 ("vxlan: add ipv6 support")
      Fixes: 2853af6a ("vxlan: use dev->needed_headroom instead of dev->hard_header_len")
      CC: Cong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9dc2ad10
    • Michael Grzeschik's avatar
      MAINTAINERS: add arcnet and take maintainership · c38f6ac7
      Michael Grzeschik authored
      Add entry for arcnet to MAINTAINERS file and add myself as the
      maintainer of the subsystem.
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Cc: davem@davemloft.net
      Cc: joe@perches.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c38f6ac7
    • Michael Grzeschik's avatar
      ARCNET: fix hard_header_len limit · 980137a2
      Michael Grzeschik authored
      For arcnet the bare minimum header only contains the 4 bytes to
      specify source, dest and offset (1, 1 and 2 bytes respectively).
      The corresponding struct is struct arc_hardware.
      
      The struct archdr contains additionally a union of possible soft
      headers. When doing $insertusecasehere packets might well
      include short (or even no?) soft headers.
      
      For this reason only use arc_hardware instead of archdr to
      determine the hard_header_len for an arcnet device.
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      980137a2
    • David S. Miller's avatar
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth · 1dbb2413
      David S. Miller authored
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth 2015-09-17
      
      Here's one important patch for the 4.3-rc series that fixes an issue
      with Bluetooth LE encryption failing because of a too early check for
      the SMP context.
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1dbb2413
    • Sasha Levin's avatar
      atm: deal with setting entry before mkip was called · 34f5b006
      Sasha Levin authored
      If we didn't call ATMARP_MKIP before ATMARP_ENCAP the VCC descriptor is
      non-existant and we'll end up dereferencing a NULL ptr:
      
      [1033173.491930] kasan: GPF could be caused by NULL-ptr deref or user memory accessirq event stamp: 123386
      [1033173.493678] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
      [1033173.493689] Modules linked in:
      [1033173.493697] CPU: 9 PID: 23815 Comm: trinity-c64 Not tainted 4.2.0-next-20150911-sasha-00043-g353d875-dirty #2545
      [1033173.493706] task: ffff8800630c4000 ti: ffff880063110000 task.ti: ffff880063110000
      [1033173.493823] RIP: clip_ioctl (net/atm/clip.c:320 net/atm/clip.c:689)
      [1033173.493826] RSP: 0018:ffff880063117a88  EFLAGS: 00010203
      [1033173.493828] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000000c
      [1033173.493830] RDX: 0000000000000002 RSI: ffffffffb3f10720 RDI: 0000000000000014
      [1033173.493832] RBP: ffff880063117b80 R08: ffff88047574d9a4 R09: 0000000000000000
      [1033173.493834] R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1000c622f53
      [1033173.493836] R13: ffff8800cb905500 R14: ffff8808d6da2000 R15: 00000000fffffdfd
      [1033173.493840] FS:  00007fa56b92d700(0000) GS:ffff880478000000(0000) knlGS:0000000000000000
      [1033173.493843] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [1033173.493845] CR2: 0000000000000000 CR3: 00000000630e8000 CR4: 00000000000006a0
      [1033173.493855] Stack:
      [1033173.493862]  ffffffffb0b60444 000000000000eaea 0000000041b58ab3 ffffffffb3c3ce32
      [1033173.493867]  ffffffffb0b6f3e0 ffffffffb0b60444 ffffffffb5ea2e50 1ffff1000c622f5e
      [1033173.493873]  ffff8800630c4cd8 00000000000ee09a ffffffffb3ec4888 ffffffffb5ea2de8
      [1033173.493874] Call Trace:
      [1033173.494108] do_vcc_ioctl (net/atm/ioctl.c:170)
      [1033173.494113] vcc_ioctl (net/atm/ioctl.c:189)
      [1033173.494116] svc_ioctl (net/atm/svc.c:605)
      [1033173.494200] sock_do_ioctl (net/socket.c:874)
      [1033173.494204] sock_ioctl (net/socket.c:958)
      [1033173.494244] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
      [1033173.494290] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
      [1033173.494295] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
      [1033173.494362] Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 50 09 00 00 49 8b 9e 60 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 14 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 14 09 00
      All code
      
      ========
         0:   fa                      cli
         1:   48 c1 ea 03             shr    $0x3,%rdx
         5:   80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
         9:   0f 85 50 09 00 00       jne    0x95f
         f:   49 8b 9e 60 06 00 00    mov    0x660(%r14),%rbx
        16:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
        1d:   fc ff df
        20:   48 8d 7b 14             lea    0x14(%rbx),%rdi
        24:   48 89 fa                mov    %rdi,%rdx
        27:   48 c1 ea 03             shr    $0x3,%rdx
        2b:*  0f b6 04 02             movzbl (%rdx,%rax,1),%eax               <-- trapping instruction
        2f:   48 89 fa                mov    %rdi,%rdx
        32:   83 e2 07                and    $0x7,%edx
        35:   38 d0                   cmp    %dl,%al
        37:   7f 08                   jg     0x41
        39:   84 c0                   test   %al,%al
        3b:   0f 85 14 09 00 00       jne    0x955
      
      Code starting with the faulting instruction
      ===========================================
         0:   0f b6 04 02             movzbl (%rdx,%rax,1),%eax
         4:   48 89 fa                mov    %rdi,%rdx
         7:   83 e2 07                and    $0x7,%edx
         a:   38 d0                   cmp    %dl,%al
         c:   7f 08                   jg     0x16
         e:   84 c0                   test   %al,%al
        10:   0f 85 14 09 00 00       jne    0x92a
      [1033173.494366] RIP clip_ioctl (net/atm/clip.c:320 net/atm/clip.c:689)
      [1033173.494368]  RSP <ffff880063117a88>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34f5b006
    • Florian Westphal's avatar
      ipv6: ip6_fragment: fix headroom tests and skb leak · 1d325d21
      Florian Westphal authored
      David Woodhouse reports skb_under_panic when we try to push ethernet
      header to fragmented ipv6 skbs:
      
       skbuff: skb_under_panic: text:c1277f1e len:1294 put:14 head:dec98000
       data:dec97ffc tail:0xdec9850a end:0xdec98f40 dev:br-lan
      [..]
      ip6_finish_output2+0x196/0x4da
      
      David further debugged this:
        [..] offending fragments were arriving here with skb_headroom(skb)==10.
        Which is reasonable, being the Solos ADSL card's header of 8 bytes
        followed by 2 bytes of PPP frame type.
      
      The problem is that if netfilter ipv6 defragmentation is used, skb_cow()
      in ip6_forward will only see reassembled skb.
      
      Therefore, headroom is overestimated by 8 bytes (we pulled fragment
      header) and we don't check the skbs in the frag_list either.
      
      We can't do these checks in netfilter defrag since outdev isn't known yet.
      
      Furthermore, existing tests in ip6_fragment did not consider the fragment
      or ipv6 header size when checking headroom of the fraglist skbs.
      
      While at it, also fix a skb leak on memory allocation -- ip6_fragment
      must consume the skb.
      
      I tested this e1000 driver hacked to not allocate additional headroom
      (we end up in slowpath, since LL_RESERVED_SPACE is 16).
      
      If 2 bytes of headroom are allocated, fastpath is taken (14 byte
      ethernet header was pulled, so 16 byte headroom available in all
      fragments).
      Reported-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Diagnosed-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Tested-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d325d21
    • David Woodhouse's avatar
      solos-pci: Increase headroom on received packets · ce816eb0
      David Woodhouse authored
      A comment in include/linux/skbuff.h says that:
      
       * Various parts of the networking layer expect at least 32 bytes of
       * headroom, you should not reduce this.
      
      This was demonstrated by a panic when handling fragmented IPv6 packets:
      http://marc.info/?l=linux-netdev&m=144236093519172&w=2
      
      It's not entirely clear if that comment is still valid — and if it is,
      perhaps netif_rx() ought to be enforcing it with a warning.
      
      But either way, it is rather stupid from a performance point of view
      for us to be receiving packets into a buffer which doesn't have enough
      room to prepend an Ethernet header — it means that *every* incoming
      packet is going to be need to be reallocated. So let's fix that.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce816eb0