May 2022 - Linux-stable-mirror

FAILED: patch "[PATCH] PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 92597f97a40bf661bebceb92e26ff87c76d562d4 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 31 Mar 2022 19:38:51 +0200 Subject: [PATCH] PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold If a Root Port on Elo i2 is put into D3cold and then back into D0, the downstream device becomes permanently inaccessible, so add a bridge D3 DMI quirk for that system. This was exposed by 14858dcc3b35 ("PCI: Use pci_update_current_state() in pci_enable_device_flags()"), but before that commit the Root Port in question had never been put into D3cold for real due to a mismatch between its power state retrieved from the PCI_PM_CTRL register (which was accessible even though the platform firmware indicated that the port was in D3cold) and the state of an ACPI power resource involved in its power management. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215715 Link: https://lore.kernel.org/r/11980172.O9o76ZdvQC@kreacher Reported-by: Stefan Gottwald <gottwald(a)igel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org # v5.15+ diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 9ecce435fb3f..d25122fbe98a 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2920,6 +2920,16 @@ static const struct dmi_system_id bridge_d3_blacklist[] = { DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."), DMI_MATCH(DMI_BOARD_NAME, "X299 DESIGNARE EX-CF"), }, + /* + * Downstream device is not accessible after putting a root port + * into D3cold and back into D0 on Elo i2. + */ + .ident = "Elo i2", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Elo Touch Solutions"), + DMI_MATCH(DMI_PRODUCT_NAME, "Elo i2"), + DMI_MATCH(DMI_PRODUCT_VERSION, "RevB"), + }, }, #endif { }

2 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 92597f97a40bf661bebceb92e26ff87c76d562d4 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 31 Mar 2022 19:38:51 +0200 Subject: [PATCH] PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold If a Root Port on Elo i2 is put into D3cold and then back into D0, the downstream device becomes permanently inaccessible, so add a bridge D3 DMI quirk for that system. This was exposed by 14858dcc3b35 ("PCI: Use pci_update_current_state() in pci_enable_device_flags()"), but before that commit the Root Port in question had never been put into D3cold for real due to a mismatch between its power state retrieved from the PCI_PM_CTRL register (which was accessible even though the platform firmware indicated that the port was in D3cold) and the state of an ACPI power resource involved in its power management. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215715 Link: https://lore.kernel.org/r/11980172.O9o76ZdvQC@kreacher Reported-by: Stefan Gottwald <gottwald(a)igel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Cc: stable(a)vger.kernel.org # v5.15+ diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 9ecce435fb3f..d25122fbe98a 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2920,6 +2920,16 @@ static const struct dmi_system_id bridge_d3_blacklist[] = { DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."), DMI_MATCH(DMI_BOARD_NAME, "X299 DESIGNARE EX-CF"), }, + /* + * Downstream device is not accessible after putting a root port + * into D3cold and back into D0 on Elo i2. + */ + .ident = "Elo i2", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Elo Touch Solutions"), + DMI_MATCH(DMI_PRODUCT_NAME, "Elo i2"), + DMI_MATCH(DMI_PRODUCT_VERSION, "RevB"), + }, }, #endif { }

2 years, 7 months

1
0
0 0

[PATCH 1/2] x86/mpparse: avoid overwriting boot_cpu_physical_apicid

by Kevin Mitchell

When booting with ACPI unavailable or disabled, get_smp_config() ends up calling MP_processor_info() for each CPU found in the MPS table. Previously, this resulted in boot_cpu_physical_apicid getting unconditionally overwritten by the apicid of whatever processor had the CPU_BOOTPROCESSOR flag. This occurred even if boot_cpu_physical_apicid had already been more reliably determined in register_lapic_address() by calling read_apic_id() from the actual boot processor. Ordinariliy, this is not a problem because the boot processor really is the one with the CPU_BOOTPROCESSOR flag. However, kexec is an exception in which the kernel may be booted from any processor regardless of the MPS table contents. In this case, boot_cpu_physical_apicid may not indicate the actual boot processor. This was particularly problematic when the second kernel was booted with NR_CPUS fewer than the number of physical processors. It's the job of generic_processor_info() to decide which CPUs to bring up in this case. That obviously must include the real boot processor which it takes care to save a slot for. It relies upon the contents of boot_cpu_physical_apicid to do this, which if incorrect, may result in the boot processor getting left out. This condition can be discovered by smp_sanity_check() and rectified by adding the boot processor to the phys_cpu_present_map with the warning "weird, boot CPU (#%d) not listed by the BIOS". However, commit 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") caused setup_local_APIC() to be called before this could happen resulting in a BUG_ON(!apic->apic_id_registered()): [ 0.655452] ------------[ cut here ]------------ [ 0.660610] Kernel BUG at setup_local_APIC+0x74/0x280 [verbose debug info unavailable] [ 0.669466] invalid opcode: 0000 [#1] SMP [ 0.673948] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.109.Ar-16509018.eostrunkkernel419 #1 [ 0.683670] Hardware name: Quanta Quanta LY6 (1LY6UZZ0FBC), BIOS 1.0.6.0-e7d6a55 11/26/2015 [ 0.693007] RIP: 0010:setup_local_APIC+0x74/0x280 [ 0.698264] Code: 80 e4 fe bf f0 00 00 00 89 c6 48 8b 05 0f 1a 8e 00 ff 50 10 e8 12 53 fd ff 48 8b 05 00 1a 8e 00 ff 90 a0 00 00 00 85 c0 75 02 <0f> 0b 48 8b 05 ed 19 8e 00 41 be 00 02 00 00 ff 90 b0 00 00 00 48 [ 0.719251] RSP: 0000:ffffffff81a03e20 EFLAGS: 00010246 [ 0.725091] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 [ 0.733066] RDX: 0000000000000000 RSI: 000000000000000f RDI: 0000000000000020 [ 0.741041] RBP: ffffffff81a03e98 R08: 0000000000000002 R09: 0000000000000000 [ 0.749014] R10: ffffffff81a204e0 R11: ffffffff81b50ea7 R12: 0000000000000000 [ 0.756989] R13: ffffffff81aef920 R14: ffffffff81af60a0 R15: 0000000000000000 [ 0.764965] FS: 0000000000000000(0000) GS:ffff888036800000(0000) knlGS:0000000000000000 [ 0.774007] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.780427] CR2: ffff888035c01000 CR3: 0000000035a08000 CR4: 00000000000006b0 [ 0.788401] Call Trace: [ 0.791137] ? amd_iommu_prepare+0x15/0x2a [ 0.795717] apic_bsp_setup+0x55/0x75 [ 0.799808] apic_intr_mode_init+0x169/0x16e [ 0.804579] x86_late_time_init+0x10/0x17 [ 0.809062] start_kernel+0x37e/0x3fe [ 0.813154] x86_64_start_reservations+0x2a/0x2c [ 0.818316] x86_64_start_kernel+0x72/0x75 [ 0.822886] secondary_startup_64+0xa4/0xb0 [ 0.827564] ---[ end trace 237b64da0fd9b22e ]--- This change avoids these issues by only setting boot_cpu_physical_apicid from the MPS table if it is not already set, which can occur in the construct_default_ISA_mptable() path. Otherwise, boot_cpu_physical_apicid will already have been set in register_lapic_address() and should therefore remain untouched. Looking through all the places where boot_cpu_physical_apicid is accessed, nearly all of them assume that boot_cpu_physical_apicid should match read_apic_id() on the booting processor. The only place that might intend to use the BSP apicid listed in the MPS table is amd_numa_init(), which explicitly requires boot_cpu_physical_apicid to be the lowest apicid of all processors. Ironically, due to the early exit short circuit in early_get_smp_config(), it instead gets boot_cpu_physical_apicid = read_apic_id() rather than the MPS table BSP. The behaviour of amd_numa_init() is therefore unaffected by this change. Fixes: 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") Signed-off-by: Kevin Mitchell <kevmitch(a)arista.com> Cc: <stable(a)vger.kernel.org> --- arch/x86/kernel/mpparse.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c index afac7ccce72f..6f22f09bfe11 100644 --- a/arch/x86/kernel/mpparse.c +++ b/arch/x86/kernel/mpparse.c @@ -64,7 +64,8 @@ static void __init MP_processor_info(struct mpc_cpu *m) if (m->cpuflag & CPU_BOOTPROCESSOR) { bootup_cpu = " (Bootup-CPU)"; - boot_cpu_physical_apicid = m->apicid; + if (boot_cpu_physical_apicid == -1U) + boot_cpu_physical_apicid = m->apicid; } pr_info("Processor #%d%s\n", m->apicid, bootup_cpu); -- 2.26.2

2 years, 7 months

1
1
0 0

Broken Audio on Stable Kernels for i.MX 7 based Boards

by Philippe Schenker

Hello I noticed today, that commit eccac77ede394 ("clk: imx7d: Remove audio_mclk_root_clk") was backported to stable kernels. This commit by itself does break audio functionality on i.MX 7 based boards. [1] For this to work commit 4cb7df64c73 ("ARM: dts: imx7: Use audio_mclk_post_div instead audio_mclk_root_clk") is also needed but is lacking a Fixes: tag, hence it is missing in stable kernels. [2] I noticed this while merging stable-patches into our downstream- branches. @Abel can you confirm my finding? @Greg could you pull patch [2] into kernels where [1] got merged? Thanks, Philippe [1] https://lore.kernel.org/all/20220127141052.1900174-2-abel.vesa@nxp.com/ [2] https://lore.kernel.org/all/20220127141052.1900174-1-abel.vesa@nxp.com/

2 years, 7 months

3
2
0 0

patch "USB: new quirk for Dell Gen 2 devices" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: new quirk for Dell Gen 2 devices to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From 97fa5887cf283bb75ffff5f6b2c0e71794c02400 Mon Sep 17 00:00:00 2001 From: Monish Kumar R <monish.kumar.r(a)intel.com> Date: Fri, 20 May 2022 18:30:44 +0530 Subject: USB: new quirk for Dell Gen 2 devices Add USB_QUIRK_NO_LPM and USB_QUIRK_RESET_RESUME quirks for Dell usb gen 2 device to not fail during enumeration. Found this bug on own testing Signed-off-by: Monish Kumar R <monish.kumar.r(a)intel.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20220520130044.17303-1-monish.kumar.r@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 97b44a68668a..f99a65a64588 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -510,6 +510,9 @@ static const struct usb_device_id usb_quirk_list[] = { /* DJI CineSSD */ { USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM }, + /* DELL USB GEN2 */ + { USB_DEVICE(0x413c, 0xb062), .driver_info = USB_QUIRK_NO_LPM | USB_QUIRK_RESET_RESUME }, + /* VCOM device */ { USB_DEVICE(0x4296, 0x7570), .driver_info = USB_QUIRK_CONFIG_INTF_STRINGS }, -- 2.36.1

2 years, 7 months

1
0
0 0

patch "USB: new quirk for Dell Gen 2 devices" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: new quirk for Dell Gen 2 devices to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 97fa5887cf283bb75ffff5f6b2c0e71794c02400 Mon Sep 17 00:00:00 2001 From: Monish Kumar R <monish.kumar.r(a)intel.com> Date: Fri, 20 May 2022 18:30:44 +0530 Subject: USB: new quirk for Dell Gen 2 devices Add USB_QUIRK_NO_LPM and USB_QUIRK_RESET_RESUME quirks for Dell usb gen 2 device to not fail during enumeration. Found this bug on own testing Signed-off-by: Monish Kumar R <monish.kumar.r(a)intel.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20220520130044.17303-1-monish.kumar.r@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 97b44a68668a..f99a65a64588 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -510,6 +510,9 @@ static const struct usb_device_id usb_quirk_list[] = { /* DJI CineSSD */ { USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM }, + /* DELL USB GEN2 */ + { USB_DEVICE(0x413c, 0xb062), .driver_info = USB_QUIRK_NO_LPM | USB_QUIRK_RESET_RESUME }, + /* VCOM device */ { USB_DEVICE(0x4296, 0x7570), .driver_info = USB_QUIRK_CONFIG_INTF_STRINGS }, -- 2.36.1

2 years, 7 months

1
0
0 0

[PATCH for-next 3/6] RDMA/hfi1: Fix potential integer multiplication overflow errors

by Dennis Dalessandro

When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Cc: stable(a)vger.kernel.org Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)cornelisnetworks.com> --- drivers/infiniband/hw/hfi1/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/hfi1/init.c b/drivers/infiniband/hw/hfi1/init.c index 4436ed4..436372b 100644 --- a/drivers/infiniband/hw/hfi1/init.c +++ b/drivers/infiniband/hw/hfi1/init.c @@ -489,7 +489,7 @@ void set_link_ipg(struct hfi1_pportdata *ppd) u16 shift, mult; u64 src; u32 current_egress_rate; /* Mbits /sec */ - u32 max_pkt_time; + u64 max_pkt_time; /* * max_pkt_time is the maximum packet egress time in units * of the fabric clock period 1/(805 MHz).

2 years, 7 months

1
0
0 0

[PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)

by Marcelo Roberto Jimenez

Some GPIO lines have stopped working after the patch commit 2ab73c6d8323f ("gpio: Support GPIO controllers without pin-ranges") And this has supposedly been fixed in the following patches commit 89ad556b7f96a ("gpio: Avoid using pin ranges with !PINCTRL") commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not defined") But an erratic behavior where some GPIO lines work while others do not work has been introduced. This patch reverts those changes so that the sysfs-gpio interface works properly again. Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez(a)gmail.com> --- Hi, My system is ARM926EJ-S rev 5 (v5l) (AT91SAM9G25), the board is an ACME Systems Arietta. The system used sysfs-gpio to manage a few gpio lines, and I have noticed that some have stopped working. The test script is very simple: #! /bin/bash cd /sys/class/gpio/ echo 24 > export cd pioA24 echo out > direction echo 0 > value cat value echo 1 > value cat value echo 0 > value cat value echo 1 > value cat value cd .. echo 24 > unexport In a "good" kernel, this script outputs 0, 1, 0, 1. In a bad kernel, the output result is 1, 1, 1, 1. Also it must be possible to run this script twice without errors, that was the issue with the gpiochip_generic_free() call that had been addressed in another patch. In my system PINCTRL is automatically selected by SOC_AT91SAM9 [=y] && ARCH_AT91 [=y] && ARCH_MULTI_V5 [=y] So it is not an option to disable it to make it work. Best regards, Marcelo. drivers/gpio/gpiolib.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index af5bb8fedfea..ac69ec8fb37a 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1804,11 +1804,6 @@ static inline void gpiochip_irqchip_free_valid_mask(struct gpio_chip *gc) */ int gpiochip_generic_request(struct gpio_chip *gc, unsigned offset) { -#ifdef CONFIG_PINCTRL - if (list_empty(&gc->gpiodev->pin_ranges)) - return 0; -#endif - return pinctrl_gpio_request(gc->gpiodev->base + offset); } EXPORT_SYMBOL_GPL(gpiochip_generic_request); @@ -1820,11 +1815,6 @@ EXPORT_SYMBOL_GPL(gpiochip_generic_request); */ void gpiochip_generic_free(struct gpio_chip *gc, unsigned offset) { -#ifdef CONFIG_PINCTRL - if (list_empty(&gc->gpiodev->pin_ranges)) - return; -#endif - pinctrl_gpio_free(gc->gpiodev->base + offset); } EXPORT_SYMBOL_GPL(gpiochip_generic_free); -- 2.30.2

2 years, 7 months

9
27
0 0

[REGRESSION} Re: [PATCH 2/2] x86/pat: add functions to query specific cache mode availability

by Chuck Zmudzinski

On 5/20/2022 10:06 AM, Jan Beulich wrote: > On 20.05.2022 15:33, Chuck Zmudzinski wrote: >> On 5/20/2022 5:41 AM, Jan Beulich wrote: >>> On 20.05.2022 10:30, Chuck Zmudzinski wrote: >>>> On 5/20/2022 2:59 AM, Chuck Zmudzinski wrote: >>>>> On 5/20/2022 2:05 AM, Jan Beulich wrote: >>>>>> On 20.05.2022 06:43, Chuck Zmudzinski wrote: >>>>>>> On 5/4/22 5:14 AM, Juergen Gross wrote: >>>>>>>> On 04.05.22 10:31, Jan Beulich wrote: >>>>>>>>> On 03.05.2022 15:22, Juergen Gross wrote: >>>>>>>>> >>>>>>>>> ... these uses there are several more. You say nothing on why >>>>>>>>> those want >>>>>>>>> leaving unaltered. When preparing my earlier patch I did inspect them >>>>>>>>> and came to the conclusion that these all would also better >>>>>>>>> observe the >>>>>>>>> adjusted behavior (or else I couldn't have left pat_enabled() as the >>>>>>>>> only predicate). In fact, as said in the description of my earlier >>>>>>>>> patch, in >>>>>>>>> my debugging I did find the use in i915_gem_object_pin_map() to be >>>>>>>>> the >>>>>>>>> problematic one, which you leave alone. >>>>>>>> Oh, I missed that one, sorry. >>>>>>> That is why your patch would not fix my Haswell unless >>>>>>> it also touches i915_gem_object_pin_map() in >>>>>>> drivers/gpu/drm/i915/gem/i915_gem_pages.c >>>>>>> >>>>>>>> I wanted to be rather defensive in my changes, but I agree at least >>>>>>>> the >>>>>>>> case in arch_phys_wc_add() might want to be changed, too. >>>>>>> I think your approach needs to be more aggressive so it will fix >>>>>>> all the known false negatives introduced by bdd8b6c98239 >>>>>>> such as the one in i915_gem_object_pin_map(). >>>>>>> >>>>>>> I looked at Jan's approach and I think it would fix the issue >>>>>>> with my Haswell as long as I don't use the nopat option. I >>>>>>> really don't have a strong opinion on that question, but I >>>>>>> think the nopat option as a Linux kernel option, as opposed >>>>>>> to a hypervisor option, should only affect the kernel, and >>>>>>> if the hypervisor provides the pat feature, then the kernel >>>>>>> should not override that, >>>>>> Hmm, why would the kernel not be allowed to override that? Such >>>>>> an override would affect only the single domain where the >>>>>> kernel runs; other domains could take their own decisions. >>>>>> >>>>>> Also, for the sake of completeness: "nopat" used when running on >>>>>> bare metal has the same bad effect on system boot, so there >>>>>> pretty clearly is an error cleanup issue in the i915 driver. But >>>>>> that's orthogonal, and I expect the maintainers may not even care >>>>>> (but tell us "don't do that then"). >>>> Actually I just did a test with the last official Debian kernel >>>> build of Linux 5.16, that is, a kernel before bdd8b6c98239 was >>>> applied. In fact, the nopat option does *not* break the i915 driver >>>> in 5.16. That is, with the nopat option, the i915 driver loads >>>> normally on both the bare metal and on the Xen hypervisor. >>>> That means your presumption (and the presumption of >>>> the author of bdd8b6c98239) that the "nopat" option was >>>> being observed by the i915 driver is incorrect. Setting "nopat" >>>> had no effect on my system with Linux 5.16. So after doing these >>>> tests, I am against the aggressive approach of breaking the i915 >>>> driver with the "nopat" option because prior to bdd8b6c98239, >>>> nopat did not break the i915 driver. Why break it now? >>> Because that's, in my understanding, is the purpose of "nopat" >>> (not breaking the driver of course - that's a driver bug -, but >>> having an effect on the driver). >> I wouldn't call it a driver bug, but an incorrect configuration of the >> kernel by the user. I presume X86_FEATURE_PAT is required by the >> i915 driver > The driver ought to work fine without PAT (and hence without being > able to make WC mappings). It would use UC instead and be slow, but > it ought to work. I am not an expert, but I think the reason it failed on my box was because of the requirements of CI. Maybe the driver would fall back to UC if the add_taint_for_CI function did not halt the entire system in response to the failed test for PAT when trying to use WC mappings. >> and therefore the driver should refuse to disable >> it if the user requests to disable it and instead warn the user that >> the driver did not disable the feature, contrary to what the user >> requested with the nopat option. >> >> In any case, my test did not verify that when nopat is set in Linux 5.16, >> the thread takes the same code path as when nopat is not set, >> so I am not totally sure that the reason nopat does not break the >> i915 driver in 5.16 is that static_cpu_has(X86_FEATURE_PAT) >> returns true even when nopat is set. I could test it with a custom >> log message in 5.16 if that is necessary. >> >> Are you saying it was wrong for >> to return true in 5.16 when the user requests nopat? > No, I'm not saying that. It was wrong for this construct to be used > in the driver, which was fixed for 5.17 (and which had caused the > regression I did observe, leading to the patch as a hopefully least > bad option). Hmm, the patch I used to fix my box with 5.17.6 used static_cpu_has(X86_FEATURE_PAT) so the driver could continue to configure the hardware using WC. This is the relevant part of the patch I used to fix my box, which includes extra error logs, (against Debian's official build of 5.17.6): --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 2022-05-09 03:16:33.000000000 -0400 +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c 2022-05-19 15:55:40.339778818 -0400 ... @@ -430,17 +434,23 @@ err = i915_gem_object_wait_moving_fence(obj, true); if (err) { ptr = ERR_PTR(err); + DRM_ERROR("i915_gem_object_wait_moving_fence error, err = %d\n", err); goto err_unpin; } - if (GEM_WARN_ON(type == I915_MAP_WC && !pat_enabled())) + if (GEM_WARN_ON(type == I915_MAP_WC && + !pat_enabled() && !static_cpu_has(X86_FEATURE_PAT))) { + DRM_ERROR("type == I915_MAP_WC && !pat_enabled(), err = %d\n", -ENODEV); ptr = ERR_PTR(-ENODEV); + } else if (i915_gem_object_has_struct_page(obj)) ptr = i915_gem_object_map_page(obj, type); else ptr = i915_gem_object_map_pfn(obj, type); - if (IS_ERR(ptr)) + if (IS_ERR(ptr)) { + DRM_ERROR("IS_ERR(PTR) is true, returning a (ptr) error\n"); goto err_unpin; + } obj->mm.mapping = page_pack_bits(ptr, type); } As you can see, adding the static_cpu_has(X86_FEATURE_PAT) function to the test for PAT restored the behavior of 5.16 on the Xen hypervisor to 5.17, and that is how I discovered the solution to this problem on 5.17 on my box. >> I think that is >> just permitting a bad configuration to break the driver that a >> well-written operating system should not allow. The i915 driver >> was, in my opinion, correctly ignoring the nopat option in 5.16 >> because that option is not compatible with the hardware the >> i915 driver is trying to initialize and setup at boot time. At least >> that is my understanding now, but I will need to test it on 5.16 >> to be sure I understand it correctly. >> >> Also, AFAICT, your patch would break the driver when the nopat >> option is set and only fix the regression introduced by bdd8b6c98239 >> when nopat is not set on my box, so your patch would >> introduce a regression relative to Linux 5.16 and earlier for the >> case when nopat is set on my box. I think your point would >> be that it is not a regression if it is an incorrect user configuration. > Again no - my view is that there's a separate, pre-existing issue > in the driver which was uncovered by the change. This may be a > perceived regression, but is imo different from a real one. Maybe it is only a perceived regression if nopat is set, but imo bdd8b6c98239 introduced a real regression in 5.17 relative to 5.16 for the correctly and identically configured case when the nopat option is not set. That is why I still think it should be reverted and the fix backported to 5.17 until the regression for the case when nopat is not set is fixed. As I said before, the i915 driver relies on the memory subsyste to provide it with an accurate test for the x86 pat feature. The test the driver used in bdd8b6c98239 gives the i915 driver a false negative, and that caused a real regression when nopat is not set. bdd8b6c98239 can be re-applied if we apply your patch which corrects the false negative that pat_enabled() is currently providing the i915 driver with. That false negative from pat_enabled() is not an i915 bug, it is a bug in x86/pat. Chuck

2 years, 7 months

1
2
0 0

Linux 5.17.5

by Greg Kroah-Hartman

I'm announcing the release of the 5.17.5 kernel. All users of the 5.17 kernel series must upgrade. The updated 5.17.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.17.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/filesystems/ext4/attributes.rst | 2 Makefile | 2 arch/arc/kernel/entry.S | 1 arch/arm/mach-vexpress/spc.c | 2 arch/arm/xen/enlighten.c | 9 - arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi | 8 - arch/arm64/boot/dts/freescale/imx8mn-var-som.dtsi | 8 - arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 arch/arm64/include/asm/pgtable.h | 4 arch/powerpc/kernel/time.c | 29 +--- arch/powerpc/kvm/book3s_64_vio.c | 45 +++--- arch/powerpc/kvm/book3s_64_vio_hv.c | 44 +++--- arch/powerpc/perf/power10-pmu.c | 2 arch/powerpc/perf/power9-pmu.c | 8 - arch/riscv/kvm/vcpu.c | 21 +- arch/x86/include/asm/compat.h | 6 arch/x86/include/asm/kvm_host.h | 4 arch/x86/kvm/hyperv.c | 40 +---- arch/x86/kvm/hyperv.h | 2 arch/x86/kvm/pmu.h | 9 + arch/x86/kvm/svm/pmu.c | 1 arch/x86/kvm/svm/sev.c | 61 +++----- arch/x86/kvm/vmx/nested.c | 5 arch/x86/kvm/vmx/pmu_intel.c | 8 - arch/x86/kvm/vmx/vmx.c | 5 arch/x86/kvm/vmx/vmx.h | 1 arch/x86/kvm/x86.c | 29 ++-- arch/xtensa/kernel/coprocessor.S | 4 arch/xtensa/kernel/jump_label.c | 2 block/ioctl.c | 2 drivers/ata/pata_marvell.c | 2 drivers/dma/at_xdmac.c | 12 - drivers/dma/dw-edma/dw-edma-v0-core.c | 7 drivers/dma/idxd/device.c | 6 drivers/dma/idxd/submit.c | 5 drivers/dma/idxd/sysfs.c | 6 drivers/dma/imx-sdma.c | 32 ++-- drivers/dma/mediatek/mtk-uart-apdma.c | 9 - drivers/edac/synopsys_edac.c | 16 +- drivers/firmware/cirrus/cs_dsp.c | 3 drivers/gpio/gpiolib.c | 4 drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 4 drivers/gpu/drm/i915/display/intel_psr.c | 38 ++--- drivers/gpu/drm/msm/adreno/adreno_device.c | 17 -- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 2 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 13 + drivers/gpu/drm/radeon/radeon_sync.c | 2 drivers/gpu/drm/vc4/vc4_dsi.c | 2 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 43 ++---- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 - drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 drivers/input/keyboard/omap4-keypad.c | 2 drivers/net/ethernet/Kconfig | 26 +-- drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 8 - drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 8 - drivers/net/ethernet/aquantia/atlantic/aq_vec.c | 24 +-- drivers/net/ethernet/cadence/macb_main.c | 8 + drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 8 - drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 drivers/net/ethernet/intel/ice/ice_eswitch.c | 3 drivers/net/ethernet/intel/ice/ice_eswitch.h | 2 drivers/net/ethernet/intel/ice/ice_nvm.c | 1 drivers/net/ethernet/intel/igc/igc_i225.c | 11 + drivers/net/ethernet/intel/igc/igc_phy.c | 4 drivers/net/ethernet/intel/igc/igc_ptp.c | 15 +- drivers/net/ethernet/mscc/ocelot.c | 2 drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 4 drivers/net/vxlan.c | 4 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 drivers/net/wireless/mediatek/mt76/mt76x2/pci.c | 2 drivers/nvme/host/core.c | 24 ++- drivers/nvme/host/nvme.h | 5 drivers/nvme/host/pci.c | 9 + drivers/perf/arm_pmu.c | 10 - drivers/platform/x86/samsung-laptop.c | 2 drivers/reset/reset-rzg2l-usbphy-ctrl.c | 4 drivers/reset/tegra/reset-bpmp.c | 9 + drivers/scsi/bnx2i/bnx2i_hwi.c | 2 drivers/scsi/bnx2i/bnx2i_iscsi.c | 2 drivers/scsi/cxgbi/libcxgbi.c | 6 drivers/scsi/libiscsi.c | 27 ++- drivers/scsi/libiscsi_tcp.c | 2 drivers/scsi/qedi/qedi_iscsi.c | 69 ++++----- drivers/scsi/scsi_transport_iscsi.c | 71 ++++------ drivers/scsi/sr_ioctl.c | 15 +- drivers/scsi/ufs/ufshcd.c | 5 drivers/spi/atmel-quadspi.c | 3 drivers/spi/spi-cadence-quadspi.c | 19 ++ drivers/spi/spi-mtk-nor.c | 12 + fs/cifs/cifsfs.c | 2 fs/cifs/connect.c | 11 + fs/cifs/dfs_cache.c | 19 +- fs/ext4/ext4.h | 7 fs/ext4/extents.c | 32 +++- fs/ext4/inode.c | 18 ++ fs/ext4/ioctl.c | 16 ++ fs/ext4/namei.c | 4 fs/ext4/page-io.c | 4 fs/ext4/super.c | 21 ++ fs/gfs2/rgrp.c | 9 - fs/hugetlbfs/inode.c | 9 - fs/io_uring.c | 11 - fs/jbd2/commit.c | 4 fs/namei.c | 22 +-- fs/posix_acl.c | 10 + fs/stat.c | 19 +- fs/xattr.c | 6 include/linux/etherdevice.h | 5 include/linux/memcontrol.h | 5 include/linux/posix_acl_xattr.h | 4 include/linux/sched.h | 1 include/linux/sched/mm.h | 8 + include/net/esp.h | 2 include/net/netns/ipv6.h | 4 include/scsi/libiscsi.h | 9 - include/scsi/scsi_transport_iscsi.h | 2 kernel/events/core.c | 2 kernel/events/internal.h | 5 kernel/events/ring_buffer.c | 5 kernel/irq_work.c | 2 kernel/sched/fair.c | 10 - lib/xarray.c | 2 mm/memcontrol.c | 12 + mm/memory-failure.c | 13 + mm/mmap.c | 8 - mm/mmu_notifier.c | 14 + mm/oom_kill.c | 54 +++++-- mm/userfaultfd.c | 15 +- mm/workingset.c | 2 net/can/isotp.c | 10 + net/dsa/tag_hellcreek.c | 8 + net/ipv4/esp4.c | 5 net/ipv6/esp6.c | 5 net/ipv6/ip6_gre.c | 14 + net/ipv6/route.c | 11 - net/l3mdev/l3mdev.c | 2 net/netlink/af_netlink.c | 7 net/openvswitch/flow_netlink.c | 2 net/packet/af_packet.c | 13 + net/rxrpc/net_ns.c | 2 net/sched/cls_u32.c | 24 +-- net/smc/af_smc.c | 4 sound/hda/intel-dsp-config.c | 18 ++ sound/pci/hda/patch_hdmi.c | 6 sound/pci/hda/patch_realtek.c | 1 sound/soc/atmel/sam9g20_wm8731.c | 61 -------- sound/soc/codecs/msm8916-wcd-digital.c | 9 + sound/soc/codecs/rk817_codec.c | 2 sound/soc/codecs/rt5682.c | 11 - sound/soc/codecs/rt5682s.c | 11 - sound/soc/codecs/wcd934x.c | 26 --- sound/soc/soc-dapm.c | 6 sound/soc/soc-topology.c | 4 sound/soc/sof/topology.c | 43 ++++++ sound/usb/midi.c | 1 sound/usb/mixer_maps.c | 4 sound/usb/usbaudio.h | 2 tools/lib/perf/evlist.c | 3 tools/perf/builtin-report.c | 14 + tools/perf/builtin-script.c | 2 tools/testing/selftests/drivers/net/mlxsw/spectrum-2/vxlan_flooding_ipv6.sh | 17 ++ tools/testing/selftests/drivers/net/mlxsw/vxlan_flooding.sh | 17 ++ tools/testing/selftests/kvm/aarch64/arch_timer.c | 15 +- 166 files changed, 1109 insertions(+), 724 deletions(-) Adrian Hunter (1): perf tools: Fix segfault accessing sample_id xyarray Alex Elder (1): arm64: dts: qcom: add IPA qcom,qmp property Alexey Kardashevskiy (1): KVM: PPC: Fix TCE handling for VFIO Alistair Popple (1): mm/mmu_notifier.c: fix race in mmu_interval_notifier_remove() Allen-KH Cheng (1): spi: spi-mtk-nor: initialize spi controller after resume Athira Rajeev (2): powerpc/perf: Fix power9 event alternatives powerpc/perf: Fix power10 event alternatives Atish Patra (2): RISC-V: KVM: Remove 's' & 'u' as valid ISA extension RISC-V: KVM: Restrict the extensions that can be disabled Bob Peterson (1): gfs2: assign rgrp glock before compute_bitstructs Borislav Petkov (3): ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant mt76: Fix undefined behavior due to shift overflowing the constant brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant Christian Brauner (1): fs: fix acl translation Christian König (1): drm/radeon: fix logic inversion in radeon_sync_resv Christoph Hellwig (3): nvme: add a quirk to disable namespace identifiers nvme-pci: disable namespace identifiers for the MAXIO MAP1002/1202 nvme-pci: disable namespace identifiers for Qemu controllers Christophe Leroy (1): mm, hugetlb: allow for "high" userspace addresses Darrick J. Wong (1): ext4: fix fallocate to use file_modified to update permissions consistently Dave Jiang (6): dmaengine: idxd: fix device cleanup on disable dmaengine: idxd: match type for retries var in idxd_enqcmds() dmaengine: idxd: fix retry value to be constant for duration of function call dmaengine: idxd: add RO check for wq max_batch_size write dmaengine: idxd: add RO check for wq max_transfer_size write dmaengine: idxd: skip clearing device context when device is read-only Dave Stevenson (2): drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare David Ahern (1): l3mdev: l3mdev_master_upper_ifindex_by_index_rcu should be using netdev_master_upper_dev_get_rcu David Howells (2): rxrpc: Restore removed timer deletion cifs: Check the IOCB_DIRECT flag, not O_DIRECT Eric Dumazet (4): net/sched: cls_u32: fix netns refcount changes in u32_change() net/sched: cls_u32: fix possible leak in u32_init_knode() ipv6: make ip6_rt_gc_expire an atomic_t netlink: reset network and mac headers in netlink_dump() Greg Kroah-Hartman (1): Linux 5.17.5 Guo Ren (1): xtensa: patch_text: Fixup last cpu should be master Hangbin Liu (1): net/packet: fix packet_sock xmit return value checking Heiner Kallweit (1): reset: renesas: Check return value of reset_control_deassert() Herve Codina (1): dmaengine: dw-edma: Fix unaligned 64bit access Hongbin Wang (1): vxlan: fix error return code in vxlan_fdb_append Ido Schimmel (2): selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets Jens Axboe (1): io_uring: free iovec if file assignment fails Jianglei Nie (1): ice: Fix memory leak in ice_get_orom_civd_data() Jiapeng Chong (1): platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative José Roberto de Souza (1): drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails Kai Vehmanen (1): ALSA: hda/hdmi: fix warning about PCM count when used with SOF Kai-Heng Feng (1): net: atlantic: Avoid out-of-bounds indexing Kees Cook (2): etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead ARM: vexpress/spc: Avoid negative array index when !SMP Kevin Groeneveld (1): dmaengine: imx-sdma: fix init of uart scripts Kevin Hao (1): net: stmmac: Use readl_poll_timeout_atomic() in atomic state Khazhismel Kumykov (1): block/compat_ioctl: fix range check in BLKGETSIZE Kurt Kanzenbach (1): net: dsa: hellcreek: Calculate checksums in tagger Leo Yan (2): perf script: Always allow field 'data_src' for auxtrace perf report: Set PERF_SAMPLE_DATA_SRC bit for Arm SPE event Like Xu (1): KVM: x86/pmu: Update AMD PMC sample period to fix guest NMI-watchdog Lv Ruyi (1): dpaa_eth: Fix missing of_node_put in dpaa_get_ts_info() Maciej Fijalkowski (1): ice: allow creating VFs for !CONFIG_NET_SWITCHDEV Manuel Ullmann (1): net: atlantic: invert deep par in pm functions, preventing null derefs Mario Limonciello (1): gpio: Request interrupts after IRQ is initialized Mark Brown (1): ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek Matthew Wilcox (Oracle) (1): XArray: Disallow sibling entries of nodes Matthias Schiffer (1): spi: cadence-quadspi: fix incorrect supports_op() return value Maurizio Avogadro (1): ALSA: usb-audio: add mapping for MSI MAG X570S Torpedo MAX. Max Filippov (1): xtensa: fix a7 clobbering in coprocessor context load/store Miaoqian Lin (6): ASoC: rk817: Use devm_clk_get() in rk817_platform_probe ASoC: msm8916-wcd-digital: Check failure for devm_snd_soc_register_component dmaengine: imx-sdma: Fix error checking in sdma_event_remap Input: omap4-keypad - fix pm_runtime_get_sync() error checking drm/vc4: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage arm/xen: Fix some refcount leaks Michael Ellerman (1): powerpc/time: Always set decrementer in timer_interrupt() Mike Christie (4): scsi: iscsi: Release endpoint ID when its freed scsi: iscsi: Merge suspend fields scsi: iscsi: Fix NOP handling during conn recovery scsi: qedi: Fix failed disconnect handling Mikulas Patocka (1): stat: fix inconsistency between struct stat and struct compat_stat Mingwei Zhang (1): KVM: SVM: Flush when freeing encrypted pages even on SME_COHERENT CPUs Muchun Song (1): arm64: mm: fix p?d_leaf() Nadav Amit (1): userfaultfd: mark uffd_wp regardless of VM_WRITE flag NeilBrown (1): VFS: filename_create(): fix incorrect intent. Nicholas Kazlauskas (1): drm/amd/display: Only set PSR version when valid Nico Pache (1): oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup Oliver Hartkopp (1): can: isotp: stop timeout monitoring when no first frame was sent Oliver Upton (1): selftests: KVM: Free the GIC FD when cleaning up in arch_timer Paolo Valerio (1): openvswitch: fix OOB access in reserve_sfa_size() Paulo Alcantara (2): cifs: fix NULL ptr dereference in refresh_mounts() cifs: use correct lock type in cifs_reconnect() Pavel Begunkov (1): io_uring: fix leaks on IOPOLL and CQE_SKIP Peilin Ye (2): ip6_gre: Avoid updating tunnel->tun_hlen in __gre6_xmit() ip6_gre: Fix skb_under_panic in __gre6_xmit() Peter Ujfalusi (1): ASoC: topology: Correct error handling in soc_tplg_dapm_widget_create() Peter Wang (1): scsi: ufs: core: scsi_get_lba() error fix Pierre-Louis Bossart (2): ALSA: hda: intel-dsp-config: update AlderLake PCI IDs ASoC: SOF: topology: cleanup dailinks on widget unload Richard Fitzgerald (1): firmware: cs_dsp: Fix overrun of unterminated control name string Rob Clark (2): drm/msm/gpu: Rename runtime suspend/resume functions drm/msm/gpu: Remove mutex from wait_event condition Rob Herring (2): arm64: dts: imx: Fix imx8*-var-som touchscreen property sizes arm_pmu: Validate single/group leader events Sabrina Dubroca (1): esp: limit skb_page_frag_refill use to a single page Sameer Pujar (1): reset: tegra-bpmp: Restore Handle errors in BPMP response Sasha Neftin (3): igc: Fix infinite loop in release_swfw_sync igc: Fix BUG: scheduling while atomic e1000e: Fix possible overflow in LTR decoding Sean Christopherson (4): KVM: x86: Don't re-acquire SRCU lock in complete_emulated_io() KVM: x86: Pend KVM_REQ_APICV_UPDATE during vCPU creation to fix a race KVM: nVMX: Defer APICv updates while L2 is active until L1 is active KVM: SVM: Simplify and harden helper to flush SEV guest page(s) Sergey Matyukevich (1): ARC: entry: fix syscall_trace_exit argument Shakeel Butt (1): memcg: sync flush only if periodic flush is delayed Shubhrajyoti Datta (1): EDAC/synopsys: Read the error count from the correct register Srinivas Kandagatla (1): ASoC: codecs: wcd934x: do not switch off SIDO Buck when codec is in use Stephen Hemminger (1): net: restore alpha order to Ethernet devices in config Tadeusz Struk (1): ext4: limit length to bitmap_maxbytes - blocksize in punch_hole Takashi Iwai (1): ALSA: usb-audio: Clear MIDI port active flag after draining Theodore Ts'o (3): ext4: fix overhead calculation to account for the reserved gdt blocks ext4: force overhead calculation if the s_overhead_cluster makes no sense ext4: update the cached overhead value in the superblock Tim Crawford (1): ALSA: hda/realtek: Add quirk for Clevo NP70PNP Tom Rix (1): scsi: sr: Do not leak information in ioctl Tomas Melin (1): net: macb: Restart tx only if queue pointer is lagging Tony Lu (1): net/smc: Fix sock leak when release after smc_shutdown() Tudor Ambarus (1): spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controller Vinicius Costa Gomes (1): igc: Fix suspending when PTM is active Vitaly Kuznetsov (1): KVM: x86: hyper-v: Avoid writing to TSC page without an active vCPU Vladimir Oltean (1): net: mscc: ocelot: fix broken IP multicast flooding Wojciech Drewek (1): ice: fix crash in switchdev mode Xiaoke Wang (2): drm/msm/disp: check the return value of kzalloc() drm/msm/mdp5: check the return of kzalloc() Xiaomeng Tong (4): dma: at_xdmac: fix a missing check on list iterator ASoC: rt5682: fix an incorrect NULL check on list iterator ASoC: soc-dapm: fix two incorrect uses of list iterator codecs: rt5682s: fix an incorrect NULL check on list iterator Xu Yu (1): mm/memory-failure.c: skip huge_zero_page in memory_failure() Ye Bin (3): ext4: fix symlink file size not match to file content ext4: fix use-after-free in ext4_search_dir jbd2: fix a potential race while discarding reserved buffers after an abort Zack Rusin (1): drm/vmwgfx: Fix gem refcounting and memory evictions Zheyu Ma (1): ata: pata_marvell: Check the 'bmdma_addr' beforing reading Zhipeng Xie (1): perf/core: Fix perf_mmap fail when CONFIG_PERF_USE_VMALLOC enabled Zqiang (1): irq_work: use kasan_record_aux_stack_noalloc() record callstack kuyo chang (1): sched/pelt: Fix attach_entity_load_avg() corner case wangjianjian (C) (1): ext4, doc: fix incorrect h_reserved size zhangqilong (1): dmaengine: mediatek:Fix PM usage reference leak of mtk_uart_apdma_alloc_chan_resources

2 years, 7 months

5
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2022