1. 25 Jan, 2018 24 commits
  2. 24 Jan, 2018 16 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · f1654953
      Linus Torvalds authored
      Pull sparc bugfix from David Miller:
       "Sparc Makefile typo fix"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64
      f1654953
    • Ivan Mikhaylov's avatar
      net/ibm/emac: wrong bit is used for STA control register write · 624ca9c3
      Ivan Mikhaylov authored
      STA control register has areas of mode and opcodes for opeations. 18 bit is
      using for mode selection, where 0 is old MIO/MDIO access method and 1 is
      indirect access mode. 19-20 bits are using for setting up read/write
      operation(STA opcodes). In current state 'read' is set into old MIO/MDIO mode
      with 19 bit and write operation is set into 18 bit which is mode selection,
      not a write operation. To correlate write with read we set it into 20 bit.
      All those bit operations are MSB 0 based.
      Signed-off-by: default avatarIvan Mikhaylov <ivan@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      624ca9c3
    • Ivan Mikhaylov's avatar
      net/ibm/emac: add 8192 rx/tx fifo size · 45d6e545
      Ivan Mikhaylov authored
      emac4syn chips has availability to use 8192 rx/tx fifo buffer sizes,
      in current state if we set it up in dts 8192 as example, we will get
      only 2048 which may impact on network speed.
      Signed-off-by: default avatarIvan Mikhaylov <ivan@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45d6e545
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · be1b6e8b
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      100GbE Intel Wired LAN Driver Updates 2018-01-24
      
      This series contains updates to fm10k only.
      
      Alex fixes MACVLAN offload for fm10k, where we were not seeing unicast
      packets being received because we did not correctly configure the
      default VLAN ID for the port and defaulting to 0.
      
      Jake cleans up unnecessary parenthesis in a couple of "if" statements.
      Fixed the driver to stop adding VLAN 0 into the VLAN table, since it
      would cause the VLAN table to be inconsistent between the PF and VF.
      Also fixed an issue where we were assuming that VLAN 1 is enabled when
      the default VLAN ID is not set, so resolve by not requesting any filters
      for the default_vid if it has not yet been assigned.
      
      Ngai fixes an issue which was generating a dmesg regarding unbale to
      kill a particular VLAN ID for the device.  This is due to
      ndo_vlan_rx_kill_vid() exits with an error and the handler for this ndo
      is fm10k_update_vid() which exits prematurely under PF VLAN management.
      So to resolve, we must check the VLAN update action type before exiting
      fm10k_update_vid(), and act appropriately based on the action type.
      Also corrected code comment typos.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be1b6e8b
    • Ngai-Mint Kwan's avatar
      fm10k: clarify action when updating the VLAN table · e0752a68
      Ngai-Mint Kwan authored
      Clarify the comment for when entering promiscuous mode that we update
      the VLAN table. Add a comment distinguishing the case where we're
      exiting promiscuous mode and need to clear the entire VLAN table.
      Signed-off-by: default avatarNgai-Mint Kwan <ngai-mint.kwan@intel.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@gmail.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e0752a68
    • Ngai-Mint Kwan's avatar
    • Jacob Keller's avatar
      fm10k: don't assume VLAN 1 is enabled · 74d2950c
      Jacob Keller authored
      Since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues",
      2016-03-03) we've incorrectly assumed that VLAN 1 is enabled when the
      default VID is not set.
      
      This occurs because we check the default_vid and if it's zero, start
      several loops over the active_vlans bitmask at 1, instead of checking to
      ensure that that bit is active.
      
      This happened because of commit d9ff3ee8efe9 ("fm10k: Add support for
      VLAN 0 w/o default VLAN", 2014-08-07) which mistakenly assumed that we
      should send requests for MAC and VLAN filters with VLAN 0 when the
      default_vid isn't set.
      
      However, the switch generally considers this an invalid configuration,
      so the only time we'd have a default_vid of 0 is when the switch is
      down.
      
      Instead, lets just not request any filters for the default_vid if it's
      not yet been assigned.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      74d2950c
    • Jacob Keller's avatar
      fm10k: stop adding VLAN 0 to the VLAN table · 8c2c5039
      Jacob Keller authored
      Currently, when the driver loads, it sends a request to add VLAN 0 to the
      VLAN table. For the PF, this is honored, and VLAN 0 is indeed set. For
      the VF, this request is silently converted into a request for the
      default VLAN as defined by either the switch vid or the PF vid.
      
      This results in the odd behavior that the VLAN table doesn't appear
      consistent between the PF and the VF.
      
      Furthermore, setting a MAC filter with VLAN 0 is generally considered an
      invalid configuration by the switch, and since commit 856dfd69e84f
      ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've had code
      which prevents us from ever sending such a request.
      
      Since there's not really a good reason to keep VLAN 0 in the VLAN table,
      stop requesting it in fm10k_restore_rx_state().
      
      This might seem to indicate that we would no longer properly configure
      the MAC and VLAN tables for the default vid. However, due to the way
      that fm10k_find_next_vlan() behaves, it will always return the
      default_vid as enabled.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8c2c5039
    • Ngai-Mint Kwan's avatar
      fm10k: fix "failed to kill vid" message for VF · cf315ea5
      Ngai-Mint Kwan authored
      When a VF is under PF VLAN assignment:
      
      ip link set <pf> vf <#> vlan <vid>
      
      This will remove all previous entries in the VLAN table including those
      generated by VLAN interfaces created on the VF. The issue arises when
      the VF is under PF VLAN assignment and one or more of these VLAN
      interfaces of the VF are deleted. When deleting these VLAN interfaces,
      the following message will be generated in "dmesg":
      
      failed to kill vid 0081/<vid> for device <vf>
      
      This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error.
      The handler for this ndo is "fm10k_update_vid". Any calls to this
      function while under PF VLAN management will exit prematurely and, thus,
      it will generate the failure message.
      
      Additionally, since "fm10k_update_vid" exits prematurely, none of the
      VLAN update is performed. So, even though the actual VLAN interfaces of
      the VF will be deleted, the active_vlans bitmask is not cleared. When
      the VF is no longer under PF VLAN assignment, the driver mistakenly
      restores the previous entries of the VLAN table based on an
      unsynchronized list of active VLANs.
      
      The solution to this issue involves checking the VLAN update action type
      before exiting "fm10k_update_vid". If the VLAN update action type is to
      "add", this action will not be permitted while the VF is under PF VLAN
      assignment and the VLAN update is abandoned like before.
      
      However, if the VLAN update action type is to "kill", then we need to
      also clear the active_vlans bitmask. However, we don't need to actually
      queue any messages to the PF, because the MAC and VLAN tables have
      already been cleared, and the PF would silently ignore these requests
      anyways.
      Signed-off-by: default avatarNgai-Mint Kwan <ngai-mint.kwan@intel.com>
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cf315ea5
    • Jacob Keller's avatar
      fm10k: cleanup unnecessary parenthesis in fm10k_iov.c · c8eeacb3
      Jacob Keller authored
      This fixes a few warnings found by checkpatch.pl --strict
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c8eeacb3
    • Wei Yongjun's avatar
      cxgb4: make symbol pedits static · 1d174e95
      Wei Yongjun authored
      Fixes the following sparse warning:
      
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c:46:27: warning:
       symbol 'pedits' was not declared. Should it be static?
      
      Fixes: 27ece1f3 ("cxgb4: add tc flower support for ETH-DMAC rewrite")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d174e95
    • Jason Wang's avatar
      vhost: do not try to access device IOTLB when not initialized · 6f3180af
      Jason Wang authored
      The code will try to access dev->iotlb when processing
      VHOST_IOTLB_INVALIDATE even if it was not initialized which may lead
      to NULL pointer dereference. Fixes this by check dev->iotlb before.
      
      Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f3180af
    • Jason Wang's avatar
      vhost: use mutex_lock_nested() in vhost_dev_lock_vqs() · e9cb4239
      Jason Wang authored
      We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
      hold mutexes of all virtqueues. This may confuse lockdep to report a
      possible deadlock because of trying to hold locks belong to same
      class. Switch to use mutex_lock_nested() to avoid false positive.
      
      Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
      Reported-by: syzbot+dbb7c1161485e61b0241@syzkaller.appspotmail.com
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e9cb4239
    • William Tu's avatar
      net: erspan: fix use-after-free · b423d13c
      William Tu authored
      When building the erspan header for either v1 or v2, the eth_hdr()
      does not point to the right inner packet's eth_hdr,
      causing kasan report use-after-free and slab-out-of-bouds read.
      
      The patch fixes the following syzkaller issues:
      [1] BUG: KASAN: slab-out-of-bounds in erspan_xmit+0x22d4/0x2430 net/ipv4/ip_gre.c:735
      [2] BUG: KASAN: slab-out-of-bounds in erspan_build_header+0x3bf/0x3d0 net/ipv4/ip_gre.c:698
      [3] BUG: KASAN: use-after-free in erspan_xmit+0x22d4/0x2430 net/ipv4/ip_gre.c:735
      [4] BUG: KASAN: use-after-free in erspan_build_header+0x3bf/0x3d0 net/ipv4/ip_gre.c:698
      
      [2] CPU: 0 PID: 3654 Comm: syzkaller377964 Not tainted 4.15.0-rc9+ #185
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351 [inline]
       kasan_report+0x25b/0x340 mm/kasan/report.c:409
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:440
       erspan_build_header+0x3bf/0x3d0 net/ipv4/ip_gre.c:698
       erspan_xmit+0x3b8/0x13b0 net/ipv4/ip_gre.c:740
       __netdev_start_xmit include/linux/netdevice.h:4042 [inline]
       netdev_start_xmit include/linux/netdevice.h:4051 [inline]
       packet_direct_xmit+0x315/0x6b0 net/packet/af_packet.c:266
       packet_snd net/packet/af_packet.c:2943 [inline]
       packet_sendmsg+0x3aed/0x60b0 net/packet/af_packet.c:2968
       sock_sendmsg_nosec net/socket.c:638 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:648
       SYSC_sendto+0x361/0x5c0 net/socket.c:1729
       SyS_sendto+0x40/0x50 net/socket.c:1697
       do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
       do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
       entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
      RIP: 0023:0xf7fcfc79
      RSP: 002b:00000000ffc6976c EFLAGS: 00000286 ORIG_RAX: 0000000000000171
      RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000020011000
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020008000
      RBP: 000000000000001c R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: f551c91d ("net: erspan: introduce erspan v2 for ip_gre")
      Fixes: 84e54fe0 ("gre: introduce native tunnel support for ERSPAN")
      Reported-by: syzbot+9723f2d288e49b492cf0@syzkaller.appspotmail.com
      Reported-by: syzbot+f0ddeb2b032a8e1d9098@syzkaller.appspotmail.com
      Reported-by: syzbot+f14b3703cd8d7670203f@syzkaller.appspotmail.com
      Reported-by: syzbot+eefa384efad8d7997f20@syzkaller.appspotmail.com
      Signed-off-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b423d13c
    • Jakub Kicinski's avatar
      i40e: flower: check if TC offload is enabled on a netdev · b7051cb8
      Jakub Kicinski authored
      Since TC block changes drivers are required to check if
      the TC hw offload flag is set on the interface themselves.
      
      Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower")
      Fixes: 44ae12a7 ("net: sched: move the can_offload check from binding phase to rule insertion phase")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarAmritha Nambiar <amritha.nambiar@intel.com>
      Acked-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7051cb8
    • Corentin Labbe's avatar
      sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64 · aebb48f5
      Corentin Labbe authored
      This patch fixes the typo CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64
      
      Fixes: 81658ad0 ("sparc64: Add CAMELLIA driver making use of the new camellia opcodes.")
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aebb48f5