From: Greg Kroah-Hartman Date: Sun, 16 Oct 2022 11:25:09 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.4.219~140 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=566607cbcb39f6b967ab7c00232b1834cdf2e154;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: mm-mmap-undo-mmap-when-arch_validate_flags-fails.patch pci-sanitise-firmware-bar-assignments-behind-a-pci-pci-bridge.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 serial-8250-let-drivers-request-full-16550a-feature-probing.patch --- diff --git a/queue-5.10/mm-mmap-undo-mmap-when-arch_validate_flags-fails.patch b/queue-5.10/mm-mmap-undo-mmap-when-arch_validate_flags-fails.patch new file mode 100644 index 00000000000..f107459545f --- /dev/null +++ b/queue-5.10/mm-mmap-undo-mmap-when-arch_validate_flags-fails.patch @@ -0,0 +1,112 @@ +From deb0f6562884b5b4beb883d73e66a7d3a1b96d99 Mon Sep 17 00:00:00 2001 +From: Carlos Llamas +Date: Fri, 30 Sep 2022 00:38:43 +0000 +Subject: mm/mmap: undo ->mmap() when arch_validate_flags() fails + +From: Carlos Llamas + +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 + #include + #include + #include + #include + + 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 +Reviewed-by: Catalin Marinas +Acked-by: Andrii Nakryiko +Reviewed-by: Liam Howlett +Cc: Christian Brauner (Microsoft) +Cc: Michal Hocko +Cc: Suren Baghdasaryan +Cc: [5.10+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/pci-sanitise-firmware-bar-assignments-behind-a-pci-pci-bridge.patch b/queue-5.10/pci-sanitise-firmware-bar-assignments-behind-a-pci-pci-bridge.patch new file mode 100644 index 00000000000..ad4c6f07a4d --- /dev/null +++ b/queue-5.10/pci-sanitise-firmware-bar-assignments-behind-a-pci-pci-bridge.patch @@ -0,0 +1,102 @@ +From 0e32818397426a688f598f35d3bc762eca6d7592 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Wed, 21 Sep 2022 20:49:16 +0100 +Subject: PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge + +From: Maciej W. Rozycki + +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 +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org # v2.6.35+ +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.10/powercap-intel_rapl-use-standard-energy-unit-for-spr-dram-rapl-domain.patch b/queue-5.10/powercap-intel_rapl-use-standard-energy-unit-for-spr-dram-rapl-domain.patch new file mode 100644 index 00000000000..87eb62b9c58 --- /dev/null +++ b/queue-5.10/powercap-intel_rapl-use-standard-energy-unit-for-spr-dram-rapl-domain.patch @@ -0,0 +1,35 @@ +From 4c081324df5608b73428662ca54d5221ea03a6bd Mon Sep 17 00:00:00 2001 +From: Zhang Rui +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 + +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 +Tested-by: Wang Wendy +Cc: 5.9+ # 5.9+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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, + }; + diff --git a/queue-5.10/powerpc-boot-explicitly-disable-usage-of-spe-instructions.patch b/queue-5.10/powerpc-boot-explicitly-disable-usage-of-spe-instructions.patch new file mode 100644 index 00000000000..cc28827a896 --- /dev/null +++ b/queue-5.10/powerpc-boot-explicitly-disable-usage-of-spe-instructions.patch @@ -0,0 +1,36 @@ +From 110a58b9f91c66f743c01a2c217243d94c899c23 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +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 + +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 +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20220827134454.17365-1-pali@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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) + diff --git a/queue-5.10/scsi-qedf-populate-sysfs-attributes-for-vport.patch b/queue-5.10/scsi-qedf-populate-sysfs-attributes-for-vport.patch new file mode 100644 index 00000000000..a2e8c767e39 --- /dev/null +++ b/queue-5.10/scsi-qedf-populate-sysfs-attributes-for-vport.patch @@ -0,0 +1,54 @@ +From 592642e6b11e620e4b43189f8072752429fc8dc3 Mon Sep 17 00:00:00 2001 +From: Saurav Kashyap +Date: Mon, 19 Sep 2022 06:44:34 -0700 +Subject: scsi: qedf: Populate sysfs attributes for vport + +From: Saurav Kashyap + +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 +Reviewed-by: John Meneghini +Signed-off-by: Saurav Kashyap +Signed-off-by: Nilesh Javali +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-5.10/serial-8250-let-drivers-request-full-16550a-feature-probing.patch b/queue-5.10/serial-8250-let-drivers-request-full-16550a-feature-probing.patch new file mode 100644 index 00000000000..bb55cc8f991 --- /dev/null +++ b/queue-5.10/serial-8250-let-drivers-request-full-16550a-feature-probing.patch @@ -0,0 +1,62 @@ +From 9906890c89e4dbd900ed87ad3040080339a7f411 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Wed, 21 Sep 2022 00:35:32 +0100 +Subject: serial: 8250: Let drivers request full 16550A feature probing + +From: Maciej W. Rozycki + +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 +Signed-off-by: Maciej W. Rozycki +Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209202357520.41633@angie.orcam.me.uk +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/series b/queue-5.10/series index 974080b0f17..4cf7a94387c 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -39,3 +39,9 @@ nvme-pci-set-min_align_mask-before-calculating-max_hw_sectors.patch 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