1. 23 Sep, 2015 1 commit
    • Russell King's avatar
      net: dsa: actually force the speed on the CPU port · 53adc9e8
      Russell King authored
      Commit 54d792f2 ("net: dsa: Centralise global and port setup
      code into mv88e6xxx.") merged in the 4.2 merge window broke the link
      speed forcing for the CPU port of Marvell DSA switches.  The original
      code was:
      
              /* MAC Forcing register: don't force link, speed, duplex
               * or flow control state to any particular values on physical
               * ports, but force the CPU port and all DSA ports to 1000 Mb/s
               * full duplex.
               */
              if (dsa_is_cpu_port(ds, p) || ds->dsa_port_mask & (1 << p))
                      REG_WRITE(addr, 0x01, 0x003e);
              else
                      REG_WRITE(addr, 0x01, 0x0003);
      
      but the new code does a read-modify-write:
      
                      reg = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_PCS_CTRL);
                      if (dsa_is_cpu_port(ds, port) ||
                          ds->dsa_port_mask & (1 << port)) {
                              reg |= PORT_PCS_CTRL_FORCE_LINK |
                                      PORT_PCS_CTRL_LINK_UP |
                                      PORT_PCS_CTRL_DUPLEX_FULL |
                                      PORT_PCS_CTRL_FORCE_DUPLEX;
                              if (mv88e6xxx_6065_family(ds))
                                      reg |= PORT_PCS_CTRL_100;
                              else
                                      reg |= PORT_PCS_CTRL_1000;
      
      The link speed in the PCS control register is a two bit field.  Forcing
      the link speed in this way doesn't ensure that the bit field is set to
      the correct value - on the hardware I have here, the speed bitfield
      remains set to 0x03, resulting in the speed not being forced to gigabit.
      
      We must clear both bits before forcing the link speed.
      
      Fixes: 54d792f2 ("net: dsa: Centralise global and port setup code into mv88e6xxx.")
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53adc9e8
  2. 22 Sep, 2015 1 commit
  3. 21 Sep, 2015 25 commits
  4. 18 Sep, 2015 13 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