1. 01 Nov, 2020 40 commits
    • Jason Gunthorpe's avatar
      RDMA/addr: Fix race with netevent_callback()/rdma_addr_cancel() · 5868beda
      Jason Gunthorpe authored
      commit 2ee9bf346fbfd1dad0933b9eb3a4c2c0979b633e upstream.
      This three thread race can result in the work being run once the callback
      becomes NULL:
             CPU1                 CPU2                   CPU3
                           process_one_req()       rdma_addr_cancel()
      		     req->callback = NULL
      		       if (!list_empty(&req->list))
                               // Skipped!
      		         // cancel_delayed_work(&req->work);
      		    process_one_req() // again
      		     req->callback() // BOOM
      The solution is to always cancel the work once it is completed so any
      in between set_timeout() does not result in it running again.
      Cc: stable@vger.kernel.org
      Fixes: 44e75052 ("RDMA/rdma_cm: Make rdma_addr_cancel into a fence")
      Link: https://lore.kernel.org/r/20200930072007.1009692-1-leon@kernel.org
      Reported-by: default avatarDan Aloni <dan@kernelim.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Frederic Barrat's avatar
      cxl: Rework error message for incompatible slots · a8069b80
      Frederic Barrat authored
      commit 40ac790d99c6dd16b367d5c2339e446a5f1b0593 upstream.
      Improve the error message shown if a capi adapter is plugged on a
      capi-incompatible slot directly under the PHB (no intermediate switch).
      Fixes: 56328743
       ("cxl: Add support for POWER9 DD2")
      Cc: stable@vger.kernel.org # 4.14+
      Signed-off-by: default avatarFrederic Barrat <fbarrat@linux.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <ajd@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200407115601.25453-1-fbarrat@linux.ibm.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jia-Ju Bai's avatar
      p54: avoid accessing the data mapped to streaming DMA · 9f9dc704
      Jia-Ju Bai authored
      commit 478762855b5ae9f68fa6ead1edf7abada70fcd5f upstream.
      In p54p_tx(), skb->data is mapped to streaming DMA on line 337:
        mapping = pci_map_single(..., skb->data, ...);
      Then skb->data is accessed on line 349:
        desc->device_addr = ((struct p54_hdr *)skb->data)->req_id;
      This access may cause data inconsistency between CPU cache and hardware.
      To fix this problem, ((struct p54_hdr *)skb->data)->req_id is stored in
      a local variable before DMA mapping, and then the driver accesses this
      local variable instead of skb->data.
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJia-Ju Bai <baijiaju@tsinghua.edu.cn>
      Acked-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200802132949.26788-1-baijiaju@tsinghua.edu.cn
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Roberto Sassu's avatar
      evm: Check size of security.evm before using it · 9f4ef6a9
      Roberto Sassu authored
      commit 455b6c9112eff8d249e32ba165742085678a80a4 upstream.
      This patch checks the size for the EVM_IMA_XATTR_DIGSIG and
      EVM_XATTR_PORTABLE_DIGSIG types to ensure that the algorithm is read from
      the buffer returned by vfs_getxattr_alloc().
      Cc: stable@vger.kernel.org # 4.19.x
      Fixes: 5feeb611
       ("evm: Allow non-SHA1 digital signatures")
      Signed-off-by: default avatarRoberto Sassu <roberto.sassu@huawei.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Song Liu's avatar
      bpf: Fix comment for helper bpf_current_task_under_cgroup() · a42b1273
      Song Liu authored
      commit 1aef5b4391f0c75c0a1523706a7b0311846ee12f upstream.
      This should be "current" not "skb".
      Fixes: c6b5fb86
       ("bpf: add documentation for eBPF helpers (42-50)")
      Signed-off-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/bpf/20200910203314.70018-1-songliubraving@fb.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Miklos Szeredi's avatar
      fuse: fix page dereference after free · 07d54b8d
      Miklos Szeredi authored
      commit d78092e4937de9ce55edcb4ee4c5e3c707be0190 upstream.
      After unlock_request() pages from the ap->pages[] array may be put (e.g. by
      aborting the connection) and the pages can be freed.
      Prevent use after free by grabbing a reference to the page before calling
      The original patch was created by Pradeep P V K.
      Reported-by: default avatarPradeep P V K <ppvk@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Pali Rohár's avatar
      ata: ahci: mvebu: Make SATA PHY optional for Armada 3720 · 78453a7d
      Pali Rohár authored
      commit 45aefe3d2251e4e229d7662052739f96ad1d08d9 upstream.
      Older ATF does not provide SMC call for SATA phy power on functionality and
      therefore initialization of ahci_mvebu is failing when older version of ATF
      is using. In this case phy_power_on() function returns -EOPNOTSUPP.
      This patch adds a new hflag AHCI_HFLAG_IGN_NOTSUPP_POWER_ON which cause
      that ahci_platform_enable_phys() would ignore -EOPNOTSUPP errors from
      phy_power_on() call.
      It fixes initialization of ahci_mvebu on Espressobin boards where is older
      Marvell's Arm Trusted Firmware without SMC call for SATA phy power.
      This is regression introduced in commit 8e18c8e5 ("arm64: dts: marvell:
      armada-3720-espressobin: declare SATA PHY property") where SATA phy was
      defined and therefore ahci_platform_enable_phys() on Espressobin started
      Fixes: 8e18c8e5
       ("arm64: dts: marvell: armada-3720-espressobin: declare SATA PHY property")
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Tested-by: default avatarTomasz Maciej Nowak <tmn505@gmail.com>
      Cc: <stable@vger.kernel.org> # 5.1+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Pali Rohár's avatar
      PCI: aardvark: Fix initialization with old Marvell's Arm Trusted Firmware · 4752a131
      Pali Rohár authored
      commit b0c6ae0f8948a2be6bf4e8b4bbab9ca1343289b6 upstream.
      Old ATF automatically power on pcie phy and does not provide SMC call for
      phy power on functionality which leads to aardvark initialization failure:
      [    0.330134] mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try updating your firmware
      [    0.338846] phy phy-d0018300.phy.1: phy poweron failed --> -95
      [    0.344753] advk-pcie d0070000.pcie: Failed to initialize PHY (-95)
      [    0.351160] advk-pcie: probe of d0070000.pcie failed with error -95
      This patch fixes above failure by ignoring 'not supported' error in
      aardvark driver. In this case it is expected that phy is already power on.
      Tested-by: default avatarTomasz Maciej Nowak <tmn505@gmail.com>
      Link: https://lore.kernel.org/r/20200902144344.16684-3-pali@kernel.org
      Fixes: 36669701
       ("PCI: aardvark: Add PHY support")
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Cc: <stable@vger.kernel.org> # 5.8+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Juergen Gross's avatar
      x86/xen: disable Firmware First mode for correctable memory errors · b9cc04b0
      Juergen Gross authored
      commit d759af38572f97321112a0852353613d18126038 upstream.
      When running as Xen dom0 the kernel isn't responsible for selecting the
      error handling mode, this should be handled by the hypervisor.
      So disable setting FF mode when running as Xen pv guest. Not doing so
      might result in boot splats like:
      [    7.509696] HEST: Enabling Firmware First mode for corrected errors.
      [    7.510382] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 2.
      [    7.510383] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 3.
      [    7.510384] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 4.
      [    7.510384] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 5.
      [    7.510385] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 6.
      [    7.510386] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 7.
      [    7.510386] mce: [Firmware Bug]: Ignoring request to disable invalid MCA bank 8.
      Reason is that the HEST ACPI table contains the real number of MCA
      banks, while the hypervisor is emulating only 2 banks for guests.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Link: https://lore.kernel.org/r/20200925140751.31381-1-jgross@suse.com
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Thomas Gleixner's avatar
      x86/traps: Fix #DE Oops message regression · ea4e8cf5
      Thomas Gleixner authored
      commit 5f1ec1fd32252af5130dac23b5542e8e66fe0bcb upstream.
      The conversion of #DE to the idtentry mechanism introduced a change in the
      Ooops message which confuses tools which parse crash information in dmesg.
      Remove the underscore from 'divide_error' to restore previous behaviour.
      Fixes: 9d06c402
       ("x86/entry: Convert Divide Error to IDTENTRY")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/CACT4Y+bTZFkuZd7+bPArowOv-7Die+WZpfOWnEO_Wgs3U59+oA@mail.gmail.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kim Phillips's avatar
      arch/x86/amd/ibs: Fix re-arming IBS Fetch · 085f6be2
      Kim Phillips authored
      commit 221bfce5ebbdf72ff08b3bf2510ae81058ee568b upstream.
      Stephane Eranian found a bug in that IBS' current Fetch counter was not
      being reset when the driver would write the new value to clear it along
      with the enable bit set, and found that adding an MSR write that would
      first disable IBS Fetch would make IBS Fetch reset its current count.
      Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12,
      2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when
      IbsFetchEn is changed from 0 to 1."
      Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch,
      so the driver properly resets the internal counter to 0 and IBS
      Fetch starts counting again.
      A family 15h machine tested does not have this problem, and the extra
      wrmsr is also not needed on Family 19h, so only do the extra wrmsr on
      families 16h through 18h.
      Reported-by: default avatarStephane Eranian <stephane.eranian@google.com>
      Signed-off-by: default avatarKim Phillips <kim.phillips@amd.com>
      [peterz: optimized]
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Gao Xiang's avatar
      erofs: avoid duplicated permission check for "trusted." xattrs · b4818cfc
      Gao Xiang authored
      commit d578b46db69d125a654f509bdc9091d84e924dc8 upstream.
      Don't recheck it since xattr_permission() already
      checks CAP_SYS_ADMIN capability.
      Just follow 5d3ce4f7
       ("f2fs: avoid duplicated permission check for "trusted." xattrs")
      Reported-by: default avatarHongyu Jin <hongyu.jin@unisoc.com>
      [ Gao Xiang: since it could cause some complex Android overlay
        permission issue as well on android-5.4+, it'd be better to
        backport to 5.4+ rather than pure cleanup on mainline. ]
      Cc: <stable@vger.kernel.org> # 5.4+
      Link: https://lore.kernel.org/r/20200811070020.6339-1-hsiangkao@redhat.com
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarGao Xiang <hsiangkao@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Leon Romanovsky's avatar
      net: protect tcf_block_unbind with block lock · 3a9e7db9
      Leon Romanovsky authored
      [ Upstream commit d6535dca28859d8d9ef80894eb287b2ac35a32e8 ]
      The tcf_block_unbind() expects that the caller will take block->cb_lock
      before calling it, however the code took RTNL lock and dropped cb_lock
      instead. This causes to the following kernel panic.
       WARNING: CPU: 1 PID: 13524 at net/sched/cls_api.c:1488 tcf_block_unbind+0x2db/0x420
       Modules linked in: mlx5_ib mlx5_core mlxfw ptp pps_core act_mirred act_tunnel_key cls_flower vxlan ip6_udp_tunnel udp_tunnel dummy sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad ib_ipoib rdma_cm iw_cm ib_cm ib_uverbs ib_core overlay [last unloaded: mlxfw]
       CPU: 1 PID: 13524 Comm: test-ecmp-add-v Tainted: G        W         5.9.0+ #1
       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
       RIP: 0010:tcf_block_unbind+0x2db/0x420
       Code: ff 48 83 c4 40 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8d bc 24 30 01 00 00 be ff ff ff ff e8 7d 7f 70 00 85 c0 0f 85 7b fd ff ff <0f> 0b e9 74 fd ff ff 48 c7 c7 dc 6a 24 84 e8 02 ec fe fe e9 55 fd
       RSP: 0018:ffff888117d17968 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: ffff88812f713c00 RCX: 1ffffffff0848d5b
       RDX: 0000000000000001 RSI: ffff88814fbc8130 RDI: ffff888107f2b878
       RBP: 1ffff11022fa2f3f R08: 0000000000000000 R09: ffffffff84115a87
       R10: fffffbfff0822b50 R11: ffff888107f2b898 R12: ffff88814fbc8000
       R13: ffff88812f713c10 R14: ffff888117d17a38 R15: ffff88814fbc80c0
       FS:  00007f6593d36740(0000) GS:ffff8882a4f00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00005607a00758f8 CR3: 0000000131aea006 CR4: 0000000000170ea0
       Call Trace:
        ? tcf_block_unbind+0x420/0x420
        ? __mutex_unlock_slowpath+0xe7/0x610
        ? mlx5e_restore_tunnel+0xdf0/0xdf0 [mlx5_core]
        ? mlx5e_restore_tunnel+0xdf0/0xdf0 [mlx5_core]
        ? flow_indr_block_cb_alloc+0x3c0/0x3c0
        ? mlx5_db_free+0x37c/0x4b0 [mlx5_core]
        mlx5e_cleanup_rep_tx+0x8b/0xc0 [mlx5_core]
        mlx5e_detach_netdev+0xe5/0x120 [mlx5_core]
        mlx5e_vport_rep_unload+0x155/0x260 [mlx5_core]
        esw_offloads_disable+0x227/0x2b0 [mlx5_core]
        mlx5_eswitch_disable_locked.cold+0x38e/0x699 [mlx5_core]
        mlx5_eswitch_disable+0x94/0xf0 [mlx5_core]
        mlx5_device_disable_sriov+0x183/0x1f0 [mlx5_core]
        mlx5_core_sriov_configure+0xfd/0x230 [mlx5_core]
        ? sriov_drivers_autoprobe_store+0x110/0x110
        ? sysfs_file_ops+0x170/0x170
        ? sysfs_file_ops+0x117/0x170
        ? sysfs_file_ops+0x170/0x170
        ? rcu_read_lock_any_held+0x6e/0x90
        ? __x64_sys_read+0xb0/0xb0
        ? lockdep_hardirqs_on_prepare+0x273/0x3f0
        ? syscall_enter_from_user_mode+0x1d/0x50
       ---[ end trace bfdd028ada702879 ]---
      Fixes: 0fdcf78d
       ("net: use flow_indr_dev_setup_offload()")
      Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Link: https://lore.kernel.org/r/20201026123327.1141066-1-leon@kernel.org
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Tung Nguyen's avatar
      tipc: fix memory leak caused by tipc_buf_append() · af5d5b8a
      Tung Nguyen authored
      [ Upstream commit ceb1eb2fb609c88363e06618b8d4bbf7815a4e03 ]
      Commit ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
      replaced skb_unshare() with skb_copy() to not reduce the data reference
      counter of the original skb intentionally. This is not the correct
      way to handle the cloned skb because it causes memory leak in 2
      following cases:
       1/ Sending multicast messages via broadcast link
        The original skb list is cloned to the local skb list for local
        destination. After that, the data reference counter of each skb
        in the original list has the value of 2. This causes each skb not
        to be freed after receiving ACK:
         /* release skb */
         __skb_unlink(skb, &l->transmq);
         kfree_skb(skb); <-- memory exists after being freed
       2/ Sending multicast messages via replicast link
        Similar to the above case, each skb cannot be freed after purging
        the skb list:
         __skb_queue_purge(pkts); <-- memory exists after being freed
      This commit fixes this issue by using skb_unshare() instead. Besides,
      to avoid use-after-free error reported by KASAN, the pointer to the
      fragment is set to NULL before calling skb_unshare() to make sure that
      the original skb is not freed after freeing the fragment 2 times in
      case skb_unshare() returns NULL.
      Fixes: ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Reported-by: default avatarThang Hoang Ngo <thang.h.ngo@dektech.com.au>
      Signed-off-by: default avatarTung Nguyen <tung.q.nguyen@dektech.com.au>
      Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Link: https://lore.kernel.org/r/20201027032403.1823-1-tung.q.nguyen@dektech.com.au
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Arjun Roy's avatar
      tcp: Prevent low rmem stalls with SO_RCVLOWAT. · 519366f6
      Arjun Roy authored
      [ Upstream commit 435ccfa894e35e3d4a1799e6ac030e48a7b69ef5 ]
      With SO_RCVLOWAT, under memory pressure,
      it is possible to enter a state where:
      1. We have not received enough bytes to satisfy SO_RCVLOWAT.
      2. We have not entered buffer pressure (see tcp_rmem_pressure()).
      3. But, we do not have enough buffer space to accept more packets.
      In this case, we advertise 0 rwnd (due to #3) but the application does
      not drain the receive queue (no wakeup because of #1 and #2) so the
      flow stalls.
      Modify the heuristic for SO_RCVLOWAT so that, if we are advertising
      rwnd<=rcv_mss, force a wakeup to prevent a stall.
      Without this patch, setting tcp_rmem to 6143 and disabling TCP
      autotune causes a stalled flow. With this patch, no stall occurs. This
      is with RPC-style traffic with large messages.
      Fixes: 03f45c88
       ("tcp: avoid extra wakeups for SO_RCVLOWAT users")
      Signed-off-by: default avatarArjun Roy <arjunroy@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20201023184709.217614-1-arjunroy.kdev@gmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Andrew Gabbasov's avatar
      ravb: Fix bit fields checking in ravb_hwtstamp_get() · 9ceecfdb
      Andrew Gabbasov authored
      [ Upstream commit 68b9f0865b1ef545da180c57d54b82c94cb464a4 ]
      In the function ravb_hwtstamp_get() in ravb_main.c with the existing
      if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_V2_L2_EVENT)
      	config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT;
      else if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_ALL)
      	config.rx_filter = HWTSTAMP_FILTER_ALL;
      if the test on RAVB_RXTSTAMP_TYPE_ALL should be true,
      it will never be reached.
      This issue can be verified with 'hwtstamp_config' testing program
      (tools/testing/selftests/net/hwtstamp_config.c). Setting filter type
      to ALL and subsequent retrieving it gives incorrect value:
      $ hwtstamp_config eth0 OFF ALL
      flags = 0
      tx_type = OFF
      rx_filter = ALL
      $ hwtstamp_config eth0
      flags = 0
      tx_type = OFF
      rx_filter = PTP_V2_L2_EVENT
      Correct this by converting if-else's to switch.
      Fixes: c156633f ("Renesas Ethernet AVB driver proper")
      Reported-by: ...
    • Heiner Kallweit's avatar
      r8169: fix issue with forced threading in combination with shared interrupts · fa67cc69
      Heiner Kallweit authored
      [ Upstream commit 2734a24e6e5d18522fbf599135c59b82ec9b2c9e ]
      As reported by Serge flag IRQF_NO_THREAD causes an error if the
      interrupt is actually shared and the other driver(s) don't have this
      flag set. This situation can occur if a PCI(e) legacy interrupt is
      used in combination with forced threading.
      There's no good way to deal with this properly, therefore we have to
      remove flag IRQF_NO_THREAD. For fixing the original forced threading
      issue switch to napi_schedule().
      Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threading")
      Link: https://www.spinics.net/lists/netdev/msg694960.html
      Reported-by: default avatarSerge Belyshev <belyshev@depni.sinp.msu.ru>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Tested-by: default avatarSerge Belyshev <belyshev@depni.sinp.msu.ru>
      Link: https://lore.kernel.org/r/b5b53bfe-35ac-3768-85bf-74d1290cf394@gmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Guillaume Nault's avatar
      net/sched: act_mpls: Add softdep on mpls_gso.ko · 62d9cec6
      Guillaume Nault authored
      TCA_MPLS_ACT_PUSH and TCA_MPLS_ACT_MAC_PUSH might be used on gso
      packets. Such packets will thus require mpls_gso.ko for segmentation.
      v2: Drop dependency on CONFIG_NET_MPLS_GSO in Kconfig (from Jakub and
      Fixes: 2a2ea508
       ("net: sched: add mpls manipulation actions to TC")
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Link: https://lore.kernel.org/r/1f6cab15bbd15666795061c55563aaf6a386e90e.1603708007.git.gnault@redhat.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alex Elder's avatar
      net: ipa: command payloads already mapped · 2bc5d5c3
      Alex Elder authored
      [ Upstream commit df833050cced27e1b343cc8bc41f90191b289334 ]
      IPA transactions describe actions to be performed by the IPA
      hardware.  Three cases use IPA transactions:  transmitting a socket
      buffer; providing a page to receive packet data; and issuing an IPA
      immediate command.  An IPA transaction contains a scatter/gather
      list (SGL) to hold the set of actions to be performed.
      We map buffers in the SGL for DMA at the time they are added to the
      transaction.  For skb TX transactions, we fill the SGL with a call
      to skb_to_sgvec().  Page RX transactions involve a single page
      pointer, and that is recorded in the SGL with sg_set_page().  In
      both of these cases we then map the SGL for DMA with a call to
      Immediate commands are different.  The payload for an immediate
      command comes from a region of coherent DMA memory, which must
      *not* be mapped for DMA.  For that reason, gsi_trans_cmd_add()
      sort of hand-crafts each SGL entry added to a command transaction.
    • Zenghui Yu's avatar
      net: hns3: Clear the CMDQ registers before unmapping BAR region · 1336d288
      Zenghui Yu authored
      [ Upstream commit e3364c5ff3ff975b943a7bf47e21a2a4bf20f3fe ]
      When unbinding the hns3 driver with the HNS3 VF, I got the following
      kernel panic:
      [  265.709989] Unable to handle kernel paging request at virtual address ffff800054627000
      [  265.717928] Mem abort info:
      [  265.720740]   ESR = 0x96000047
      [  265.723810]   EC = 0x25: DABT (current EL), IL = 32 bits
      [  265.729126]   SET = 0, FnV = 0
      [  265.732195]   EA = 0, S1PTW = 0
      [  265.735351] Data abort info:
      [  265.738227]   ISV = 0, ISS = 0x00000047
      [  265.742071]   CM = 0, WnR = 1
      [  265.745055] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000009b54000
      [  265.751753] [ffff800054627000] pgd=0000202ffffff003, p4d=0000202ffffff003, pud=00002020020eb003, pmd=00000020a0dfc003, pte=0000000000000000
      [  265.764314] Internal error: Oops: 96000047 [#1] SMP
      [  265.830357] CPU: 61 PID: 20319 Comm: bash Not tainted 5.9.0+ #206
      [  265.836423] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019
      [  265.843873] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
      [  265.843890] pc : hclgevf_cmd_uninit+0xbc/0x300
      [  265.861988] lr : hclgevf_cmd_uninit+0xb0/0x300
      [  265.861992] sp : ffff80004c983b50
      [  265.881411] pmr_save: 000000e0
      [  265.884453] x29: ffff80004c983b50 x28: ffff20280bbce500
      [  265.889744] x27: 0000000000000000 x26: 0000000000000000
      [  265.895034] x25: ffff800011a1f000 x24: ffff800011a1fe90
      [  265.900325] x23: ffff0020ce9b00d8 x22: ffff0020ce9b0150
      [  265.905616] x21: ffff800010d70e90 x20: ffff800010d70e90
      [  265.910906] x19: ffff0020ce9b0080 x18: 0000000000000004
      [  265.916198] x17: 0000000000000000 x16: ffff800011ae32e8
      [  265.916201] x15: 0000000000000028 x14: 0000000000000002
      [  265.916204] x13: ffff800011ae32e8 x12: 0000000000012ad8
      [  265.946619] x11: ffff80004c983b50 x10: 0000000000000000
      [  265.951911] x9 : ffff8000115d0888 x8 : 0000000000000000
      [  265.951914] x7 : ffff800011890b20 x6 : c0000000ffff7fff
      [  265.951917] x5 : ffff80004c983930 x4 : 0000000000000001
      [  265.951919] x3 : ffffa027eec1b000 x2 : 2b78ccbbff369100
      [  265.964487] x1 : 0000000000000000 x0 : ffff800054627000
      [  265.964491] Call trace:
      [  265.964494]  hclgevf_cmd_uninit+0xbc/0x300
      [  265.964496]  hclgevf_uninit_ae_dev+0x9c/0xe8
      [  265.964501]  hnae3_unregister_ae_dev+0xb0/0x130
      [  265.964516]  hns3_remove+0x34/0x88 [hns3]
      [  266.009683]  pci_device_remove+0x48/0xf0
      [  266.009692]  device_release_driver_internal+0x114/0x1e8
      [  266.030058]  device_driver_detach+0x28/0x38
      [  266.034224]  unbind_store+0xd4/0x108
      [  266.037784]  drv_attr_store+0x40/0x58
      [  266.041435]  sysfs_kf_write+0x54/0x80
      [  266.045081]  kernfs_fop_write+0x12c/0x250
      [  266.049076]  vfs_write+0xc4/0x248
      [  266.052378]  ksys_write+0x74/0xf8
      [  266.055677]  __arm64_sys_write+0x24/0x30
      [  266.059584]  el0_svc_common.constprop.3+0x84/0x270
      [  266.064354]  do_el0_svc+0x34/0xa0
      [  266.067658]  el0_svc+0x38/0x40
      [  266.070700]  el0_sync_handler+0x8c/0xb0
      [  266.074519]  el0_sync+0x140/0x180
      It looks like the BAR memory region had already been unmapped before we
      start clearing CMDQ registers in it, which is pretty bad and the kernel
      happily kills itself because of a Current EL Data Abort (on arm64).
      Moving the CMDQ uninitialization a bit early fixes the issue for me.
      Fixes: 862d969a
       ("net: hns3: do VF's pci re-initialization while PF doing FLR")
      Signed-off-by: default avatarZenghui Yu <yuzenghui@huawei.com>
      Link: https://lore.kernel.org/r/20201023051550.793-1-yuzenghui@huawei.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Aleksandr Nogikh's avatar
      netem: fix zero division in tabledist · 7fb8fbce
      Aleksandr Nogikh authored
      [ Upstream commit eadd1befdd778a1eca57fad058782bd22b4db804 ]
      Currently it is possible to craft a special netlink RTM_NEWQDISC
      command that can result in jitter being equal to 0x80000000. It is
      enough to set the 32 bit jitter to 0x02000000 (it will later be
      multiplied by 2^6) or just set the 64 bit jitter via
      TCA_NETEM_JITTER64. This causes an overflow during the generation of
      uniformly distributed numbers in tabledist(), which in turn leads to
      division by zero (sigma != 0, but sigma * 2 is 0).
      The related fragment of code needs 32-bit division - see commit
      9b0ed891 ("netem: remove unnecessary 64 bit modulus"), so switching to
      64 bit is not an option.
      Fix the issue by keeping the value of jitter within the range that can
      be adequately handled by tabledist() - [0;INT_MAX]. As negative std
      deviation makes no sense, take the absolute value of the passed value
      and cap it at INT_MAX. Inside tabledist(), switch to unsigned 32 bit
      arithmetic in order to prevent overflows.
      Fixes: 1da177e4
      Signed-off-by: default avatarAleksandr Nogikh <nogikh@google.com>
      Reported-by: syzbot+ec762a6342ad0d3c0d8f@syzkaller.appspotmail.com
      Acked-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Link: https://lore.kernel.org/r/20201028170731.1383332-1-aleksandrnogikh@gmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ido Schimmel's avatar
      mlxsw: core: Fix memory leak on module removal · 25259932
      Ido Schimmel authored
      [ Upstream commit adc80b6cfedff6dad8b93d46a5ea2775fd5af9ec ]
      Free the devlink instance during the teardown sequence in the non-reload
      case to avoid the following memory leak.
      unreferenced object 0xffff888232895000 (size 2048):
        comm "modprobe", pid 1073, jiffies 4295568857 (age 164.871s)
        hex dump (first 32 bytes):
          00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de  ........".......
          10 50 89 32 82 88 ff ff 10 50 89 32 82 88 ff ff  .P.2.....P.2....
          [<00000000c704e9a6>] __kmalloc+0x13a/0x2a0
          [<00000000ee30129d>] devlink_alloc+0xff/0x760
          [<0000000092ab3e5d>] 0xffffffffa042e5b0
          [<000000004f3f8a31>] 0xffffffffa042f6ad
          [<0000000092800b4b>] 0xffffffffa0491df3
          [<00000000c4843903>] local_pci_probe+0xcb/0x170
          [<000000006993ded7>] pci_device_probe+0x2c2/0x4e0
          [<00000000a8e0de75>] really_probe+0x2c5/0xf90
          [<00000000d42ba75d>] driver_probe_device+0x1eb/0x340
          [<00000000bcc95e05>] device_driver_attach+0x294/0x300
          [<000000000e2bc177>] __driver_attach+0x167/0x2f0
          [<000000007d44cd6e>] bus_for_each_dev+0x148/0x1f0
          [<000000003cd5a91e>] driver_attach+0x45/0x60
          [<000000000041ce51>] bus_add_driver+0x3b8/0x720
          [<00000000f5215476>] driver_register+0x230/0x4e0
          [<00000000d79356f5>] __pci_register_driver+0x190/0x200
      Fixes: a22712a9
       ("mlxsw: core: Fix devlink unregister flow")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reported-by: default avatarVadim Pasternak <vadimp@nvidia.com>
      Tested-by: default avatarOleksandr Shamray <oleksandrs@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lijun Pan's avatar
      ibmvnic: fix ibmvnic_set_mac · d6f6e3f9
      Lijun Pan authored
      [ Upstream commit 8fc3672a8ad3e782bac80e979bc2a2c10960cbe9 ]
      Jakub Kicinski brought up a concern in ibmvnic_set_mac().
      ibmvnic_set_mac() does this:
      	ether_addr_copy(adapter->mac_addr, addr->sa_data);
      	if (adapter->state != VNIC_PROBED)
      		rc = __ibmvnic_set_mac(netdev, addr->sa_data);
      So if state == VNIC_PROBED, the user can assign an invalid address to
      adapter->mac_addr, and ibmvnic_set_mac() will still return 0.
      The fix is to validate ethernet address at the beginning of
      ibmvnic_set_mac(), and move the ether_addr_copy to
      the case of "adapter->state != VNIC_PROBED".
      Fixes: c26eba03
       ("ibmvnic: Update reset infrastructure to support tunable parameters")
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Link: https://lore.kernel.org/r/20201027220456.71450-1-ljp@linux.ibm.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Thomas Bogendoerfer's avatar
      ibmveth: Fix use of ibmveth in a bridge. · 4606d351
      Thomas Bogendoerfer authored
      [ Upstream commit 2ac8af0967aaa2b67cb382727e784900d2f4d0da ]
      The check for src mac address in ibmveth_is_packet_unsupported is wrong.
      Commit 6f227543 wanted to shut down messages for loopback packets,
      but now suppresses bridged frames, which are accepted by the hypervisor
      otherwise bridging won't work at all.
      Fixes: 6f227543
       ("ibmveth: Detect unsupported packets before sending to the hypervisor")
      Signed-off-by: default avatarMichal Suchanek <msuchanek@suse.de>
      Signed-off-by: default avatarThomas Bogendoerfer <tbogendoerfer@suse.de>
      Link: https://lore.kernel.org/r/20201026104221.26570-1-msuchanek@suse.de
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Masahiro Fujiwara's avatar
      gtp: fix an use-before-init in gtp_newlink() · b520e574
      Masahiro Fujiwara authored
      [ Upstream commit 51467431200b91682b89d31317e35dcbca1469ce ]
      *_pdp_find() from gtp_encap_recv() would trigger a crash when a peer
      sends GTP packets while creating new GTP device.
      RIP: 0010:gtp1_pdp_find.isra.0+0x68/0x90 [gtp]
      Call Trace:
       gtp_encap_recv+0xc2/0x2e0 [gtp]
       ? gtp1_pdp_find.isra.0+0x90/0x90 [gtp]
       ? ip_protocol_deliver_rcu+0x1b0/0x1b0
      gtp_encap_enable() should be called after gtp_hastable_new() otherwise
      *_pdp_find() will access the uninitialized hash table.
      Fixes: 1e3a3abd
       ("gtp: make GTP sockets in gtp_newlink optional")
      Signed-off-by: default avatarMasahiro Fujiwara <fujiwara.masahiro@gmail.com>
      Link: https://lore.kernel.org/r/20201027114846.3924-1-fujiwara.masahiro@gmail.com
      Signed-off-by: Ja...
    • Raju Rangoju's avatar
      cxgb4: set up filter action after rewrites · 9921e777
      Raju Rangoju authored
      [ Upstream commit 937d8420588421eaa5c7aa5c79b26b42abb288ef ]
      The current code sets up the filter action field before
      rewrites are set up. When the action 'switch' is used
      with rewrites, this may result in initial few packets
      that get switched out don't have rewrites applied
      on them.
      So, make sure filter action is set up along with rewrites
      or only after everything else is set up for rewrites.
      Fixes: 12b276fb
       ("cxgb4: add support to create hash filters")
      Signed-off-by: default avatarRaju Rangoju <rajur@chelsio.com>
      Link: https://lore.kernel.org/r/20201023115852.18262-1-rajur@chelsio.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vinay Kumar Yadav's avatar
      chelsio/chtls: fix tls record info to user · b97638e0
      Vinay Kumar Yadav authored
      [ Upstream commit 4f3391ce8f5a69e7e6d66d0a3fc654eb6dbdc919 ]
      chtls_pt_recvmsg() receives a skb with tls header and subsequent
      skb with data, need to finalize the data copy whenever next skb
      with tls header is available. but here current tls header is
      overwritten by next available tls header, ends up corrupting
      user buffer data. fixing it by finalizing current record whenever
      next skb contains tls header.
      - Improved commit message.
      Fixes: 17a7d24a
       ("crypto: chtls - generic handling of data and hdr")
      Signed-off-by: default avatarVinay Kumar Yadav <vinay.yadav@chelsio.com>
      Link: https://lore.kernel.org/r/20201022190556.21308-1-vinay.yadav@chelsio.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vinay Kumar Yadav's avatar
      chelsio/chtls: fix memory leaks in CPL handlers · eb592f2a
      Vinay Kumar Yadav authored
      [ Upstream commit 6daa1da4e262b0cd52ef0acc1989ff22b5540264 ]
      CPL handler functions chtls_pass_open_rpl() and
      chtls_close_listsrv_rpl() should return CPL_RET_BUF_DONE
      so that caller function will do skb free to avoid leak.
      Fixes: cc35c88a
       ("crypto : chtls - CPL handler definition")
      Signed-off-by: default avatarVinay Kumar Yadav <vinay.yadav@chelsio.com>
      Link: https://lore.kernel.org/r/20201025194228.31271-1-vinay.yadav@chelsio.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vinay Kumar Yadav's avatar
      chelsio/chtls: fix deadlock issue · c3208dec
      Vinay Kumar Yadav authored
      [ Upstream commit 28e9dcd9172028263c8225c15c4e329e08475e89 ]
      In chtls_pass_establish() we hold child socket lock using bh_lock_sock
      and we are again trying bh_lock_sock in add_to_reap_list, causing deadlock.
      Remove bh_lock_sock in add_to_reap_list() as lock is already held.
      Fixes: cc35c88a
       ("crypto : chtls - CPL handler definition")
      Signed-off-by: default avatarVinay Kumar Yadav <vinay.yadav@chelsio.com>
      Link: https://lore.kernel.org/r/20201025193538.31112-1-vinay.yadav@chelsio.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasundhara Volam's avatar
      bnxt_en: Send HWRM_FUNC_RESET fw command unconditionally. · b334112f
      Vasundhara Volam authored
      [ Upstream commit 825741b071722f1c8ad692cead562c4b5f5eaa93 ]
      In the AER or firmware reset flow, if we are in fatal error state or
      if pci_channel_offline() is true, we don't send any commands to the
      firmware because the commands will likely not reach the firmware and
      most commands don't matter much because the firmware is likely to be
      reset imminently.
      However, the HWRM_FUNC_RESET command is different and we should always
      attempt to send it.  In the AER flow for example, the .slot_reset()
      call will trigger this fw command and we need to try to send it to
      effect the proper reset.
      Fixes: b340dc680ed4 ("bnxt_en: Avoid sending firmware messages when AER error is detected.")
      Reviewed-by: default avatarEdwin Peer <edwin.peer@broadcom.com>
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasundhara Volam's avatar
      bnxt_en: Re-write PCI BARs after PCI fatal error. · f739fc7e
      Vasundhara Volam authored
      [ Upstream commit f75d9a0aa96721d20011cd5f8c7a24eb32728589 ]
      When a PCIe fatal error occurs, the internal latched BAR addresses
      in the chip get reset even though the BAR register values in config
      space are retained.
      pci_restore_state() will not rewrite the BAR addresses if the
      BAR address values are valid, causing the chip's internal BAR addresses
      to stay invalid.  So we need to zero the BAR registers during PCIe fatal
      error to force pci_restore_state() to restore the BAR addresses.  These
      write cycles to the BAR registers will cause the proper BAR addresses to
      latch internally.
      Fixes: 6316ea6d
       ("bnxt_en: Enable AER support.")
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasundhara Volam's avatar
      bnxt_en: Invoke cancel_delayed_work_sync() for PFs also. · 7fe9514c
      Vasundhara Volam authored
      [ Upstream commit 631ce27a3006fc0b732bfd589c6df505f62eadd9 ]
      As part of the commit b148bb238c02
      ("bnxt_en: Fix possible crash in bnxt_fw_reset_task()."),
      cancel_delayed_work_sync() is called only for VFs to fix a possible
      crash by cancelling any pending delayed work items. It was assumed
      by mistake that the flush_workqueue() call on the PF would flush
      delayed work items as well.
      As flush_workqueue() does not cancel the delayed workqueue, extend
      the fix for PFs. This fix will avoid the system crash, if there are
      any pending delayed work items in fw_reset_task() during driver's
      .remove() call.
      Unify the workqueue cleanup logic for both PF and VF by calling
      cancel_work_sync() and cancel_delayed_work_sync() directly in
      Fixes: b148bb238c02 ("bnxt_en: Fix possible crash in bnxt_fw_reset_task().")
      Reviewed-by: default avatarPavan Chebbi <pavan.chebbi@broadcom.com>
      Reviewed-by: default avatarAndy Gospodarek <gospo@broadcom.com>
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Vasundhara Volam's avatar
      bnxt_en: Fix regression in workqueue cleanup logic in bnxt_remove_one(). · bfbbfb50
      Vasundhara Volam authored
      [ Upstream commit 21d6a11e2cadfb8446265a3efff0e2aad206e15e ]
      A recent patch has moved the workqueue cleanup logic before
      calling unregister_netdev() in bnxt_remove_one().  This caused a
      regression because the workqueue can be restarted if the device is
      still open.  Workqueue cleanup must be done after unregister_netdev().
      The workqueue will not restart itself after the device is closed.
      Call bnxt_cancel_sp_work() after unregister_netdev() and
      call bnxt_dl_fw_reporters_destroy() after that.  This fixes the
      regession and the original NULL ptr dereference issue.
      Fixes: b16939b59cc0 ("bnxt_en: Fix NULL ptr dereference crash in bnxt_fw_reset_task()")
      Signed-off-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michael Chan's avatar
      bnxt_en: Check abort error state in bnxt_open_nic(). · 0b17de4d
      Michael Chan authored
      [ Upstream commit a1301f08c5acf992d9c1fafddc84c3a822844b04 ]
      bnxt_open_nic() is called during configuration changes that require
      the NIC to be closed and then opened.  This call is protected by
      rtnl_lock.  Firmware reset can be happening at the same time.  Only
      critical portions of the entire firmware reset sequence are protected
      by the rtnl_lock.  It is possible that bnxt_open_nic() can be called
      when the firmware reset sequence is aborting.  In that case,
      bnxt_open_nic() needs to check if the ABORT_ERR flag is set and
      abort if it is.  The configuration change that resulted in the
      bnxt_open_nic() call will fail but the NIC will be brought to a
      consistent IF_DOWN state.
      Without this patch, if bnxt_open_nic() were to continue in this error
      state, it may crash like this:
      [ 1648.659736] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 1648.659768] IP: [<ffffffffc01e9b3a>] bnxt_alloc_mem+0x50a/0x1140 [bnxt_en]
      [ 1648.659796] PGD 101e1b3067 PUD 101e1b2067 PMD 0
      [ 1648.659813] Oops: 0000 [#1] SMP
      [ 1648.659825] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc dell_smbios dell_wmi_descriptor dcdbas amd64_edac_mod edac_mce_amd kvm_amd kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper vfat cryptd fat pcspkr ipmi_ssif sg k10temp i2c_piix4 wmi ipmi_si ipmi_devintf ipmi_msghandler tpm_crb acpi_power_meter sch_fq_codel ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ahci drm libahci megaraid_sas crct10dif_pclmul crct10dif_common
      [ 1648.660063]  tg3 libata crc32c_intel bnxt_en(OE) drm_panel_orientation_quirks devlink ptp pps_core dm_mirror dm_region_hash dm_log dm_mod fuse
      [ 1648.660105] CPU: 13 PID: 3867 Comm: ethtool Kdump: loaded Tainted: G           OE  ------------   3.10.0-1152.el7.x86_64 #1
      [ 1648.660911] Hardware name: Dell Inc. PowerEdge R7515/0R4CNN, BIOS 1.2.14 01/28/2020
      [ 1648.661662] task: ffff94e64cbc9080 ti: ffff94f55df1c000 task.ti: ffff94f55df1c000
      [ 1648.662409] RIP: 0010:[<ffffffffc01e9b3a>]  [<ffffffffc01e9b3a>] bnxt_alloc_mem+0x50a/0x1140 [bnxt_en]
      [ 1648.663171] RSP: 0018:ffff94f55df1fba8  EFLAGS: 00010202
      [ 1648.663927] RAX: 0000000000000000 RBX: ffff94e6827e0000 RCX: 0000000000000000
      [ 1648.664684] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94e6827e08c0
      [ 1648.665433] RBP: ffff94f55df1fc20 R08: 00000000000001ff R09: 0000000000000008
      [ 1648.666184] R10: 0000000000000d53 R11: ffff94f55df1f7ce R12: ffff94e6827e08c0
      [ 1648.666940] R13: ffff94e6827e08c0 R14: ffff94e6827e08c0 R15: ffffffffb9115e40
      [ 1648.667695] FS:  00007f8aadba5740(0000) GS:ffff94f57eb40000(0000) knlGS:0000000000000000
      [ 1648.668447] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1648.669202] CR2: 0000000000000000 CR3: 0000001022772000 CR4: 0000000000340fe0
      [ 1648.669966] Call Trace:
      [ 1648.670730]  [<ffffffffc01f1d5d>] ? bnxt_need_reserve_rings+0x9d/0x170 [bnxt_en]
      [ 1648.671496]  [<ffffffffc01fa7ea>] __bnxt_open_nic+0x8a/0x9a0 [bnxt_en]
      [ 1648.672263]  [<ffffffffc01f7479>] ? bnxt_close_nic+0x59/0x1b0 [bnxt_en]
      [ 1648.673031]  [<ffffffffc01fb11b>] bnxt_open_nic+0x1b/0x50 [bnxt_en]
      [ 1648.673793]  [<ffffffffc020037c>] bnxt_set_ringparam+0x6c/0xa0 [bnxt_en]
      [ 1648.674550]  [<ffffffffb8a5f564>] dev_ethtool+0x1334/0x21a0
      [ 1648.675306]  [<ffffffffb8a719ff>] dev_ioctl+0x1ef/0x5f0
      [ 1648.676061]  [<ffffffffb8a324bd>] sock_do_ioctl+0x4d/0x60
      [ 1648.676810]  [<ffffffffb8a326bb>] sock_ioctl+0x1eb/0x2d0
      [ 1648.677548]  [<ffffffffb8663230>] do_vfs_ioctl+0x3a0/0x5b0
      [ 1648.678282]  [<ffffffffb8b8e678>] ? __do_page_fault+0x238/0x500
      [ 1648.679016]  [<ffffffffb86634e1>] SyS_ioctl+0xa1/0xc0
      [ 1648.679745]  [<ffffffffb8b93f92>] system_call_fastpath+0x25/0x2a
      [ 1648.680461] Code: 9e 60 01 00 00 0f 1f 40 00 45 8b 8e 48 01 00 00 31 c9 45 85 c9 0f 8e 73 01 00 00 66 0f 1f 44 00 00 49 8b 86 a8 00 00 00 48 63 d1 <48> 8b 14 d0 48 85 d2 0f 84 46 01 00 00 41 8b 86 44 01 00 00 c7
      [ 1648.681986] RIP  [<ffffffffc01e9b3a>] bnxt_alloc_mem+0x50a/0x1140 [bnxt_en]
      [ 1648.682724]  RSP <ffff94f55df1fba8>
      [ 1648.683451] CR2: 0000000000000000
      Fixes: ec5d31e3
       ("bnxt_en: Handle firmware reset status during IF_UP.")
      Reviewed-by: default avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Reviewed-by: default avatarPavan Chebbi <pavan.chebbi@broadcom.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michael Schaller's avatar
      efivarfs: Replace invalid slashes with exclamation marks in dentries. · c328793e
      Michael Schaller authored
      commit 336af6a4686d885a067ecea8c3c3dd129ba4fc75 upstream.
      Without this patch efivarfs_alloc_dentry creates dentries with slashes in
      their name if the respective EFI variable has slashes in its name. This in
      turn causes EIO on getdents64, which prevents a complete directory listing
      of /sys/firmware/efi/efivars/.
      This patch replaces the invalid shlashes with exclamation marks like
      kobject_set_name_vargs does for /sys/firmware/efi/vars/ to have consistently
      named dentries under /sys/firmware/efi/vars/ and /sys/firmware/efi/efivars/.
      Signed-off-by: default avatarMichael Schaller <misch@google.com>
      Link: https://lore.kernel.org/r/20200925074502.150448-1-misch@google.com
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatardann frazier <dann.frazier@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Williams's avatar
      x86/copy_mc: Introduce copy_mc_enhanced_fast_string() · 61ececc8
      Dan Williams authored
      commit 5da8e4a658109e3b7e1f45ae672b7c06ac3e7158 upstream.
      The motivations to go rework memcpy_mcsafe() are that the benefit of
      doing slow and careful copies is obviated on newer CPUs, and that the
      current opt-in list of CPUs to instrument recovery is broken relative to
      those CPUs.  There is no need to keep an opt-in list up to date on an
      ongoing basis if pmem/dax operations are instrumented for recovery by
      default. With recovery enabled by default the old "mcsafe_key" opt-in to
      careful copying can be made a "fragile" opt-out. Where the "fragile"
      list takes steps to not consume poison across cachelines.
      The discussion with Linus made clear that the current "_mcsafe" suffix
      was imprecise to a fault. The operations that are needed by pmem/dax are
      to copy from a source address that might throw #MC to a destination that
      may write-fault, if it is a user page.
      So copy_to_user_mcsafe() becomes copy_mc_to_user() to indicate
      the separate precautions taken on source and destination.
      copy_mc_to_kernel() is introduced as a non-SMAP version that does not
      expect write-faults on the destination, but is still prepared to abort
      with an error code upon taking #MC.
      The original copy_mc_fragile() implementation had negative performance
      implications since it did not use the fast-string instruction sequence
      to perform copies. For this reason copy_mc_to_kernel() fell back to
      plain memcpy() to preserve performance on platforms that did not indicate
      the capability to recover from machine check exceptions. However, that
      capability detection was not architectural and now that some platforms
      can recover from fast-string consumption of memory errors the memcpy()
      fallback now causes these more capable platforms to fail.
      Introduce copy_mc_enhanced_fast_string() as the fast default
      implementation of copy_mc_to_kernel() and finalize the transition of
      copy_mc_fragile() to be a platform quirk to indicate 'copy-carefully'.
      With this in place, copy_mc_to_kernel() is fast and recovery-ready by
      default regardless of hardware capability.
      Thanks to Vivek for identifying that copy_user_generic() is not suitable
      as the copy_mc_to_user() backend since the #MC handler explicitly checks
      ex_has_fault_handler(). Thanks to the 0day robot for catching a
      performance bug in the x86/copy_mc_to_user implementation.
       [ bp: Add the "why" for this change from the 0/2th message, massage. ]
      Fixes: 92b0729c
       ("x86/mm, x86/mce: Add memcpy_mcsafe()")
      Reported-by: default avatarErwin Tsaur <erwin.tsaur@intel.com>
      Reported-by: default avatar0day robot <lkp@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarTony Luck <tony.luck@intel.com>
      Tested-by: default avatarErwin Tsaur <erwin.tsaur@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/160195562556.2163339.18063423034951948973.stgit@dwillia2-desk3.amr.corp.intel.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Williams's avatar
      x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}() · a092869e
      Dan Williams authored
      commit ec6347bb43395cb92126788a1a5b25302543f815 upstream.
      In reaction to a proposal to introduce a memcpy_mcsafe_fast()
      implementation Linus points out that memcpy_mcsafe() is poorly named
      relative to communicating the scope of the interface. Specifically what
      addresses are valid to pass as source, destination, and what faults /
      exceptions are handled.
      Of particular concern is that even though x86 might be able to handle
      the semantics of copy_mc_to_user() with its common copy_user_generic()
      implementation other archs likely need / want an explicit path for this
        On Fri, May 1, 2020 at 11:28 AM Linus Torvalds <torvalds@linux-foundation.org> wrote:
        > On Thu, Apr 30, 2020 at 6:21 PM Dan Williams <dan.j.williams@intel.com> wrote:
        > >
        > > However now I see that copy_user_generic() works for the wrong reason.
        > > It works because the exception on the source address due to poison
        > > looks no different than a write fault on the user address to the
        > > caller, it's still just a short copy. So it makes copy_to_user() work
        > > for the wrong reason relative to the name.
        > Right.
        > And it won't work that way on other architectures. On x86, we have a
        > generic function that can take faults on either side, and we use it
        > for both cases (and for the "in_user" case too), but that's an
        > artifact of the architecture oddity.
        > In fact, it's probably wrong even on x86 - because it can hide bugs -
        > but writing those things is painful enough that everybody prefers
        > having just one function.
      Replace a single top-level memcpy_mcsafe() with either
      copy_mc_to_user(), or copy_mc_to_kernel().
      Introduce an x86 copy_mc_fragile() name as the rename for the
      low-level x86 implementation formerly named memcpy_mcsafe(). It is used
      as the slow / careful backend that is supplanted by a fast
      copy_mc_generic() in a follow-on patch.
      One side-effect of this reorganization is that separating copy_mc_64.S
      to its own file means that perf no longer needs to track dependencies
      for its memcpy_64.S benchmarks.
       [ bp: Massage a bit. ]
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Cc: <stable@vger.kernel.org>
      Link: http://lore.kernel.org/r/CAHk-=wjSqtXAqfUJxFtWNwmguFASTgB0dz1dT3V-78Quiezqbg@mail.gmail.com
      Link: https://lkml.kernel.org/r/160195561680.2163339.11574962055305783722.stgit@dwillia2-desk3.amr.corp.intel.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Randy Dunlap's avatar
      x86/PCI: Fix intel_mid_pci.c build error when ACPI is not enabled · 18703f74
      Randy Dunlap authored
      commit 035fff1f7aab43e420e0098f0854470a5286fb83 upstream.
      Fix build error when CONFIG_ACPI is not set/enabled by adding the header
      file <asm/acpi.h> which contains a stub for the function in the build
          ../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
          ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
      Fixes: a912a758 ("x86/platform/intel-mid: Move PCI initialization to arch_init()")
      Link: https://lore.kernel.org/r/ea903917-e51b-4cc9-2680-bc1e36efa026@infradead.org
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: default avatarJesse Barnes <jsbarnes@google.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org	# v4.16+
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Jesse Barnes <jsbarnes@google.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nick Desaulniers's avatar
      arm64: link with -z norelro regardless of CONFIG_RELOCATABLE · 4b0a9591
      Nick Desaulniers authored
      commit 3b92fa7485eba16b05166fddf38ab42f2ff6ab95 upstream.
      CONFIG_RELOCATABLE=n, we observe the following failure when trying to
      link the kernel image with LD=ld.lld:
      error: section: .exit.data is not contiguous with other relro sections
      ld.lld defaults to -z relro while ld.bfd defaults to -z norelro. This
      was previously fixed, but only for CONFIG_RELOCATABLE=y.
      Fixes: 3bbd3db8
       ("arm64: relocatable: fix inconsistencies in linker script and options")
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20201016175339.2429280-1-ndesaulniers@google.com
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Marc Zyngier's avatar
      arm64: Run ARCH_WORKAROUND_2 enabling code on all CPUs · dfaa0f7d
      Marc Zyngier authored
      commit 39533e12063be7f55e3d6ae21ffe067799d542a4 upstream.
      Commit 606f8e7b ("arm64: capabilities: Use linear array for
      detection and verification") changed the way we deal with per-CPU errata
      by only calling the .matches() callback until one CPU is found to be
      affected. At this point, .matches() stop being called, and .cpu_enable()
      will be called on all CPUs.
      This breaks the ARCH_WORKAROUND_2 handling, as only a single CPU will be
      In order to address this, forcefully call the .matches() callback from a
      .cpu_enable() callback, which brings us back to the original behaviour.
      Fixes: 606f8e7b
       ("arm64: capabilities: Use linear array for detection and verification")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>