From: Greg Kroah-Hartman Date: Mon, 13 Sep 2021 12:21:48 +0000 (+0200) Subject: 5.14-stable patches X-Git-Tag: v5.4.146~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=79500426e10cc190bf10d4d5a2e300d6f271219d;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: acpi-prm-find-prmt-table-before-parsing-it.patch backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch bootconfig-fix-missing-return-check-of-xbc_node_compose_key-function.patch clk-kirkwood-fix-a-clocking-boot-regression.patch fbmem-don-t-allow-too-huge-resolutions.patch parisc-fix-unaligned-access-crash-in-bootloader.patch rdma-mlx5-fix-number-of-allocated-xlt-entries.patch --- diff --git a/queue-5.14/acpi-prm-find-prmt-table-before-parsing-it.patch b/queue-5.14/acpi-prm-find-prmt-table-before-parsing-it.patch new file mode 100644 index 00000000000..dcaf89b38f5 --- /dev/null +++ b/queue-5.14/acpi-prm-find-prmt-table-before-parsing-it.patch @@ -0,0 +1,47 @@ +From 3265cc3ec52e75fc8daf189954cebda27ad26b2e Mon Sep 17 00:00:00 2001 +From: Aubrey Li +Date: Wed, 8 Sep 2021 18:55:45 +0800 +Subject: ACPI: PRM: Find PRMT table before parsing it + +From: Aubrey Li + +commit 3265cc3ec52e75fc8daf189954cebda27ad26b2e upstream. + +Find and verify PRMT before parsing it, which eliminates a +warning on machines without PRMT: + + [ 7.197173] ACPI: PRMT not present + +Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype") +Signed-off-by: Aubrey Li +Tested-by: Paul Menzel +Cc: 5.14+ # 5.14+ +[ rjw: Subject and changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/prmt.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/prmt.c ++++ b/drivers/acpi/prmt.c +@@ -288,10 +288,18 @@ invalid_guid: + + void __init init_prmt(void) + { ++ struct acpi_table_header *tbl; + acpi_status status; +- int mc = acpi_table_parse_entries(ACPI_SIG_PRMT, sizeof(struct acpi_table_prmt) + ++ int mc; ++ ++ status = acpi_get_table(ACPI_SIG_PRMT, 0, &tbl); ++ if (ACPI_FAILURE(status)) ++ return; ++ ++ mc = acpi_table_parse_entries(ACPI_SIG_PRMT, sizeof(struct acpi_table_prmt) + + sizeof (struct acpi_table_prmt_header), + 0, acpi_parse_prmt, 0); ++ acpi_put_table(tbl); + /* + * Return immediately if PRMT table is not present or no PRM module found. + */ diff --git a/queue-5.14/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch b/queue-5.14/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch new file mode 100644 index 00000000000..66823696761 --- /dev/null +++ b/queue-5.14/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch @@ -0,0 +1,114 @@ +From 79fad92f2e596f5a8dd085788a24f540263ef887 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Thu, 22 Jul 2021 15:46:23 +0100 +Subject: backlight: pwm_bl: Improve bootloader/kernel device handover + +From: Daniel Thompson + +commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream. + +Currently there are (at least) two problems in the way pwm_bl starts +managing the enable_gpio pin. Both occur when the backlight is initially +off and the driver finds the pin not already in output mode and, as a +result, unconditionally switches it to output-mode and asserts the signal. + +Problem 1: This could cause the backlight to flicker since, at this stage +in driver initialisation, we have no idea what the PWM and regulator are +doing (an unconfigured PWM could easily "rest" at 100% duty cycle). + +Problem 2: This will cause us not to correctly honour the +post_pwm_on_delay (which also risks flickers). + +Fix this by moving the code to configure the GPIO output mode until after +we have examines the handover state. That allows us to initialize +enable_gpio to off if the backlight is currently off and on if the +backlight is on. + +Cc: stable@vger.kernel.org +Reported-by: Marek Vasut +Signed-off-by: Daniel Thompson +Acked-by: Marek Vasut +Tested-by: Marek Vasut +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/backlight/pwm_bl.c | 54 ++++++++++++++++++++------------------- + 1 file changed, 28 insertions(+), 26 deletions(-) + +--- a/drivers/video/backlight/pwm_bl.c ++++ b/drivers/video/backlight/pwm_bl.c +@@ -409,6 +409,33 @@ static bool pwm_backlight_is_linear(stru + static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb) + { + struct device_node *node = pb->dev->of_node; ++ bool active = true; ++ ++ /* ++ * If the enable GPIO is present, observable (either as input ++ * or output) and off then the backlight is not currently active. ++ * */ ++ if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0) ++ active = false; ++ ++ if (!regulator_is_enabled(pb->power_supply)) ++ active = false; ++ ++ if (!pwm_is_enabled(pb->pwm)) ++ active = false; ++ ++ /* ++ * Synchronize the enable_gpio with the observed state of the ++ * hardware. ++ */ ++ if (pb->enable_gpio) ++ gpiod_direction_output(pb->enable_gpio, active); ++ ++ /* ++ * Do not change pb->enabled here! pb->enabled essentially ++ * tells us if we own one of the regulator's use counts and ++ * right now we do not. ++ */ + + /* Not booted with device tree or no phandle link to the node */ + if (!node || !node->phandle) +@@ -420,20 +447,7 @@ static int pwm_backlight_initial_power_s + * assume that another driver will enable the backlight at the + * appropriate time. Therefore, if it is disabled, keep it so. + */ +- +- /* if the enable GPIO is disabled, do not enable the backlight */ +- if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0) +- return FB_BLANK_POWERDOWN; +- +- /* The regulator is disabled, do not enable the backlight */ +- if (!regulator_is_enabled(pb->power_supply)) +- return FB_BLANK_POWERDOWN; +- +- /* The PWM is disabled, keep it like this */ +- if (!pwm_is_enabled(pb->pwm)) +- return FB_BLANK_POWERDOWN; +- +- return FB_BLANK_UNBLANK; ++ return active ? FB_BLANK_UNBLANK: FB_BLANK_POWERDOWN; + } + + static int pwm_backlight_probe(struct platform_device *pdev) +@@ -486,18 +500,6 @@ static int pwm_backlight_probe(struct pl + goto err_alloc; + } + +- /* +- * If the GPIO is not known to be already configured as output, that +- * is, if gpiod_get_direction returns either 1 or -EINVAL, change the +- * direction to output and set the GPIO as active. +- * Do not force the GPIO to active when it was already output as it +- * could cause backlight flickering or we would enable the backlight too +- * early. Leave the decision of the initial backlight state for later. +- */ +- if (pb->enable_gpio && +- gpiod_get_direction(pb->enable_gpio) != 0) +- gpiod_direction_output(pb->enable_gpio, 1); +- + pb->power_supply = devm_regulator_get(&pdev->dev, "power"); + if (IS_ERR(pb->power_supply)) { + ret = PTR_ERR(pb->power_supply); diff --git a/queue-5.14/bootconfig-fix-missing-return-check-of-xbc_node_compose_key-function.patch b/queue-5.14/bootconfig-fix-missing-return-check-of-xbc_node_compose_key-function.patch new file mode 100644 index 00000000000..1f6885b0e44 --- /dev/null +++ b/queue-5.14/bootconfig-fix-missing-return-check-of-xbc_node_compose_key-function.patch @@ -0,0 +1,41 @@ +From 903bd067faa837fddb6e5c8b740c3374dc582f04 Mon Sep 17 00:00:00 2001 +From: Julio Faracco +Date: Sun, 5 Sep 2021 00:54:38 +0900 +Subject: bootconfig: Fix missing return check of xbc_node_compose_key function + +From: Julio Faracco + +commit 903bd067faa837fddb6e5c8b740c3374dc582f04 upstream. + +The function `xbc_show_list should` handle the keys during the +composition. Even the errors returned by the compose function. Instead +of removing the `ret` variable, it should save the value and show the +exact error. This missing variable is causing a compilation issue also. + +Link: https://lkml.kernel.org/r/163077087861.222577.12884543474750968146.stgit@devnote2 + +Fixes: e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key") +Signed-off-by: Julio Faracco +Acked-by: Masami Hiramatsu +Cc: stable@vger.kernel.org +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + tools/bootconfig/main.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/tools/bootconfig/main.c ++++ b/tools/bootconfig/main.c +@@ -111,9 +111,11 @@ static void xbc_show_list(void) + char key[XBC_KEYLEN_MAX]; + struct xbc_node *leaf; + const char *val; ++ int ret; + + xbc_for_each_key_value(leaf, val) { +- if (xbc_node_compose_key(leaf, key, XBC_KEYLEN_MAX) < 0) { ++ ret = xbc_node_compose_key(leaf, key, XBC_KEYLEN_MAX); ++ if (ret < 0) { + fprintf(stderr, "Failed to compose key %d\n", ret); + break; + } diff --git a/queue-5.14/clk-kirkwood-fix-a-clocking-boot-regression.patch b/queue-5.14/clk-kirkwood-fix-a-clocking-boot-regression.patch new file mode 100644 index 00000000000..53c926395ca --- /dev/null +++ b/queue-5.14/clk-kirkwood-fix-a-clocking-boot-regression.patch @@ -0,0 +1,63 @@ +From aaedb9e00e5400220a8871180d23a83e67f29f63 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Sun, 15 Aug 2021 01:55:14 +0200 +Subject: clk: kirkwood: Fix a clocking boot regression + +From: Linus Walleij + +commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream. + +Since a few kernel releases the Pogoplug 4 has crashed like this +during boot: + +Unable to handle kernel NULL pointer dereference at virtual address 00000002 +(...) +[] (strlen) from [] (kstrdup+0x1c/0x4c) +[] (kstrdup) from [] (__clk_register+0x44/0x37c) +[] (__clk_register) from [] (clk_hw_register+0x20/0x44) +[] (clk_hw_register) from [] (__clk_hw_register_mux+0x198/0x1e4) +[] (__clk_hw_register_mux) from [] (clk_register_mux_table+0x5c/0x6c) +[] (clk_register_mux_table) from [] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac) +[] (kirkwood_clk_muxing_setup.constprop.0) from [] (of_clk_init+0x12c/0x214) +[] (of_clk_init) from [] (time_init+0x20/0x2c) +[] (time_init) from [] (start_kernel+0x3dc/0x56c) +[] (start_kernel) from [<00000000>] (0x0) +Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000) + +This is because the "powersave" mux clock 0 was provided in an unterminated +array, which is required by the loop in the driver: + + /* Count, allocate, and register clock muxes */ + for (n = 0; desc[n].name;) + n++; + +Here n will go out of bounds and then call clk_register_mux() on random +memory contents after the mux clock. + +Fix this by terminating the array with a blank entry. + +Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer") +Cc: stable@vger.kernel.org +Cc: Andrew Lunn +Cc: Chris Packham +Cc: Gregory CLEMENT +Cc: Sebastian Hesselbarth +Signed-off-by: Linus Walleij +Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org +Reviewed-by: Andrew Lunn +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/mvebu/kirkwood.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/clk/mvebu/kirkwood.c ++++ b/drivers/clk/mvebu/kirkwood.c +@@ -265,6 +265,7 @@ static const char *powersave_parents[] = + static const struct clk_muxing_soc_desc kirkwood_mux_desc[] __initconst = { + { "powersave", powersave_parents, ARRAY_SIZE(powersave_parents), + 11, 1, 0 }, ++ { } + }; + + static struct clk *clk_muxing_get_src( diff --git a/queue-5.14/fbmem-don-t-allow-too-huge-resolutions.patch b/queue-5.14/fbmem-don-t-allow-too-huge-resolutions.patch new file mode 100644 index 00000000000..61deed4e81b --- /dev/null +++ b/queue-5.14/fbmem-don-t-allow-too-huge-resolutions.patch @@ -0,0 +1,56 @@ +From 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Wed, 8 Sep 2021 19:27:49 +0900 +Subject: fbmem: don't allow too huge resolutions + +From: Tetsuo Handa + +commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream. + +syzbot is reporting page fault at vga16fb_fillrect() [1], for +vga16fb_check_var() is failing to detect multiplication overflow. + + if (vxres * vyres > maxmem) { + vyres = maxmem / vxres; + if (vyres < yres) + return -ENOMEM; + } + +Since no module would accept too huge resolutions where multiplication +overflow happens, let's reject in the common path. + +Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1] +Reported-by: syzbot +Debugged-by: Randy Dunlap +Signed-off-by: Tetsuo Handa +Reviewed-by: Geert Uytterhoeven +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/fbdev/core/fbmem.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/video/fbdev/core/fbmem.c ++++ b/drivers/video/fbdev/core/fbmem.c +@@ -962,6 +962,7 @@ fb_set_var(struct fb_info *info, struct + struct fb_var_screeninfo old_var; + struct fb_videomode mode; + struct fb_event event; ++ u32 unused; + + if (var->activate & FB_ACTIVATE_INV_MODE) { + struct fb_videomode mode1, mode2; +@@ -1008,6 +1009,11 @@ fb_set_var(struct fb_info *info, struct + if (var->xres < 8 || var->yres < 8) + return -EINVAL; + ++ /* Too huge resolution causes multiplication overflow. */ ++ if (check_mul_overflow(var->xres, var->yres, &unused) || ++ check_mul_overflow(var->xres_virtual, var->yres_virtual, &unused)) ++ return -EINVAL; ++ + ret = info->fbops->fb_check_var(var, info); + + if (ret) diff --git a/queue-5.14/parisc-fix-unaligned-access-crash-in-bootloader.patch b/queue-5.14/parisc-fix-unaligned-access-crash-in-bootloader.patch new file mode 100644 index 00000000000..eb743c88cb6 --- /dev/null +++ b/queue-5.14/parisc-fix-unaligned-access-crash-in-bootloader.patch @@ -0,0 +1,42 @@ +From c42813b71a06a2ff4a155aa87ac609feeab76cf3 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Thu, 2 Sep 2021 23:24:42 +0200 +Subject: parisc: Fix unaligned-access crash in bootloader + +From: Helge Deller + +commit c42813b71a06a2ff4a155aa87ac609feeab76cf3 upstream. + +Kernel v5.14 has various changes to optimize unaligned memory accesses, +e.g. commit 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers"). + +Those changes triggered an unalignment-exception and thus crashed the +bootloader on parisc because the unaligned "output_len" variable now suddenly +was read word-wise while it was read byte-wise in the past. + +Fix this issue by declaring the external output_len variable as char which then +forces the compiler to generate byte-accesses. + +Signed-off-by: Helge Deller +Cc: Arnd Bergmann +Cc: John David Anglin +Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162 +Fixes: 8c031ba63f8f ("parisc: Unbreak bootloader due to gcc-7 optimizations") +Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers") +Cc: # v5.14+ +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/boot/compressed/misc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/parisc/boot/compressed/misc.c ++++ b/arch/parisc/boot/compressed/misc.c +@@ -26,7 +26,7 @@ + extern char input_data[]; + extern int input_len; + /* output_len is inserted by the linker possibly at an unaligned address */ +-extern __le32 output_len __aligned(1); ++extern char output_len; + extern char _text, _end; + extern char _bss, _ebss; + extern char _startcode_end; diff --git a/queue-5.14/rdma-mlx5-fix-number-of-allocated-xlt-entries.patch b/queue-5.14/rdma-mlx5-fix-number-of-allocated-xlt-entries.patch new file mode 100644 index 00000000000..5e8bfdaf8e4 --- /dev/null +++ b/queue-5.14/rdma-mlx5-fix-number-of-allocated-xlt-entries.patch @@ -0,0 +1,43 @@ +From 9660dcbe0d9186976917c94bce4e69dbd8d7a974 Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Wed, 8 Sep 2021 10:18:48 +0200 +Subject: RDMA/mlx5: Fix number of allocated XLT entries + +From: Niklas Schnelle + +commit 9660dcbe0d9186976917c94bce4e69dbd8d7a974 upstream. + +In commit 8010d74b9965b ("RDMA/mlx5: Split the WR setup out of +mlx5_ib_update_xlt()") the allocation logic was split out of +mlx5_ib_update_xlt() and the logic was changed to enable better OOM +handling. Sadly this change introduced a miscalculation of the number of +entries that were actually allocated when under memory pressure where it +can actually become 0 which on s390 lets dma_map_single() fail. + +It can also lead to corruption of the free pages list when the wrong +number of entries is used in the calculation of sg->length which is used +as argument for free_pages(). + +Fix this by using the allocation size instead of misusing get_order(size). + +Cc: stable@vger.kernel.org +Fixes: 8010d74b9965 ("RDMA/mlx5: Split the WR setup out of mlx5_ib_update_xlt()") +Link: https://lore.kernel.org/r/20210908081849.7948-1-schnelle@linux.ibm.com +Signed-off-by: Niklas Schnelle +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx5/mr.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -1024,7 +1024,7 @@ static void *mlx5_ib_alloc_xlt(size_t *n + + if (size > MLX5_SPARE_UMR_CHUNK) { + size = MLX5_SPARE_UMR_CHUNK; +- *nents = get_order(size) / ent_size; ++ *nents = size / ent_size; + res = (void *)__get_free_pages(gfp_mask | __GFP_NOWARN, + get_order(size)); + if (res) diff --git a/queue-5.14/series b/queue-5.14/series index 957b327ecf4..5a8d8562f3b 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -325,3 +325,10 @@ fuse-flush-extending-writes.patch fuse-wait-for-writepages-in-syncfs.patch ima-remove-wmissing-prototypes-warning.patch ima-remove-the-dependency-on-crypto_md5.patch +fbmem-don-t-allow-too-huge-resolutions.patch +acpi-prm-find-prmt-table-before-parsing-it.patch +rdma-mlx5-fix-number-of-allocated-xlt-entries.patch +bootconfig-fix-missing-return-check-of-xbc_node_compose_key-function.patch +backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch +parisc-fix-unaligned-access-crash-in-bootloader.patch +clk-kirkwood-fix-a-clocking-boot-regression.patch