1. 01 Dec, 2019 21 commits
    • Adrian Bunk's avatar
      mwifiex: Fix NL80211_TX_POWER_LIMITED · 49a9643b
      Adrian Bunk authored
      [ Upstream commit 65a576e2 ]
      
      NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC,
      which is the opposite of what should happen and can cause nasty
      regulatory problems.
      
      if/else converted to a switch without default to make gcc warn
      on unhandled enum values.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      49a9643b
    • Chris Wilson's avatar
      drm/i915/userptr: Try to acquire the page lock around set_page_dirty() · e80e88ef
      Chris Wilson authored
      commit 2d691aec upstream.
      
      set_page_dirty says:
      
      	For pages with a mapping this should be done under the page lock
      	for the benefit of asynchronous memory errors who prefer a
      	consistent dirty state. This rule can be broken in some special
      	cases, but should be better not to.
      
      Under those rules, it is only safe for us to use the plain set_page_dirty
      calls for shmemfs/anonymous memory. Userptr may be used with real
      mappings and so needs to use the locked version (set_page_dirty_lock).
      
      However, following a try_to_unmap() we may want to remove the userptr and
      so call put_pages(). However, try_to_unmap() acquires the page lock and
      so we must avoid recursively locking the pages ourselves -- which means
      that we cannot safely acquire the lock around set_page_dirty(). Since we
      can't be sure of the lock, we have to risk skip dirtying the page, or
      else risk calling set_page_dirty() without a lock and so risk fs
      corruption.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012
      Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
      References: cb6d7c7d ("drm/i915/userptr: Acquire the page lock around set_page_dirty()")
      References: 505a8ec7 ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"")
      References: 6dcc693b ("ext4: warn when page is dirtied without buffers")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk
      (cherry picked from commit 0d4bbe3d)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit cee7fb43)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e80e88ef
    • Chris Wilson's avatar
      drm/i915/pmu: "Frequency" is reported as accumulated cycles · a0ee03bb
      Chris Wilson authored
      commit add3eeed upstream.
      
      We report "frequencies" (actual-frequency, requested-frequency) as the
      number of accumulated cycles so that the average frequency over that
      period may be determined by the user. This means the units we report to
      the user are Mcycles (or just M), not MHz.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191109105356.5273-1-chris@chris-wilson.co.uk
      (cherry picked from commit e88866ef)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit a7d87b70)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0ee03bb
    • Evan Quan's avatar
      drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs · 8a67fbf6
      Evan Quan authored
      commit 355d991c upstream.
      
      Otherwise, the error message prompted will confuse user.
      Signed-off-by: default avatarEvan Quan <evan.quan@amd.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a67fbf6
    • Andrey Ryabinin's avatar
      mm/ksm.c: don't WARN if page is still mapped in remove_stable_node() · e8d355be
      Andrey Ryabinin authored
      commit 9a63236f upstream.
      
      It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in
      remove_stable_node() when it races with __mmput() and squeezes in
      between ksm_exit() and exit_mmap().
      
        WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150
      
        Call Trace:
         remove_all_stable_nodes+0x12b/0x330
         run_store+0x4ef/0x7b0
         kernfs_fop_write+0x200/0x420
         vfs_write+0x154/0x450
         ksys_write+0xf9/0x1d0
         do_syscall_64+0x99/0x510
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Remove the warning as there is nothing scary going on.
      
      Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com
      Fixes: cbf86cfe ("ksm: remove old stable nodes more thoroughly")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8d355be
    • Joseph Qi's avatar
      Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()" · b28da9da
      Joseph Qi authored
      commit 94b07b6f upstream.
      
      This reverts commit 56e94ea1.
      
      Commit 56e94ea1 ("fs: ocfs2: fix possible null-pointer dereferences
      in ocfs2_xa_prepare_entry()") introduces a regression that fail to
      create directory with mount option user_xattr and acl.  Actually the
      reported NULL pointer dereference case can be correctly handled by
      loc->xl_ops->xlo_add_entry(), so revert it.
      
      Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com
      Fixes: 56e94ea1 ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()")
      Signed-off-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Reported-by: default avatarThomas Voegtle <tv@lio96.de>
      Acked-by: default avatarChangwei Ge <gechangwei@live.cn>
      Cc: Jia-Ju Bai <baijiaju1990@gmail.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b28da9da
    • Laurent Vivier's avatar
      virtio_console: allocate inbufs in add_port() only if it is needed · 67380639
      Laurent Vivier authored
      commit d791cfcb upstream.
      
      When we hot unplug a virtserialport and then try to hot plug again,
      it fails:
      
      (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait
      (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
                        chardev=serial0,id=serial0,name=serial0
      (qemu) device_del serial0
      (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
                        chardev=serial0,id=serial0,name=serial0
      kernel error:
        virtio-ports vport2p2: Error allocating inbufs
      qemu error:
        virtio-serial-bus: Guest failure in adding port 2 for device \
                           virtio-serial0.0
      
      This happens because buffers for the in_vq are allocated when the port is
      added but are not released when the port is unplugged.
      
      They are only released when virtconsole is removed (see a7a69ec0)
      
      To avoid the problem and to be symmetric, we could allocate all the buffers
      in init_vqs() as they are released in remove_vqs(), but it sounds like
      a waste of memory.
      
      Rather than that, this patch changes add_port() logic to ignore ENOSPC
      error in fill_queue(), which means queue has already been filled.
      
      Fixes: a7a69ec0 ("virtio_console: free buffers after reset")
      Cc: mst@redhat.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67380639
    • Sun Ke's avatar
      nbd:fix memory leak in nbd_get_socket() · 65d153c8
      Sun Ke authored
      commit dff10bbe upstream.
      
      Before returning NULL, put the sock first.
      
      Cc: stable@vger.kernel.org
      Fixes: cf1b2326 ("nbd: verify socket is supported during setup")
      Reviewed-by: default avatarJosef Bacik <josef@toxicpanda.com>
      Reviewed-by: default avatarMike Christie <mchristi@redhat.com>
      Signed-off-by: default avatarSun Ke <sunke32@huawei.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65d153c8
    • Laura Abbott's avatar
      tools: gpio: Correctly add make dependencies for gpio_utils · 036588ec
      Laura Abbott authored
      commit 0161a94e upstream.
      
      gpio tools fail to build correctly with make parallelization:
      
      $ make -s -j24
      ld: gpio-utils.o: file not recognized: file truncated
      make[1]: *** [/home/labbott/linux_upstream/tools/build/Makefile.build:145: lsgpio-in.o] Error 1
      make: *** [Makefile:43: lsgpio-in.o] Error 2
      make: *** Waiting for unfinished jobs....
      
      This is because gpio-utils.o is used across multiple targets.
      Fix this by making gpio-utios.o a proper dependency.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      036588ec
    • Thierry Reding's avatar
      gpio: max77620: Fixup debounce delays · 7cb8ee73
      Thierry Reding authored
      commit b0391479 upstream.
      
      When converting milliseconds to microseconds in commit fffa6af9
      ("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps
      were introduced between the various ranges supported by the controller.
      Fix this by changing the start of each range to the value immediately
      following the end of the previous range. This way a debounce time of,
      say 8250 us will translate into 16 ms instead of returning an -EINVAL
      error.
      
      Typically the debounce delay is only ever set through device tree and
      specified in milliseconds, so we can never really hit this issue because
      debounce times are always a multiple of 1000 us.
      
      The only notable exception for this is drivers/mmc/host/mmc-spi.c where
      the CD GPIO is requested, which passes a 1 us debounce time. According
      to a comment preceeding that code this should actually be 1 ms (i.e.
      1000 us).
      Reported-by: default avatarPavel Machek <pavel@denx.de>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarPavel Machek <pavel@denx.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cb8ee73
    • Stefano Garzarella's avatar
      vhost/vsock: split packets to send using multiple buffers · 70d594d1
      Stefano Garzarella authored
      commit 6dbd3e66 upstream.
      
      If the packets to sent to the guest are bigger than the buffer
      available, we can split them, using multiple buffers and fixing
      the length in the packet header.
      This is safe since virtio-vsock supports only stream sockets.
      Signed-off-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70d594d1
    • Maor Gottlieb's avatar
      net/mlx5: Fix auto group size calculation · 48bc34ef
      Maor Gottlieb authored
      [ Upstream commit 97fd8da2 ]
      
      Once all the large flow groups (defined by the user when the flow table
      is created - max_num_groups) were created, then all the following new
      flow groups will have only one flow table entry, even though the flow table
      has place to larger groups.
      Fix the condition to prefer large flow group.
      
      Fixes: f0d22d18 ("net/mlx5_core: Introduce flow steering autogrouped flow table")
      Signed-off-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48bc34ef
    • Eran Ben Elisha's avatar
      net/mlxfw: Verify FSM error code translation doesn't exceed array size · 28a4cc2b
      Eran Ben Elisha authored
      [ Upstream commit 30e9e055 ]
      
      Array mlxfw_fsm_state_err_str contains value to string translation, when
      values are provided by mlxfw_dev. If value is larger than
      MLXFW_FSM_STATE_ERR_MAX, return "unknown error" as expected instead of
      reading an address than exceed array size.
      
      Fixes: 410ed13c ("Add the mlxfw module for Mellanox firmware flash process")
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28a4cc2b
    • Roi Dayan's avatar
      net/mlx5e: Fix set vf link state error flow · 7c1a5381
      Roi Dayan authored
      [ Upstream commit 75102121 ]
      
      Before this commit the ndo always returned success.
      Fix that.
      
      Fixes: 1ab2068a ("net/mlx5: Implement vports admin state backup/restore")
      Signed-off-by: default avatarRoi Dayan <roid@mellanox.com>
      Reviewed-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c1a5381
    • Martin Habets's avatar
      sfc: Only cancel the PPS workqueue if it exists · 1ff2a0f8
      Martin Habets authored
      [ Upstream commit 723eb536 ]
      
      The workqueue only exists for the primary PF. For other functions
      we hit a WARN_ON in kernel/workqueue.c.
      
      Fixes: 7c236c43 ("sfc: Add support for IEEE-1588 PTP")
      Signed-off-by: default avatarMartin Habets <mhabets@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ff2a0f8
    • Xin Long's avatar
      net: sched: ensure opts_len <= IP_TUNNEL_OPTS_MAX in act_tunnel_key · 13512a5e
      Xin Long authored
      [ Upstream commit 4f0e97d0 ]
      
      info->options_len is 'u8' type, and when opts_len with a value >
      IP_TUNNEL_OPTS_MAX, 'info->options_len = opts_len' will cast int
      to u8 and set a wrong value to info->options_len.
      
      Kernel crashed in my test when doing:
      
        # opts="0102:80:00800022"
        # for i in {1..99}; do opts="$opts,0102:80:00800022"; done
        # ip link add name geneve0 type geneve dstport 0 external
        # tc qdisc add dev eth0 ingress
        # tc filter add dev eth0 protocol ip parent ffff: \
             flower indev eth0 ip_proto udp action tunnel_key \
             set src_ip 10.0.99.192 dst_ip 10.0.99.193 \
             dst_port 6081 id 11 geneve_opts $opts \
             action mirred egress redirect dev geneve0
      
      So we should do the similar check as cls_flower does, return error
      when opts_len > IP_TUNNEL_OPTS_MAX in tunnel_key_copy_opts().
      
      Fixes: 0ed5269f ("net/sched: add tunnel option support to act_tunnel_key")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13512a5e
    • Davide Caratti's avatar
      net/sched: act_pedit: fix WARN() in the traffic path · 2ba6a4f5
      Davide Caratti authored
      [ Upstream commit f67169fe ]
      
      when configuring act_pedit rules, the number of keys is validated only on
      addition of a new entry. This is not sufficient to avoid hitting a WARN()
      in the traffic path: for example, it is possible to replace a valid entry
      with a new one having 0 extended keys, thus causing splats in dmesg like:
      
       pedit BUG: index 42
       WARNING: CPU: 2 PID: 4054 at net/sched/act_pedit.c:410 tcf_pedit_act+0xc84/0x1200 [act_pedit]
       [...]
       RIP: 0010:tcf_pedit_act+0xc84/0x1200 [act_pedit]
       Code: 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ac 00 00 00 48 8b 44 24 10 48 c7 c7 a0 c4 e4 c0 8b 70 18 e8 1c 30 95 ea <0f> 0b e9 a0 fa ff ff e8 00 03 f5 ea e9 14 f4 ff ff 48 89 58 40 e9
       RSP: 0018:ffff888077c9f320 EFLAGS: 00010286
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffac2983a2
       RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888053927bec
       RBP: dffffc0000000000 R08: ffffed100a726209 R09: ffffed100a726209
       R10: 0000000000000001 R11: ffffed100a726208 R12: ffff88804beea780
       R13: ffff888079a77400 R14: ffff88804beea780 R15: ffff888027ab2000
       FS:  00007fdeec9bd740(0000) GS:ffff888053900000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007ffdb3dfd000 CR3: 000000004adb4006 CR4: 00000000001606e0
       Call Trace:
        tcf_action_exec+0x105/0x3f0
        tcf_classify+0xf2/0x410
        __dev_queue_xmit+0xcbf/0x2ae0
        ip_finish_output2+0x711/0x1fb0
        ip_output+0x1bf/0x4b0
        ip_send_skb+0x37/0xa0
        raw_sendmsg+0x180c/0x2430
        sock_sendmsg+0xdb/0x110
        __sys_sendto+0x257/0x2b0
        __x64_sys_sendto+0xdd/0x1b0
        do_syscall_64+0xa5/0x4e0
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
       RIP: 0033:0x7fdeeb72e993
       Code: 48 8b 0d e0 74 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 0d d6 2c 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 4b cc 00 00 48 89 04 24
       RSP: 002b:00007ffdb3de8a18 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000055c81972b700 RCX: 00007fdeeb72e993
       RDX: 0000000000000040 RSI: 000055c81972b700 RDI: 0000000000000003
       RBP: 00007ffdb3dea130 R08: 000055c819728510 R09: 0000000000000010
       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
       R13: 000055c81972b6c0 R14: 000055c81972969c R15: 0000000000000080
      
      Fix this moving the check on 'nkeys' earlier in tcf_pedit_init(), so that
      attempts to install rules having 0 keys are always rejected with -EINVAL.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ba6a4f5
    • Dan Carpenter's avatar
      net: rtnetlink: prevent underflows in do_setvfinfo() · 9f6de5cf
      Dan Carpenter authored
      [ Upstream commit d658c8f56ec7b3de8051a24afb25da9ba3c388c5 ]
      
      The "ivm->vf" variable is a u32, but the problem is that a number of
      drivers cast it to an int and then forget to check for negatives.  An
      example of this is in the cxgb4 driver.
      
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
        2890  static int cxgb4_mgmt_get_vf_config(struct net_device *dev,
        2891                                      int vf, struct ifla_vf_info *ivi)
                                                  ^^^^^^
        2892  {
        2893          struct port_info *pi = netdev_priv(dev);
        2894          struct adapter *adap = pi->adapter;
        2895          struct vf_info *vfinfo;
        2896
        2897          if (vf >= adap->num_vfs)
                          ^^^^^^^^^^^^^^^^^^^
        2898                  return -EINVAL;
        2899          vfinfo = &adap->vfinfo[vf];
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
      
      There are 48 functions affected.
      
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:8435 hclge_set_vf_vlan_filter() warn: can 'vfid' underflow 's32min-2147483646'
      drivers/net/ethernet/freescale/enetc/enetc_pf.c:377 enetc_pf_set_vf_mac() warn: can 'vf' underflow 's32min-2147483646'
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2899 cxgb4_mgmt_get_vf_config() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2960 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3019 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3038 cxgb4_mgmt_set_vf_vlan() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3086 cxgb4_mgmt_set_vf_link_state() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/chelsio/cxgb/cxgb2.c:791 get_eeprom() warn: can 'i' underflow 's32min-(-4),0,4-s32max'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:82 bnxt_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:164 bnxt_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:186 bnxt_get_vf_config() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:228 bnxt_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:264 bnxt_set_vf_vlan() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:293 bnxt_set_vf_bw() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:333 bnxt_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2281 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2285 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2286 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2292 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
      drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2297 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63'
      drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1832 qlcnic_sriov_set_vf_mac() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1864 qlcnic_sriov_set_vf_tx_rate() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1937 qlcnic_sriov_set_vf_vlan() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2005 qlcnic_sriov_get_vf_config() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2036 qlcnic_sriov_set_vf_spoofchk() warn: can 'vf' underflow 's32min-254'
      drivers/net/ethernet/emulex/benet/be_main.c:1914 be_get_vf_config() warn: can 'vf' underflow 's32min-65534'
      drivers/net/ethernet/emulex/benet/be_main.c:1915 be_get_vf_config() warn: can 'vf' underflow 's32min-65534'
      drivers/net/ethernet/emulex/benet/be_main.c:1922 be_set_vf_tvt() warn: can 'vf' underflow 's32min-65534'
      drivers/net/ethernet/emulex/benet/be_main.c:1951 be_clear_vf_tvt() warn: can 'vf' underflow 's32min-65534'
      drivers/net/ethernet/emulex/benet/be_main.c:2063 be_set_vf_tx_rate() warn: can 'vf' underflow 's32min-65534'
      drivers/net/ethernet/emulex/benet/be_main.c:2091 be_set_vf_link_state() warn: can 'vf' underflow 's32min-65534'
      drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:2609 ice_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3050 ice_get_vf_cfg() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3103 ice_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3181 ice_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3237 ice_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3286 ice_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3919 i40e_validate_vf() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3957 i40e_ndo_set_vf_mac() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4104 i40e_ndo_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4263 i40e_ndo_set_vf_bw() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4309 i40e_ndo_get_vf_config() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4371 i40e_ndo_set_vf_link_state() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646'
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4504 i40e_ndo_set_vf_trust() warn: can 'vf_id' underflow 's32min-2147483646'
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f6de5cf
    • Tariq Toukan's avatar
      net/mlx4_en: Fix wrong limitation for number of TX rings · ebcb0840
      Tariq Toukan authored
      [ Upstream commit 2744bf42 ]
      
      XDP_TX rings should not be limited by max_num_tx_rings_p_up.
      To make sure total number of TX rings never exceed MAX_TX_RINGS,
      add similar check in mlx4_en_alloc_tx_queue_per_tc(), where
      a new value is assigned for num_up.
      
      Fixes: 7e1dc5e9 ("net/mlx4_en: Limit the number of TX rings")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebcb0840
    • Luigi Rizzo's avatar
      net/mlx4_en: fix mlx4 ethtool -N insertion · 5408138d
      Luigi Rizzo authored
      [ Upstream commit 34e59836 ]
      
      ethtool expects ETHTOOL_GRXCLSRLALL to set ethtool_rxnfc->data with the
      total number of entries in the rx classifier table.  Surprisingly, mlx4
      is missing this part (in principle ethtool could still move forward and
      try the insert).
      
      Tested: compiled and run command:
      	phh13:~# ethtool -N eth1 flow-type udp4  queue 4
      	Added rule with ID 255
      Signed-off-by: default avatarLuigi Rizzo <lrizzo@google.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5408138d
    • Petr Machata's avatar
      mlxsw: spectrum_router: Fix determining underlay for a GRE tunnel · baa888ca
      Petr Machata authored
      [ Upstream commit 1fc16577 ]
      
      The helper mlxsw_sp_ipip_dev_ul_tb_id() determines the underlay VRF of a
      GRE tunnel. For a tunnel without a bound device, it uses the same VRF that
      the tunnel is in. However in Linux, a GRE tunnel without a bound device
      uses the main VRF as the underlay. Fix the function accordingly.
      
      mlxsw further assumed that moving a tunnel to a different VRF could cause
      conflict in local tunnel endpoint address, which cannot be offloaded.
      However, the only way that an underlay could be changed by moving the
      tunnel device itself is if the tunnel device does not have a bound device.
      But in that case the underlay is always the main VRF, so there is no
      opportunity to introduce a conflict by moving such device. Thus this check
      constitutes a dead code, and can be removed, which do.
      
      Fixes: 6ddb7426 ("mlxsw: spectrum_router: Introduce loopback RIFs")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      baa888ca
  2. 24 Nov, 2019 19 commits