--- /dev/null
+From 474c4f306eefbb21b67ebd1de802d005c7d7ecdc Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Mon, 30 Dec 2019 16:32:38 +0100
+Subject: nfs: NFS_SWAP should depend on SWAP
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 474c4f306eefbb21b67ebd1de802d005c7d7ecdc upstream.
+
+If CONFIG_SWAP=n, it does not make much sense to offer the user the
+option to enable support for swapping over NFS, as that will still fail
+at run time:
+
+ # swapon /swap
+ swapon: /swap: swapon failed: Function not implemented
+
+Fix this by adding a dependency on CONFIG_SWAP.
+
+Fixes: a564b8f0398636ba ("nfs: enable swap on NFS")
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfs/Kconfig
++++ b/fs/nfs/Kconfig
+@@ -89,7 +89,7 @@ config NFS_V4
+ config NFS_SWAP
+ bool "Provide swap over NFS support"
+ default n
+- depends on NFS_FS
++ depends on NFS_FS && SWAP
+ select SUNRPC_SWAP
+ help
+ This option enables swapon to work on files located on NFS mounts.
--- /dev/null
+From 924491f2e476f7234d722b24171a4daff61bbe13 Mon Sep 17 00:00:00 2001
+From: Robert Milkowski <rmilkowski@gmail.com>
+Date: Tue, 28 Jan 2020 08:37:47 +0000
+Subject: NFSv4: try lease recovery on NFS4ERR_EXPIRED
+
+From: Robert Milkowski <rmilkowski@gmail.com>
+
+commit 924491f2e476f7234d722b24171a4daff61bbe13 upstream.
+
+Currently, if an nfs server returns NFS4ERR_EXPIRED to open(),
+we return EIO to applications without even trying to recover.
+
+Fixes: 272289a3df72 ("NFSv4: nfs4_do_handle_exception() handle revoke/expiry of a single stateid")
+Signed-off-by: Robert Milkowski <rmilkowski@gmail.com>
+Reviewed-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -2916,6 +2916,11 @@ static struct nfs4_state *nfs4_do_open(s
+ exception.retry = 1;
+ continue;
+ }
++ if (status == -NFS4ERR_EXPIRED) {
++ nfs4_schedule_lease_recovery(server->nfs_client);
++ exception.retry = 1;
++ continue;
++ }
+ if (status == -EAGAIN) {
+ /* We must have found a delegation */
+ exception.retry = 1;
--- /dev/null
+From 9db8dc6d0785225c42a37be7b44d1b07b31b8957 Mon Sep 17 00:00:00 2001
+From: Logan Gunthorpe <logang@deltatee.com>
+Date: Wed, 8 Jan 2020 14:32:08 -0700
+Subject: PCI: Don't disable bridge BARs when assigning bus resources
+
+From: Logan Gunthorpe <logang@deltatee.com>
+
+commit 9db8dc6d0785225c42a37be7b44d1b07b31b8957 upstream.
+
+Some PCI bridges implement BARs in addition to bridge windows. For
+example, here's a PLX switch:
+
+ 04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI
+ Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca)
+ (prog-if 00 [Normal decode])
+ Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
+ Memory at 90a00000 (32-bit, non-prefetchable) [size=256K]
+ Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0
+ I/O behind bridge: 00002000-00003fff
+ Memory behind bridge: 90000000-909fffff
+ Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff
+
+Previously, when the kernel assigned resource addresses (with the
+pci=realloc command line parameter, for example) it could clear the struct
+resource corresponding to the BAR. When this happened, lspci would report
+this BAR as "ignored":
+
+ Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=256K]
+
+This is because the kernel reports a zero start address and zero flags
+in the corresponding sysfs resource file and in /proc/bus/pci/devices.
+Investigation with 'lspci -x', however, shows the BIOS-assigned address
+will still be programmed in the device's BAR registers.
+
+It's clearly a bug that the kernel lost track of the BAR value, but in most
+cases, this still won't result in a visible issue because nothing uses the
+memory, so nothing is affected. However, when an IOMMU is in use, it will
+not reserve this space in the IOVA because the kernel no longer thinks the
+range is valid. (See dmar_init_reserved_ranges() for the Intel
+implementation of this.)
+
+Without the proper reserved range, a DMA mapping may allocate an IOVA that
+matches a bridge BAR, which results in DMA accesses going to the BAR
+instead of the intended RAM.
+
+The problem was in pci_assign_unassigned_root_bus_resources(). When any
+resource from a bridge device fails to get assigned, the code set the
+resource's flags to zero. This makes sense for bridge windows, as they
+will be re-enabled later, but for regular BARs, it makes the kernel
+permanently lose track of the fact that they decode address space.
+
+Change pci_assign_unassigned_root_bus_resources() and
+pci_assign_unassigned_bridge_resources() so they only clear "res->flags"
+for bridge *windows*, not bridge BARs.
+
+Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)")
+Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com
+[bhelgaas: commit log, check for pci_is_bridge()]
+Reported-by: Kit Chow <kchow@gigaio.com>
+Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/setup-bus.c | 20 ++++++++++++++++----
+ 1 file changed, 16 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/setup-bus.c
++++ b/drivers/pci/setup-bus.c
+@@ -1833,12 +1833,18 @@ again:
+ /* restore size and flags */
+ list_for_each_entry(fail_res, &fail_head, list) {
+ struct resource *res = fail_res->res;
++ int idx;
+
+ res->start = fail_res->start;
+ res->end = fail_res->end;
+ res->flags = fail_res->flags;
+- if (fail_res->dev->subordinate)
+- res->flags = 0;
++
++ if (pci_is_bridge(fail_res->dev)) {
++ idx = res - &fail_res->dev->resource[0];
++ if (idx >= PCI_BRIDGE_RESOURCES &&
++ idx <= PCI_BRIDGE_RESOURCE_END)
++ res->flags = 0;
++ }
+ }
+ free_list(&fail_head);
+
+@@ -1904,12 +1910,18 @@ again:
+ /* restore size and flags */
+ list_for_each_entry(fail_res, &fail_head, list) {
+ struct resource *res = fail_res->res;
++ int idx;
+
+ res->start = fail_res->start;
+ res->end = fail_res->end;
+ res->flags = fail_res->flags;
+- if (fail_res->dev->subordinate)
+- res->flags = 0;
++
++ if (pci_is_bridge(fail_res->dev)) {
++ idx = res - &fail_res->dev->resource[0];
++ if (idx >= PCI_BRIDGE_RESOURCES &&
++ idx <= PCI_BRIDGE_RESOURCE_END)
++ res->flags = 0;
++ }
+ }
+ free_list(&fail_head);
+
--- /dev/null
+From a242c36951ecd24bc16086940dbe6b522205c461 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?H=C3=A5kon=20Bugge?= <haakon.bugge@oracle.com>
+Date: Mon, 16 Dec 2019 13:04:36 +0100
+Subject: RDMA/netlink: Do not always generate an ACK for some netlink operations
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Håkon Bugge <haakon.bugge@oracle.com>
+
+commit a242c36951ecd24bc16086940dbe6b522205c461 upstream.
+
+In rdma_nl_rcv_skb(), the local variable err is assigned the return value
+of the supplied callback function, which could be one of
+ib_nl_handle_resolve_resp(), ib_nl_handle_set_timeout(), or
+ib_nl_handle_ip_res_resp(). These three functions all return skb->len on
+success.
+
+rdma_nl_rcv_skb() is merely a copy of netlink_rcv_skb(). The callback
+functions used by the latter have the convention: "Returns 0 on success or
+a negative error code".
+
+In particular, the statement (equal for both functions):
+
+ if (nlh->nlmsg_flags & NLM_F_ACK || err)
+
+implies that rdma_nl_rcv_skb() always will ack a message, independent of
+the NLM_F_ACK being set in nlmsg_flags or not.
+
+The fix could be to change the above statement, but it is better to keep
+the two *_rcv_skb() functions equal in this respect and instead change the
+three callback functions in the rdma subsystem to the correct convention.
+
+Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink")
+Fixes: ae43f8286730 ("IB/core: Add IP to GID netlink offload")
+Link: https://lore.kernel.org/r/20191216120436.3204814-1-haakon.bugge@oracle.com
+Suggested-by: Mark Haywood <mark.haywood@oracle.com>
+Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
+Tested-by: Mark Haywood <mark.haywood@oracle.com>
+Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
+Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/addr.c | 2 +-
+ drivers/infiniband/core/sa_query.c | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/infiniband/core/addr.c
++++ b/drivers/infiniband/core/addr.c
+@@ -141,7 +141,7 @@ int ib_nl_handle_ip_res_resp(struct sk_b
+ if (ib_nl_is_good_ip_resp(nlh))
+ ib_nl_process_good_ip_rsep(nlh);
+
+- return skb->len;
++ return 0;
+ }
+
+ static int ib_nl_ip_send_msg(struct rdma_dev_addr *dev_addr,
+--- a/drivers/infiniband/core/sa_query.c
++++ b/drivers/infiniband/core/sa_query.c
+@@ -848,7 +848,7 @@ int ib_nl_handle_set_timeout(struct sk_b
+ }
+
+ settimeout_out:
+- return skb->len;
++ return 0;
+ }
+
+ static inline int ib_nl_is_good_resolve_resp(const struct nlmsghdr *nlh)
+@@ -920,7 +920,7 @@ int ib_nl_handle_resolve_resp(struct sk_
+ }
+
+ resp_out:
+- return skb->len;
++ return 0;
+ }
+
+ static void free_sm_ah(struct kref *kref)
--- /dev/null
+From b9fc5320212efdfb4e08b825aaa007815fd11d16 Mon Sep 17 00:00:00 2001
+From: Bean Huo <beanhuo@micron.com>
+Date: Mon, 20 Jan 2020 14:08:13 +0100
+Subject: scsi: ufs: Fix ufshcd_probe_hba() reture value in case ufshcd_scsi_add_wlus() fails
+
+From: Bean Huo <beanhuo@micron.com>
+
+commit b9fc5320212efdfb4e08b825aaa007815fd11d16 upstream.
+
+A non-zero error value likely being returned by ufshcd_scsi_add_wlus() in
+case of failure of adding the WLs, but ufshcd_probe_hba() doesn't use this
+value, and doesn't report this failure to upper caller. This patch is to
+fix this issue.
+
+Fixes: 2a8fa600445c ("ufs: manually add well known logical units")
+Link: https://lore.kernel.org/r/20200120130820.1737-2-huobean@gmail.com
+Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
+Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
+Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
+Signed-off-by: Bean Huo <beanhuo@micron.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/ufs/ufshcd.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/ufs/ufshcd.c
++++ b/drivers/scsi/ufs/ufshcd.c
+@@ -5347,7 +5347,8 @@ static int ufshcd_probe_hba(struct ufs_h
+ ufshcd_init_icc_levels(hba);
+
+ /* Add required well known logical units to scsi mid layer */
+- if (ufshcd_scsi_add_wlus(hba))
++ ret = ufshcd_scsi_add_wlus(hba);
++ if (ret)
+ goto out;
+
+ scsi_scan_host(hba->host);
perf-core-fix-mlock-accounting-in-perf_mmap.patch
rxrpc-fix-service-call-disconnection.patch
asoc-pcm-update-fe-be-trigger-order-based-on-the-com.patch
+rdma-netlink-do-not-always-generate-an-ack-for-some-netlink-operations.patch
+scsi-ufs-fix-ufshcd_probe_hba-reture-value-in-case-ufshcd_scsi_add_wlus-fails.patch
+pci-don-t-disable-bridge-bars-when-assigning-bus-resources.patch
+nfs-nfs_swap-should-depend-on-swap.patch
+nfsv4-try-lease-recovery-on-nfs4err_expired.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
