--- /dev/null
+From ddc204b517e60ae64db34f9832dc41dafa77c751 Mon Sep 17 00:00:00 2001
+From: Waiman Long <longman@redhat.com>
+Date: Tue, 8 Feb 2022 11:39:12 -0500
+Subject: copy_process(): Move fd_install() out of sighand->siglock critical section
+
+From: Waiman Long <longman@redhat.com>
+
+commit ddc204b517e60ae64db34f9832dc41dafa77c751 upstream.
+
+I was made aware of the following lockdep splat:
+
+[ 2516.308763] =====================================================
+[ 2516.309085] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
+[ 2516.309433] 5.14.0-51.el9.aarch64+debug #1 Not tainted
+[ 2516.309703] -----------------------------------------------------
+[ 2516.310149] stress-ng/153663 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
+[ 2516.310512] ffff0000e422b198 (&newf->file_lock){+.+.}-{2:2}, at: fd_install+0x368/0x4f0
+[ 2516.310944]
+ and this task is already holding:
+[ 2516.311248] ffff0000c08140d8 (&sighand->siglock){-.-.}-{2:2}, at: copy_process+0x1e2c/0x3e80
+[ 2516.311804] which would create a new lock dependency:
+[ 2516.312066] (&sighand->siglock){-.-.}-{2:2} -> (&newf->file_lock){+.+.}-{2:2}
+[ 2516.312446]
+ but this new dependency connects a HARDIRQ-irq-safe lock:
+[ 2516.312983] (&sighand->siglock){-.-.}-{2:2}
+ :
+[ 2516.330700] Possible interrupt unsafe locking scenario:
+
+[ 2516.331075] CPU0 CPU1
+[ 2516.331328] ---- ----
+[ 2516.331580] lock(&newf->file_lock);
+[ 2516.331790] local_irq_disable();
+[ 2516.332231] lock(&sighand->siglock);
+[ 2516.332579] lock(&newf->file_lock);
+[ 2516.332922] <Interrupt>
+[ 2516.333069] lock(&sighand->siglock);
+[ 2516.333291]
+ *** DEADLOCK ***
+[ 2516.389845]
+ stack backtrace:
+[ 2516.390101] CPU: 3 PID: 153663 Comm: stress-ng Kdump: loaded Not tainted 5.14.0-51.el9.aarch64+debug #1
+[ 2516.390756] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
+[ 2516.391155] Call trace:
+[ 2516.391302] dump_backtrace+0x0/0x3e0
+[ 2516.391518] show_stack+0x24/0x30
+[ 2516.391717] dump_stack_lvl+0x9c/0xd8
+[ 2516.391938] dump_stack+0x1c/0x38
+[ 2516.392247] print_bad_irq_dependency+0x620/0x710
+[ 2516.392525] check_irq_usage+0x4fc/0x86c
+[ 2516.392756] check_prev_add+0x180/0x1d90
+[ 2516.392988] validate_chain+0x8e0/0xee0
+[ 2516.393215] __lock_acquire+0x97c/0x1e40
+[ 2516.393449] lock_acquire.part.0+0x240/0x570
+[ 2516.393814] lock_acquire+0x90/0xb4
+[ 2516.394021] _raw_spin_lock+0xe8/0x154
+[ 2516.394244] fd_install+0x368/0x4f0
+[ 2516.394451] copy_process+0x1f5c/0x3e80
+[ 2516.394678] kernel_clone+0x134/0x660
+[ 2516.394895] __do_sys_clone3+0x130/0x1f4
+[ 2516.395128] __arm64_sys_clone3+0x5c/0x7c
+[ 2516.395478] invoke_syscall.constprop.0+0x78/0x1f0
+[ 2516.395762] el0_svc_common.constprop.0+0x22c/0x2c4
+[ 2516.396050] do_el0_svc+0xb0/0x10c
+[ 2516.396252] el0_svc+0x24/0x34
+[ 2516.396436] el0t_64_sync_handler+0xa4/0x12c
+[ 2516.396688] el0t_64_sync+0x198/0x19c
+[ 2517.491197] NET: Registered PF_ATMPVC protocol family
+[ 2517.491524] NET: Registered PF_ATMSVC protocol family
+[ 2591.991877] sched: RT throttling activated
+
+One way to solve this problem is to move the fd_install() call out of
+the sighand->siglock critical section.
+
+Before commit 6fd2fe494b17 ("copy_process(): don't use ksys_close()
+on cleanups"), the pidfd installation was done without holding both
+the task_list lock and the sighand->siglock. Obviously, holding these
+two locks are not really needed to protect the fd_install() call.
+So move the fd_install() call down to after the releases of both locks.
+
+Link: https://lore.kernel.org/r/20220208163912.1084752-1-longman@redhat.com
+Fixes: 6fd2fe494b17 ("copy_process(): don't use ksys_close() on cleanups")
+Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/fork.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -2182,10 +2182,6 @@ static __latent_entropy struct task_stru
+ goto bad_fork_cancel_cgroup;
+ }
+
+- /* past the last point of failure */
+- if (pidfile)
+- fd_install(pidfd, pidfile);
+-
+ init_task_pid_links(p);
+ if (likely(p->pid)) {
+ ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
+@@ -2234,6 +2230,9 @@ static __latent_entropy struct task_stru
+ syscall_tracepoint_update(p);
+ write_unlock_irq(&tasklist_lock);
+
++ if (pidfile)
++ fd_install(pidfd, pidfile);
++
+ proc_fork_connector(p);
+ cgroup_post_fork(p);
+ cgroup_threadgroup_change_end(current);
--- /dev/null
+From 2d21543efe332cd8c8f212fb7d365bc8b0690bfa Mon Sep 17 00:00:00 2001
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Date: Thu, 6 Jan 2022 11:09:39 +0800
+Subject: dmaengine: sh: rcar-dmac: Check for error num after setting mask
+
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+
+commit 2d21543efe332cd8c8f212fb7d365bc8b0690bfa upstream.
+
+Because of the possible failure of the dma_supported(), the
+dma_set_mask_and_coherent() may return error num.
+Therefore, it should be better to check it and return the error if
+fails.
+
+Fixes: dc312349e875 ("dmaengine: rcar-dmac: Widen DMA mask to 40 bits")
+Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Link: https://lore.kernel.org/r/20220106030939.2644320-1-jiasheng@iscas.ac.cn
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/sh/rcar-dmac.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/dma/sh/rcar-dmac.c
++++ b/drivers/dma/sh/rcar-dmac.c
+@@ -1825,7 +1825,9 @@ static int rcar_dmac_probe(struct platfo
+ platform_set_drvdata(pdev, dmac);
+ dmac->dev->dma_parms = &dmac->parms;
+ dma_set_max_seg_size(dmac->dev, RCAR_DMATCR_MASK);
+- dma_set_mask_and_coherent(dmac->dev, DMA_BIT_MASK(40));
++ ret = dma_set_mask_and_coherent(dmac->dev, DMA_BIT_MASK(40));
++ if (ret)
++ return ret;
+
+ ret = rcar_dmac_parse_of(&pdev->dev, dmac);
+ if (ret < 0)
--- /dev/null
+From 834cea3a252ed4847db076a769ad9efe06afe2d5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
+Date: Tue, 15 Feb 2022 08:27:35 +0100
+Subject: i2c: brcmstb: fix support for DSL and CM variants
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rafał Miłecki <rafal@milecki.pl>
+
+commit 834cea3a252ed4847db076a769ad9efe06afe2d5 upstream.
+
+DSL and CM (Cable Modem) support 8 B max transfer size and have a custom
+DT binding for that reason. This driver was checking for a wrong
+"compatible" however which resulted in an incorrect setup.
+
+Fixes: e2e5a2c61837 ("i2c: brcmstb: Adding support for CM and DSL SoCs")
+Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
+Acked-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-brcmstb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-brcmstb.c
++++ b/drivers/i2c/busses/i2c-brcmstb.c
+@@ -640,7 +640,7 @@ static int brcmstb_i2c_probe(struct plat
+
+ /* set the data in/out register size for compatible SoCs */
+ if (of_device_is_compatible(dev->device->of_node,
+- "brcmstb,brcmper-i2c"))
++ "brcm,brcmper-i2c"))
+ dev->data_regsz = sizeof(u8);
+ else
+ dev->data_regsz = sizeof(u32);
projects / thirdparty / kernel / stable-queue.git / commitdiff
