--- /dev/null
+From deb0f6562884b5b4beb883d73e66a7d3a1b96d99 Mon Sep 17 00:00:00 2001
+From: Carlos Llamas <cmllamas@google.com>
+Date: Fri, 30 Sep 2022 00:38:43 +0000
+Subject: mm/mmap: undo ->mmap() when arch_validate_flags() fails
+
+From: Carlos Llamas <cmllamas@google.com>
+
+commit deb0f6562884b5b4beb883d73e66a7d3a1b96d99 upstream.
+
+Commit c462ac288f2c ("mm: Introduce arch_validate_flags()") added a late
+check in mmap_region() to let architectures validate vm_flags. The check
+needs to happen after calling ->mmap() as the flags can potentially be
+modified during this callback.
+
+If arch_validate_flags() check fails we unmap and free the vma. However,
+the error path fails to undo the ->mmap() call that previously succeeded
+and depending on the specific ->mmap() implementation this translates to
+reference increments, memory allocations and other operations what will
+not be cleaned up.
+
+There are several places (mainly device drivers) where this is an issue.
+However, one specific example is bpf_map_mmap() which keeps count of the
+mappings in map->writecnt. The count is incremented on ->mmap() and then
+decremented on vm_ops->close(). When arch_validate_flags() fails this
+count is off since bpf_map_mmap_close() is never called.
+
+One can reproduce this issue in arm64 devices with MTE support. Here the
+vm_flags are checked to only allow VM_MTE if VM_MTE_ALLOWED has been set
+previously. From userspace then is enough to pass the PROT_MTE flag to
+mmap() syscall to trigger the arch_validate_flags() failure.
+
+The following program reproduces this issue:
+
+ #include <stdio.h>
+ #include <unistd.h>
+ #include <linux/unistd.h>
+ #include <linux/bpf.h>
+ #include <sys/mman.h>
+
+ int main(void)
+ {
+ union bpf_attr attr = {
+ .map_type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(long long),
+ .max_entries = 256,
+ .map_flags = BPF_F_MMAPABLE,
+ };
+ int fd;
+
+ fd = syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
+ mmap(NULL, 4096, PROT_WRITE | PROT_MTE, MAP_SHARED, fd, 0);
+
+ return 0;
+ }
+
+By manually adding some log statements to the vm_ops callbacks we can
+confirm that when passing PROT_MTE to mmap() the map->writecnt is off upon
+->release():
+
+With PROT_MTE flag:
+ root@debian:~# ./bpf-test
+ [ 111.263874] bpf_map_write_active_inc: map=9 writecnt=1
+ [ 111.288763] bpf_map_release: map=9 writecnt=1
+
+Without PROT_MTE flag:
+ root@debian:~# ./bpf-test
+ [ 157.816912] bpf_map_write_active_inc: map=10 writecnt=1
+ [ 157.830442] bpf_map_write_active_dec: map=10 writecnt=0
+ [ 157.832396] bpf_map_release: map=10 writecnt=0
+
+This patch fixes the above issue by calling vm_ops->close() when the
+arch_validate_flags() check fails, after this we can proceed to unmap and
+free the vma on the error path.
+
+Link: https://lkml.kernel.org/r/20220930003844.1210987-1-cmllamas@google.com
+Fixes: c462ac288f2c ("mm: Introduce arch_validate_flags()")
+Signed-off-by: Carlos Llamas <cmllamas@google.com>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Acked-by: Andrii Nakryiko <andrii@kernel.org>
+Reviewed-by: Liam Howlett <liam.howlett@oracle.com>
+Cc: Christian Brauner (Microsoft) <brauner@kernel.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Suren Baghdasaryan <surenb@google.com>
+Cc: <stable@vger.kernel.org> [5.10+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mmap.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -1856,7 +1856,7 @@ unsigned long mmap_region(struct file *f
+ if (!arch_validate_flags(vma->vm_flags)) {
+ error = -EINVAL;
+ if (file)
+- goto unmap_and_free_vma;
++ goto close_and_free_vma;
+ else
+ goto free_vma;
+ }
+@@ -1900,6 +1900,9 @@ out:
+
+ return addr;
+
++close_and_free_vma:
++ if (vma->vm_ops && vma->vm_ops->close)
++ vma->vm_ops->close(vma);
+ unmap_and_free_vma:
+ vma->vm_file = NULL;
+ fput(file);
--- /dev/null
+From 0e32818397426a688f598f35d3bc762eca6d7592 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Wed, 21 Sep 2022 20:49:16 +0100
+Subject: PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 0e32818397426a688f598f35d3bc762eca6d7592 upstream.
+
+When pci_assign_resource() is unable to assign resources to a BAR, it uses
+pci_revert_fw_address() to fall back to a firmware assignment (if any).
+Previously pci_revert_fw_address() assumed all addresses could reach the
+device, but this is not true if the device is below a bridge that only
+forwards addresses within its windows.
+
+This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS
+did not assign valid addresses to several bridges and USB devices:
+
+ pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff]
+ pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
+ pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff]
+ pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable
+ pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff]
+ pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable
+ pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff]
+ pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable
+ pci 0000:06:08.0: USB UHCI 1.1
+ pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable
+ pci 0000:06:08.1: USB UHCI 1.1
+ pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable
+ pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window
+ pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window
+
+During the first pass of assigning unassigned resources, there was not
+enough I/O space available, so we couldn't assign the 06:08.0 BAR and
+reverted to the firmware assignment (still unreachable). Reverting the
+06:08.1 assignment failed because it conflicted with 06:08.0:
+
+ pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
+ pci 0000:01:00.0: no space for bridge window [io size 0x2000]
+ pci 0000:02:02.0: no space for bridge window [io size 0x1000]
+ pci 0000:05:00.0: no space for bridge window [io size 0x1000]
+ pci 0000:06:08.0: BAR 4: no space for [io size 0x0020]
+ pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
+ pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
+ pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
+ pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff]
+
+A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR,
+but left the 06:08.0 BAR alone, so the UHCI device was still unusable:
+
+ pci 0000:00:11.0: bridge window [io 0xe000-0xefff] released
+ pci 0000:00:11.0: bridge window [io 0x1000-0x2fff] # reassigned
+ pci 0000:01:00.0: bridge window [io 0x1000-0x2fff] # reassigned
+ pci 0000:02:02.0: bridge window [io 0x2000-0x2fff] # reassigned
+ pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] # reassigned
+ pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff] # left alone
+ pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f]
+ ...
+ uhci_hcd 0000:06:08.0: host system error, PCI problems?
+ uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
+ uhci_hcd 0000:06:08.0: host controller halted, very bad!
+ uhci_hcd 0000:06:08.0: HCRESET not completed yet!
+ uhci_hcd 0000:06:08.0: HC died; cleaning up
+
+If the address assigned by firmware is not reachable because it's not
+within upstream bridge windows, fail instead of assigning the unusable
+address from firmware.
+
+[bhelgaas: commit log, use pci_upstream_bridge()]
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk
+Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses")
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org # v2.6.35+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/setup-res.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/pci/setup-res.c
++++ b/drivers/pci/setup-res.c
+@@ -210,6 +210,17 @@ static int pci_revert_fw_address(struct
+
+ root = pci_find_parent_resource(dev, res);
+ if (!root) {
++ /*
++ * If dev is behind a bridge, accesses will only reach it
++ * if res is inside the relevant bridge window.
++ */
++ if (pci_upstream_bridge(dev))
++ return -ENXIO;
++
++ /*
++ * On the root bus, assume the host bridge will forward
++ * everything.
++ */
+ if (res->flags & IORESOURCE_IO)
+ root = &ioport_resource;
+ else
--- /dev/null
+From 4c081324df5608b73428662ca54d5221ea03a6bd Mon Sep 17 00:00:00 2001
+From: Zhang Rui <rui.zhang@intel.com>
+Date: Sat, 24 Sep 2022 13:47:36 +0800
+Subject: powercap: intel_rapl: Use standard Energy Unit for SPR Dram RAPL domain
+
+From: Zhang Rui <rui.zhang@intel.com>
+
+commit 4c081324df5608b73428662ca54d5221ea03a6bd upstream.
+
+Intel Xeon servers used to use a fixed energy resolution (15.3uj) for
+Dram RAPL domain. But on SPR, Dram RAPL domain follows the standard
+energy resolution as described in MSR_RAPL_POWER_UNIT.
+
+Remove the SPR dram_domain_energy_unit quirk.
+
+Fixes: 2d798d9f5967 ("powercap: intel_rapl: add support for Sapphire Rapids")
+Signed-off-by: Zhang Rui <rui.zhang@intel.com>
+Tested-by: Wang Wendy <wendy.wang@intel.com>
+Cc: 5.9+ <stable@vger.kernel.org> # 5.9+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/powercap/intel_rapl_common.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/powercap/intel_rapl_common.c
++++ b/drivers/powercap/intel_rapl_common.c
+@@ -979,7 +979,6 @@ static const struct rapl_defaults rapl_d
+ .check_unit = rapl_check_unit_core,
+ .set_floor_freq = set_floor_freq_default,
+ .compute_time_window = rapl_compute_time_window_core,
+- .dram_domain_energy_unit = 15300,
+ .psys_domain_energy_unit = 1000000000,
+ };
+
--- /dev/null
+From 110a58b9f91c66f743c01a2c217243d94c899c23 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali@kernel.org>
+Date: Sat, 27 Aug 2022 15:44:54 +0200
+Subject: powerpc/boot: Explicitly disable usage of SPE instructions
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Pali Rohár <pali@kernel.org>
+
+commit 110a58b9f91c66f743c01a2c217243d94c899c23 upstream.
+
+uImage boot wrapper should not use SPE instructions, like kernel itself.
+Boot wrapper has already disabled Altivec and VSX instructions but not SPE.
+Options -mno-spe and -mspe=no already set when compilation of kernel, but
+not when compiling uImage wrapper yet. Fix it.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Pali Rohár <pali@kernel.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20220827134454.17365-1-pali@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/boot/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/powerpc/boot/Makefile
++++ b/arch/powerpc/boot/Makefile
+@@ -30,6 +30,7 @@ endif
+
+ BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
+ -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
++ $(call cc-option,-mno-spe) $(call cc-option,-mspe=no) \
+ -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
+ $(LINUXINCLUDE)
+
--- /dev/null
+From 592642e6b11e620e4b43189f8072752429fc8dc3 Mon Sep 17 00:00:00 2001
+From: Saurav Kashyap <skashyap@marvell.com>
+Date: Mon, 19 Sep 2022 06:44:34 -0700
+Subject: scsi: qedf: Populate sysfs attributes for vport
+
+From: Saurav Kashyap <skashyap@marvell.com>
+
+commit 592642e6b11e620e4b43189f8072752429fc8dc3 upstream.
+
+Few vport parameters were displayed by systool as 'Unknown' or 'NULL'.
+Copy speed, supported_speed, frame_size and update port_type for NPIV port.
+
+Link: https://lore.kernel.org/r/20220919134434.3513-1-njavali@marvell.com
+Cc: stable@vger.kernel.org
+Tested-by: Guangwu Zhang <guazhang@redhat.com>
+Reviewed-by: John Meneghini <jmeneghi@redhat.com>
+Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qedf/qedf_main.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+--- a/drivers/scsi/qedf/qedf_main.c
++++ b/drivers/scsi/qedf/qedf_main.c
+@@ -1917,6 +1917,27 @@ static int qedf_vport_create(struct fc_v
+ fc_vport_setlink(vn_port);
+ }
+
++ /* Set symbolic node name */
++ if (base_qedf->pdev->device == QL45xxx)
++ snprintf(fc_host_symbolic_name(vn_port->host), 256,
++ "Marvell FastLinQ 45xxx FCoE v%s", QEDF_VERSION);
++
++ if (base_qedf->pdev->device == QL41xxx)
++ snprintf(fc_host_symbolic_name(vn_port->host), 256,
++ "Marvell FastLinQ 41xxx FCoE v%s", QEDF_VERSION);
++
++ /* Set supported speed */
++ fc_host_supported_speeds(vn_port->host) = n_port->link_supported_speeds;
++
++ /* Set speed */
++ vn_port->link_speed = n_port->link_speed;
++
++ /* Set port type */
++ fc_host_port_type(vn_port->host) = FC_PORTTYPE_NPIV;
++
++ /* Set maxframe size */
++ fc_host_maxframe_size(vn_port->host) = n_port->mfs;
++
+ QEDF_INFO(&(base_qedf->dbg_ctx), QEDF_LOG_NPIV, "vn_port=%p.\n",
+ vn_port);
+
--- /dev/null
+From 9906890c89e4dbd900ed87ad3040080339a7f411 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Wed, 21 Sep 2022 00:35:32 +0100
+Subject: serial: 8250: Let drivers request full 16550A feature probing
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 9906890c89e4dbd900ed87ad3040080339a7f411 upstream.
+
+A SERIAL_8250_16550A_VARIANTS configuration option has been recently
+defined that lets one request the 8250 driver not to probe for 16550A
+device features so as to reduce the driver's device startup time in
+virtual machines.
+
+Some actual hardware devices require these features to have been fully
+determined however for their driver to work correctly, so define a flag
+to let drivers request full 16550A feature probing on a device-by-device
+basis if required regardless of the SERIAL_8250_16550A_VARIANTS option
+setting chosen.
+
+Fixes: dc56ecb81a0a ("serial: 8250: Support disabling mdelay-filled probes of 16550A variants")
+Cc: stable@vger.kernel.org # v5.6+
+Reported-by: Anders Blomdell <anders.blomdell@control.lth.se>
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209202357520.41633@angie.orcam.me.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_port.c | 3 ++-
+ include/linux/serial_core.h | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_port.c
++++ b/drivers/tty/serial/8250/8250_port.c
+@@ -1021,7 +1021,8 @@ static void autoconfig_16550a(struct uar
+ up->port.type = PORT_16550A;
+ up->capabilities |= UART_CAP_FIFO;
+
+- if (!IS_ENABLED(CONFIG_SERIAL_8250_16550A_VARIANTS))
++ if (!IS_ENABLED(CONFIG_SERIAL_8250_16550A_VARIANTS) &&
++ !(up->port.flags & UPF_FULL_PROBE))
+ return;
+
+ /*
+--- a/include/linux/serial_core.h
++++ b/include/linux/serial_core.h
+@@ -100,7 +100,7 @@ struct uart_icount {
+ __u32 buf_overrun;
+ };
+
+-typedef unsigned int __bitwise upf_t;
++typedef u64 __bitwise upf_t;
+ typedef unsigned int __bitwise upstat_t;
+
+ struct uart_port {
+@@ -207,6 +207,7 @@ struct uart_port {
+ #define UPF_FIXED_PORT ((__force upf_t) (1 << 29))
+ #define UPF_DEAD ((__force upf_t) (1 << 30))
+ #define UPF_IOREMAP ((__force upf_t) (1 << 31))
++#define UPF_FULL_PROBE ((__force upf_t) (1ULL << 32))
+
+ #define __UPF_CHANGE_MASK 0x17fff
+ #define UPF_CHANGE_MASK ((__force upf_t) __UPF_CHANGE_MASK)
drm-virtio-check-whether-transferred-2d-bo-is-shmem.patch
drm-udl-restore-display-mode-on-resume.patch
block-fix-inflight-statistics-of-part0.patch
+mm-mmap-undo-mmap-when-arch_validate_flags-fails.patch
+pci-sanitise-firmware-bar-assignments-behind-a-pci-pci-bridge.patch
+serial-8250-let-drivers-request-full-16550a-feature-probing.patch
+powercap-intel_rapl-use-standard-energy-unit-for-spr-dram-rapl-domain.patch
+powerpc-boot-explicitly-disable-usage-of-spe-instructions.patch
+scsi-qedf-populate-sysfs-attributes-for-vport.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
