From: Sasha Levin Date: Sun, 4 Dec 2022 23:57:12 +0000 (-0500) Subject: Fixes for 5.4 X-Git-Tag: v4.9.335~37^2~3 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1ed0de22005ba30f38cf3754fd20c49a76b1d95e;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/revert-clocksource-drivers-riscv-events-are-stopped-.patch b/queue-5.4/revert-clocksource-drivers-riscv-events-are-stopped-.patch new file mode 100644 index 00000000000..fa47ed9ba79 --- /dev/null +++ b/queue-5.4/revert-clocksource-drivers-riscv-events-are-stopped-.patch @@ -0,0 +1,96 @@ +From 42c9c13b436b97d16cd014df8c0b27dddcace86a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Nov 2022 12:16:21 +0000 +Subject: Revert "clocksource/drivers/riscv: Events are stopped during CPU + suspend" + +From: Conor Dooley + +[ Upstream commit d9f15a9de44affe733e34f93bc184945ba277e6d ] + +This reverts commit 232ccac1bd9b5bfe73895f527c08623e7fa0752d. + +On the subject of suspend, the RISC-V SBI spec states: + + This does not cover whether any given events actually reach the hart or + not, just what the hart will do if it receives an event. On PolarFire + SoC, and potentially other SiFive based implementations, events from the + RISC-V timer do reach a hart during suspend. This is not the case for the + implementation on the Allwinner D1 - there timer events are not received + during suspend. + +To fix this, the CLOCK_EVT_FEAT_C3STOP (mis)feature was enabled for the +timer driver - but this has broken both RCU stall detection and timers +generally on PolarFire SoC and potentially other SiFive based +implementations. + +If an AXI read to the PCIe controller on PolarFire SoC times out, the +system will stall, however, with CLOCK_EVT_FEAT_C3STOP active, the system +just locks up without RCU stalling: + + io scheduler mq-deadline registered + io scheduler kyber registered + microchip-pcie 2000000000.pcie: host bridge /soc/pcie@2000000000 ranges: + microchip-pcie 2000000000.pcie: MEM 0x2008000000..0x2087ffffff -> 0x0008000000 + microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer + microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer + microchip-pcie 2000000000.pcie: axi read request error + microchip-pcie 2000000000.pcie: axi read timeout + microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer + microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer + microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer + microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer + microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer + microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer + Freeing initrd memory: 7332K + +Similarly issues were reported with clock_nanosleep() - with a test app +that sleeps each cpu for 6, 5, 4, 3 ms respectively, HZ=250 & the blamed +commit in place, the sleep times are rounded up to the next jiffy: + +== CPU: 1 == == CPU: 2 == == CPU: 3 == == CPU: 4 == +Mean: 7.974992 Mean: 7.976534 Mean: 7.962591 Mean: 3.952179 +Std Dev: 0.154374 Std Dev: 0.156082 Std Dev: 0.171018 Std Dev: 0.076193 +Hi: 9.472000 Hi: 10.495000 Hi: 8.864000 Hi: 4.736000 +Lo: 6.087000 Lo: 6.380000 Lo: 4.872000 Lo: 3.403000 +Samples: 521 Samples: 521 Samples: 521 Samples: 521 + +Fortunately, the D1 has a second timer, which is "currently used in +preference to the RISC-V/SBI timer driver" so a revert here does not +hurt operation of D1 in its current form. + +Ultimately, a DeviceTree property (or node) will be added to encode the +behaviour of the timers, but until then revert the addition of +CLOCK_EVT_FEAT_C3STOP. + +Fixes: 232ccac1bd9b ("clocksource/drivers/riscv: Events are stopped during CPU suspend") +Signed-off-by: Conor Dooley +Signed-off-by: Thomas Gleixner +Reviewed-by: Palmer Dabbelt +Acked-by: Palmer Dabbelt +Acked-by: Samuel Holland +Link: https://lore.kernel.org/linux-riscv/YzYTNQRxLr7Q9JR0@spud/ +Link: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/98/ +Link: https://lore.kernel.org/linux-riscv/bf6d3b1f-f703-4a25-833e-972a44a04114@sholland.org/ +Link: https://lore.kernel.org/r/20221122121620.3522431-1-conor.dooley@microchip.com +Signed-off-by: Sasha Levin +--- + drivers/clocksource/timer-riscv.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c +index e3be5c2f57b8..4b04ffbe5e7e 100644 +--- a/drivers/clocksource/timer-riscv.c ++++ b/drivers/clocksource/timer-riscv.c +@@ -26,7 +26,7 @@ static int riscv_clock_next_event(unsigned long delta, + + static DEFINE_PER_CPU(struct clock_event_device, riscv_clock_event) = { + .name = "riscv_timer_clockevent", +- .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP, ++ .features = CLOCK_EVT_FEAT_ONESHOT, + .rating = 100, + .set_next_event = riscv_clock_next_event, + }; +-- +2.35.1 + diff --git a/queue-5.4/series b/queue-5.4/series index b37cdf47335..e93fdb0d833 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -153,3 +153,5 @@ nvme-ensure-subsystem-reset-is-single-threaded.patch x86-tsx-add-a-feature-bit-for-tsx-control-msr-support.patch x86-pm-add-enumeration-check-before-spec-msrs-save-restore-setup.patch bluetooth-l2cap-fix-accepting-connection-request-for-invalid-spsm.patch +x86-ioremap-fix-page-aligned-size-calculation-in-__i.patch +revert-clocksource-drivers-riscv-events-are-stopped-.patch diff --git a/queue-5.4/x86-ioremap-fix-page-aligned-size-calculation-in-__i.patch b/queue-5.4/x86-ioremap-fix-page-aligned-size-calculation-in-__i.patch new file mode 100644 index 00000000000..2a129bd074a --- /dev/null +++ b/queue-5.4/x86-ioremap-fix-page-aligned-size-calculation-in-__i.patch @@ -0,0 +1,54 @@ +From 550a07b48b1575d1773308cb5ecadbec93c9dcfe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 4 Dec 2022 13:52:01 -0800 +Subject: x86/ioremap: Fix page aligned size calculation in __ioremap_caller() + +From: Michael Kelley + +[ Upstream commit 4dbd6a3e90e03130973688fd79e19425f720d999 ] + +Current code re-calculates the size after aligning the starting and +ending physical addresses on a page boundary. But the re-calculation +also embeds the masking of high order bits that exceed the size of +the physical address space (via PHYSICAL_PAGE_MASK). If the masking +removes any high order bits, the size calculation results in a huge +value that is likely to immediately fail. + +Fix this by re-calculating the page-aligned size first. Then mask any +high order bits using PHYSICAL_PAGE_MASK. + +Fixes: ffa71f33a820 ("x86, ioremap: Fix incorrect physical address handling in PAE mode") +Signed-off-by: Michael Kelley +Signed-off-by: Borislav Petkov +Acked-by: Dave Hansen +Cc: +Link: https://lore.kernel.org/r/1668624097-14884-2-git-send-email-mikelley@microsoft.com +Signed-off-by: Sasha Levin +--- + arch/x86/mm/ioremap.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c +index a353f88d299d..137714df879e 100644 +--- a/arch/x86/mm/ioremap.c ++++ b/arch/x86/mm/ioremap.c +@@ -214,9 +214,15 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size, + * Mappings have to be page-aligned + */ + offset = phys_addr & ~PAGE_MASK; +- phys_addr &= PHYSICAL_PAGE_MASK; ++ phys_addr &= PAGE_MASK; + size = PAGE_ALIGN(last_addr+1) - phys_addr; + ++ /* ++ * Mask out any bits not part of the actual physical ++ * address, like memory encryption bits. ++ */ ++ phys_addr &= PHYSICAL_PAGE_MASK; ++ + retval = reserve_memtype(phys_addr, (u64)phys_addr + size, + pcm, &new_pcm); + if (retval) { +-- +2.35.1 +