From: Greg Kroah-Hartman Date: Mon, 13 Sep 2021 12:21:32 +0000 (+0200) Subject: 5.13-stable patches X-Git-Tag: v5.4.146~5 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=450b4c3b1b13ef647e76833eba45159fd060a8aa;p=thirdparty%2Fkernel%2Fstable-queue.git 5.13-stable patches added patches: backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch clk-kirkwood-fix-a-clocking-boot-regression.patch fbmem-don-t-allow-too-huge-resolutions.patch rdma-mlx5-fix-number-of-allocated-xlt-entries.patch --- diff --git a/queue-5.13/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch b/queue-5.13/backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch new file mode 100644 index 00000000000..66823696761 --- /dev/null +++ b/queue-5.13/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.13/clk-kirkwood-fix-a-clocking-boot-regression.patch b/queue-5.13/clk-kirkwood-fix-a-clocking-boot-regression.patch new file mode 100644 index 00000000000..53c926395ca --- /dev/null +++ b/queue-5.13/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.13/fbmem-don-t-allow-too-huge-resolutions.patch b/queue-5.13/fbmem-don-t-allow-too-huge-resolutions.patch new file mode 100644 index 00000000000..61deed4e81b --- /dev/null +++ b/queue-5.13/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.13/rdma-mlx5-fix-number-of-allocated-xlt-entries.patch b/queue-5.13/rdma-mlx5-fix-number-of-allocated-xlt-entries.patch new file mode 100644 index 00000000000..2cdee44401c --- /dev/null +++ b/queue-5.13/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 +@@ -1022,7 +1022,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.13/series b/queue-5.13/series index 69863b22cf0..ee0b8878b6c 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -294,3 +294,7 @@ 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 +rdma-mlx5-fix-number-of-allocated-xlt-entries.patch +backlight-pwm_bl-improve-bootloader-kernel-device-handover.patch +clk-kirkwood-fix-a-clocking-boot-regression.patch