From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4118CC38145 for ; Fri, 2 Sep 2022 12:52:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237885AbiIBMv5 (ORCPT ); Fri, 2 Sep 2022 08:51:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237809AbiIBMu6 (ORCPT ); Fri, 2 Sep 2022 08:50:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21DC63B1; Fri, 2 Sep 2022 05:36:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4A0396215E; Fri, 2 Sep 2022 12:26:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E163C433C1; Fri, 2 Sep 2022 12:26:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121613; bh=CJRQTFu+wUrdMa03M09XgGm0xY+TyLR5hIcc/xMR2wQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MNUWxGoS8qrlKKpc4vf0EgGZgaT14L5Gi+heT3zooGGV0balNWb0ub8qzPIx/yVFb tmBxikQ3b7snAomuwCG9TFbcuGINksLI47tJQVw7hTZ9xXi4/SipU+o1OOS1MBttWC bXRNCm/KM/DpsZ0X4WDQbTEQpc7WaibGib0y+U3U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Gaosheng Cui , Jan Kara , Paul Moore Subject: [PATCH 5.4 01/77] audit: fix potential double free on error path from fsnotify_add_inode_mark Date: Fri, 2 Sep 2022 14:18:10 +0200 Message-Id: <20220902121403.635952136@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Gaosheng Cui commit ad982c3be4e60c7d39c03f782733503cbd88fd2a upstream. Audit_alloc_mark() assign pathname to audit_mark->path, on error path from fsnotify_add_inode_mark(), fsnotify_put_mark will free memory of audit_mark->path, but the caller of audit_alloc_mark will free the pathname again, so there will be double free problem. Fix this by resetting audit_mark->path to NULL pointer on error path from fsnotify_add_inode_mark(). Cc: stable@vger.kernel.org Fixes: 7b1293234084d ("fsnotify: Add group pointer in fsnotify_init_mark()") Signed-off-by: Gaosheng Cui Reviewed-by: Jan Kara Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/audit_fsnotify.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/audit_fsnotify.c +++ b/kernel/audit_fsnotify.c @@ -102,6 +102,7 @@ struct audit_fsnotify_mark *audit_alloc_ =20 ret =3D fsnotify_add_inode_mark(&audit_mark->mark, inode, true); if (ret < 0) { + audit_mark->path =3D NULL; fsnotify_put_mark(&audit_mark->mark); audit_mark =3D ERR_PTR(ret); } From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CE6DECAAD5 for ; Fri, 2 Sep 2022 12:51:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237737AbiIBMvy (ORCPT ); Fri, 2 Sep 2022 08:51:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237467AbiIBMur (ORCPT ); Fri, 2 Sep 2022 08:50:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A7D3DDB46; Fri, 2 Sep 2022 05:36:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 33642B82A99; Fri, 2 Sep 2022 12:27:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86D57C433D6; Fri, 2 Sep 2022 12:27:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121646; bh=NajXgsYiuauLyQeZ+zf17PKBvQW9QaVX+z7efwu5PKk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xJynxbXeyQZKlsS1EhRY3bAZNjmCOmkbt34G9OKclbvtYNS6nQEKj4KRVx8Bsv+BA deG/9wo0n6l3/SZWml8FmKSDBnFKTIWuXjoPSCIf6Mxpr9VsTWnYoDXSC6DUn93n4Q /vn5WdFFXf0LFo6LvLrHz8ZXA6u803KZuXKW+GP4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Helge Deller Subject: [PATCH 5.4 02/77] parisc: Fix exception handler for fldw and fstw instructions Date: Fri, 2 Sep 2022 14:18:11 +0200 Message-Id: <20220902121403.669167896@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Helge Deller commit 7ae1f5508d9a33fd58ed3059bd2d569961e3b8bd upstream. The exception handler is broken for unaligned memory acceses with fldw and fstw instructions, because it trashes or uses randomly some other floating point register than the one specified in the instruction word on loads and stores. The instruction "fldw 0(addr),%fr22L" (and the other fldw/fstw instructions) encode the target register (%fr22) in the rightmost 5 bits of the instruction word. The 7th rightmost bit of the instruction word defines if the left or right half of %fr22 should be used. While processing unaligned address accesses, the FR3() define is used to extract the offset into the local floating-point register set. But the calculation in FR3() was buggy, so that for example instead of %fr22, register %fr12 [((22 * 2) & 0x1f) =3D 12] was used. This bug has been since forever in the parisc kernel and I wonder why it wasn't detected earlier. Interestingly I noticed this bug just because the libime debian package failed to build on *native* hardware, while it successfully built in qemu. This patch corrects the bitshift and masking calculation in FR3(). Signed-off-by: Helge Deller Cc: Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/parisc/kernel/unaligned.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/parisc/kernel/unaligned.c +++ b/arch/parisc/kernel/unaligned.c @@ -107,7 +107,7 @@ #define R1(i) (((i)>>21)&0x1f) #define R2(i) (((i)>>16)&0x1f) #define R3(i) ((i)&0x1f) -#define FR3(i) ((((i)<<1)&0x1f)|(((i)>>6)&1)) +#define FR3(i) ((((i)&0x1f)<<1)|(((i)>>6)&1)) #define IM(i,n) (((i)>>1&((1<<(n-1))-1))|((i)&1?((0-1L)<<(n-1)):0)) #define IM5_2(i) IM((i)>>16,5) #define IM5_3(i) IM((i),5) From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2E8FC38145 for ; Fri, 2 Sep 2022 12:37:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236638AbiIBMhP (ORCPT ); Fri, 2 Sep 2022 08:37:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236973AbiIBMgf (ORCPT ); Fri, 2 Sep 2022 08:36:35 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E138B5FFA; Fri, 2 Sep 2022 05:29:08 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 36E2DB82A98; Fri, 2 Sep 2022 12:27:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F4E9C433D6; Fri, 2 Sep 2022 12:27:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121653; bh=90j0F/FrWOEKi/n+s4lG8xuIPvMDJtcHV/oVOc7vAuU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y23ir6DufrQjqosvKLkCP7976hzZCqmR8Nxysd8znSMqj/8C9JbcnYjFxakBKPqfM 4YfTpBi2fi0CB6BCJbYAxJftRyIkftpGIK6j+vr6xEhHKjAOedHstKFFCit1LXQMYr AvDrx5AKuXiTYef1U/+8pMmCANG3iFiacs+TSYzw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Randy Dunlap , Arnd Bergmann , Josh Triplett , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrew Morton Subject: [PATCH 5.4 03/77] kernel/sys_ni: add compat entry for fadvise64_64 Date: Fri, 2 Sep 2022 14:18:12 +0200 Message-Id: <20220902121403.712211412@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Randy Dunlap commit a8faed3a02eeb75857a3b5d660fa80fe79db77a3 upstream. When CONFIG_ADVISE_SYSCALLS is not set/enabled and CONFIG_COMPAT is set/enabled, the riscv compat_syscall_table references 'compat_sys_fadvise64_64', which is not defined: riscv64-linux-ld: arch/riscv/kernel/compat_syscall_table.o:(.rodata+0x6f8): undefined reference to `compat_sys_fadvise64_64' Add 'fadvise64_64' to kernel/sys_ni.c as a conditional COMPAT function so that when CONFIG_ADVISE_SYSCALLS is not set, there is a fallback function available. Link: https://lkml.kernel.org/r/20220807220934.5689-1-rdunlap@infradead.org Fixes: d3ac21cacc24 ("mm: Support compiling out madvise and fadvise") Signed-off-by: Randy Dunlap Suggested-by: Arnd Bergmann Reviewed-by: Arnd Bergmann Cc: Josh Triplett Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/sys_ni.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -268,6 +268,7 @@ COND_SYSCALL_COMPAT(keyctl); =20 /* mm/fadvise.c */ COND_SYSCALL(fadvise64_64); +COND_SYSCALL_COMPAT(fadvise64_64); =20 /* mm/, CONFIG_MMU only */ COND_SYSCALL(swapon); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93B34C6FA85 for ; Fri, 2 Sep 2022 13:01:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238455AbiIBNBD (ORCPT ); Fri, 2 Sep 2022 09:01:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238692AbiIBM7U (ORCPT ); Fri, 2 Sep 2022 08:59:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 922C8CEB1B; Fri, 2 Sep 2022 05:40:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4E080B82AA2; Fri, 2 Sep 2022 12:27:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AC0DC433D6; Fri, 2 Sep 2022 12:27:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121656; bh=y22KnKr1+JIk3i0jCCB6oiluxBJ8/iLl7XYTywdc0s4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lSQowt24jAezOMoMU0t6ufWw28YOZKm7KWJR8UOWjXElf0yz1/p+fjopaMWBsVR6+ 2f1b5r1ZzXwVu56qTPxCb2DTXiCrVR+0aAjZxb5QhiqZkOr0AJ+PyKmadGy7cGDzWH 8H3nEIfvCvhFikiF65PCNiT4wVRCiy3OBBMxsLxI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Peter Chen , Pawel Laszczak Subject: [PATCH 5.4 04/77] usb: cdns3: Fix issue for clear halt endpoint Date: Fri, 2 Sep 2022 14:18:13 +0200 Message-Id: <20220902121403.750784175@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawel Laszczak commit b3fa25de31fb7e9afebe9599b8ff32eda13d7c94 upstream. Path fixes bug which occurs during resetting endpoint in __cdns3_gadget_ep_clear_halt function. During resetting endpoint controller will change HW/DMA owned TRB. It set Abort flag in trb->control and will change trb->length field. If driver want to use the aborted trb it must update the changed field in TRB. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") cc: Acked-by: Peter Chen Signed-off-by: Pawel Laszczak Link: https://lore.kernel.org/r/20220329084605.4022-1-pawell@cadence.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/cdns3/gadget.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/usb/cdns3/gadget.c +++ b/drivers/usb/cdns3/gadget.c @@ -2166,6 +2166,7 @@ int __cdns3_gadget_ep_clear_halt(struct struct usb_request *request; struct cdns3_request *priv_req; struct cdns3_trb *trb =3D NULL; + struct cdns3_trb trb_tmp; int ret; int val; =20 @@ -2175,8 +2176,10 @@ int __cdns3_gadget_ep_clear_halt(struct if (request) { priv_req =3D to_cdns3_request(request); trb =3D priv_req->trb; - if (trb) + if (trb) { + trb_tmp =3D *trb; trb->control =3D trb->control ^ TRB_CYCLE; + } } =20 writel(EP_CMD_CSTALL | EP_CMD_EPRST, &priv_dev->regs->ep_cmd); @@ -2191,7 +2194,8 @@ int __cdns3_gadget_ep_clear_halt(struct =20 if (request) { if (trb) - trb->control =3D trb->control ^ TRB_CYCLE; + *trb =3D trb_tmp; + cdns3_rearm_transfer(priv_ep, 1); } From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79F35C38145 for ; Fri, 2 Sep 2022 12:53:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237977AbiIBMxB (ORCPT ); Fri, 2 Sep 2022 08:53:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237892AbiIBMwC (ORCPT ); Fri, 2 Sep 2022 08:52:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 058D8E394F; Fri, 2 Sep 2022 05:37:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A1CAD62178; Fri, 2 Sep 2022 12:27:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A83D1C433C1; Fri, 2 Sep 2022 12:27:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121659; bh=b73JFdEEH0L5zpEOhUoRbXlzxwYfjFJus6um4Pn4iT4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uMwI0YozS9gwT20hpV+MI/o2IdzGpIABI4D8ig+ZygiLsvKNc8JvsszbSbzXH4cRJ ou0HdcCsNL4uQ38GmdG5yS04kYBOgX8BOyaU/MlZfs9MZybjJpSjSkPaeCS2G/8uwb ssWx9DgTYR0ezVOCPDxrMdLD3K5cZp81oo7wfD8Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Jean-Philippe Brucker Subject: [PATCH 5.4 05/77] Revert "selftests/bpf: Fix "dubious pointer arithmetic" test" Date: Fri, 2 Sep 2022 14:18:14 +0200 Message-Id: <20220902121403.789465369@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jean-Philippe Brucker This reverts commit 6098562ed9df1babcc0ba5b89c4fb47715ba3f72. It shouldn't be in v5.4 because the commit it fixes is only present in v5.9 onward. Signed-off-by: Jean-Philippe Brucker Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/bpf/test_align.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/tools/testing/selftests/bpf/test_align.c +++ b/tools/testing/selftests/bpf/test_align.c @@ -475,10 +475,10 @@ static struct bpf_align_test tests[] =3D { */ {7, "R5_w=3Dinv(id=3D0,smin_value=3D-9223372036854775806,smax_value=3D9= 223372036854775806,umin_value=3D2,umax_value=3D18446744073709551614,var_off= =3D(0x2; 0xfffffffffffffffc)"}, /* Checked s>=3D0 */ - {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372036854775806,va= r_off=3D(0x2; 0x7ffffffffffffffc)"}, + {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372034707292158,va= r_off=3D(0x2; 0x7fffffff7ffffffc)"}, /* packet pointer + nonnegative (4n+2) */ - {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc)"}, - {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc)"}, + {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, /* NET_IP_ALIGN + (4n+2) =3D=3D (4n), alignment is fine. * We checked the bounds, but it might have been able * to overflow if the packet pointer started in the @@ -486,7 +486,7 @@ static struct bpf_align_test tests[] =3D { * So we did not get a 'range' on R6, and the access * attempt will fail. */ - {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc)"}, + {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, } }, { From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A65F0ECAAD5 for ; Fri, 2 Sep 2022 12:34:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236839AbiIBMe0 (ORCPT ); Fri, 2 Sep 2022 08:34:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236585AbiIBMdM (ORCPT ); Fri, 2 Sep 2022 08:33:12 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03587DEA58; Fri, 2 Sep 2022 05:27:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7B04BB82AB3; Fri, 2 Sep 2022 12:27:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C443DC433D6; Fri, 2 Sep 2022 12:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121662; bh=clthHZEoZSss9EqN16KFL/fAvVHFjGWtR6Z/Pce8wIc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WXoJYHpusRdt5/0wp2MQnqv3/swldNZ49jF4jCkqsAwOGh+tat0m6ZlXbyAVLtocg v0yU0oQSM/4dD+uJ4zPX7DnxgKWwUsRYSK0oQPFkT3vfRk6u11I3xatMWBuBySNtlI Q4YUVhdZFrYRx+vSeD6sKvnTJiz0V1jPo+E5WZH4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Jean-Philippe Brucker Subject: [PATCH 5.4 06/77] Revert "selftests/bpf: Fix test_align verifier log patterns" Date: Fri, 2 Sep 2022 14:18:15 +0200 Message-Id: <20220902121403.832779905@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jean-Philippe Brucker This partially reverts commit 6a9b3f0f3bad4ca6421f8c20e1dde9839699db0f. The upstream commit addresses multiple verifier changes, only one of which was backported to v5.4. Therefore only keep the relevant changes and revert the others. Signed-off-by: Jean-Philippe Brucker Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/bpf/test_align.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/tools/testing/selftests/bpf/test_align.c +++ b/tools/testing/selftests/bpf/test_align.c @@ -475,10 +475,10 @@ static struct bpf_align_test tests[] =3D { */ {7, "R5_w=3Dinv(id=3D0,smin_value=3D-9223372036854775806,smax_value=3D9= 223372036854775806,umin_value=3D2,umax_value=3D18446744073709551614,var_off= =3D(0x2; 0xfffffffffffffffc)"}, /* Checked s>=3D0 */ - {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372034707292158,va= r_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372036854775806,va= r_off=3D(0x2; 0x7ffffffffffffffc))"}, /* packet pointer + nonnegative (4n+2) */ - {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, - {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc))"}, + {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc))"}, /* NET_IP_ALIGN + (4n+2) =3D=3D (4n), alignment is fine. * We checked the bounds, but it might have been able * to overflow if the packet pointer started in the @@ -486,7 +486,7 @@ static struct bpf_align_test tests[] =3D { * So we did not get a 'range' on R6, and the access * attempt will fail. */ - {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc))"}, } }, { @@ -580,18 +580,18 @@ static struct bpf_align_test tests[] =3D { /* Adding 14 makes R6 be (4n+2) */ {11, "R6_w=3Dinv(id=3D0,umin_value=3D14,umax_value=3D74,var_off=3D(0x2;= 0x7c))"}, /* Subtracting from packet pointer overflows ubounds */ - {13, "R5_w=3Dpkt(id=3D1,off=3D0,r=3D8,umin_value=3D18446744073709551542= ,umax_value=3D18446744073709551602,var_off=3D(0xffffffffffffff82; 0x7c)"}, + {13, "R5_w=3Dpkt(id=3D1,off=3D0,r=3D8,umin_value=3D18446744073709551542= ,umax_value=3D18446744073709551602,var_off=3D(0xffffffffffffff82; 0x7c))"}, /* New unknown value in R7 is (4n), >=3D 76 */ {15, "R7_w=3Dinv(id=3D0,umin_value=3D76,umax_value=3D1096,var_off=3D(0x= 0; 0x7fc))"}, /* Adding it to packet pointer gives nice bounds again */ - {16, "R5_w=3Dpkt(id=3D2,off=3D0,r=3D0,umin_value=3D2,umax_value=3D1082,= var_off=3D(0x2; 0xfffffffc)"}, + {16, "R5_w=3Dpkt(id=3D2,off=3D0,r=3D0,umin_value=3D2,umax_value=3D1082,= var_off=3D(0x2; 0x7fc))"}, /* At the time the word size load is performed from R5, * its total fixed offset is NET_IP_ALIGN + reg->off (0) * which is 2. Then the variable offset is (4n+2), so * the total offset is 4-byte aligned and meets the * load's requirements. */ - {20, "R5=3Dpkt(id=3D2,off=3D0,r=3D4,umin_value=3D2,umax_value=3D1082,va= r_off=3D(0x2; 0xfffffffc)"}, + {20, "R5=3Dpkt(id=3D2,off=3D0,r=3D4,umin_value=3D2,umax_value=3D1082,va= r_off=3D(0x2; 0x7fc))"}, }, }, }; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF6E7C38145 for ; Fri, 2 Sep 2022 12:35:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236950AbiIBMfa (ORCPT ); Fri, 2 Sep 2022 08:35:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236999AbiIBMeA (ORCPT ); Fri, 2 Sep 2022 08:34:00 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10A84DEA63; Fri, 2 Sep 2022 05:28:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DE35262109; Fri, 2 Sep 2022 12:27:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5F90C433C1; Fri, 2 Sep 2022 12:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121665; bh=JTYxFQLfUjY3t704BsxDxE+D5RtOCrFe01IOPYQEJwI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RhHqtX51bjo1UOeiN1dpkS/F4hDt1+Yvz+3raIAijLkunjZz3FcrPdWYSUMGKoFgQ e/LHZhQeNZgQoZN4xwxfEHww+Xjrg8t8yHzAkdxB5zbtKl9BIMeMrezMAl/0p8bEwr Jd/YW6nxYivB7dqYH4oaQDzKSXz3pmmhroR4TnjY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mario Limonciello , Basavaraj Natikar , Linus Walleij Subject: [PATCH 5.4 07/77] pinctrl: amd: Dont save/restore interrupt status and wake status bits Date: Fri, 2 Sep 2022 14:18:16 +0200 Message-Id: <20220902121403.862256116@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Basavaraj Natikar commit b8c824a869f220c6b46df724f85794349bafbf23 upstream. Saving/restoring interrupt and wake status bits across suspend can cause the suspend to fail if an IRQ is serviced across the suspend cycle. Signed-off-by: Mario Limonciello Signed-off-by: Basavaraj Natikar Fixes: 79d2c8bede2c ("pinctrl/amd: save pin registers over suspend/resume") Link: https://lore.kernel.org/r/20220613064127.220416-3-Basavaraj.Natikar@a= md.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/pinctrl/pinctrl-amd.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/drivers/pinctrl/pinctrl-amd.c +++ b/drivers/pinctrl/pinctrl-amd.c @@ -793,6 +793,7 @@ static int amd_gpio_suspend(struct devic { struct amd_gpio *gpio_dev =3D dev_get_drvdata(dev); struct pinctrl_desc *desc =3D gpio_dev->pctrl->desc; + unsigned long flags; int i; =20 for (i =3D 0; i < desc->npins; i++) { @@ -801,7 +802,9 @@ static int amd_gpio_suspend(struct devic if (!amd_gpio_should_save(gpio_dev, pin)) continue; =20 - gpio_dev->saved_regs[i] =3D readl(gpio_dev->base + pin*4); + raw_spin_lock_irqsave(&gpio_dev->lock, flags); + gpio_dev->saved_regs[i] =3D readl(gpio_dev->base + pin * 4) & ~PIN_IRQ_P= ENDING; + raw_spin_unlock_irqrestore(&gpio_dev->lock, flags); } =20 return 0; @@ -811,6 +814,7 @@ static int amd_gpio_resume(struct device { struct amd_gpio *gpio_dev =3D dev_get_drvdata(dev); struct pinctrl_desc *desc =3D gpio_dev->pctrl->desc; + unsigned long flags; int i; =20 for (i =3D 0; i < desc->npins; i++) { @@ -819,7 +823,10 @@ static int amd_gpio_resume(struct device if (!amd_gpio_should_save(gpio_dev, pin)) continue; =20 - writel(gpio_dev->saved_regs[i], gpio_dev->base + pin*4); + raw_spin_lock_irqsave(&gpio_dev->lock, flags); + gpio_dev->saved_regs[i] |=3D readl(gpio_dev->base + pin * 4) & PIN_IRQ_P= ENDING; + writel(gpio_dev->saved_regs[i], gpio_dev->base + pin * 4); + raw_spin_unlock_irqrestore(&gpio_dev->lock, flags); } =20 return 0; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26232ECAAD5 for ; Fri, 2 Sep 2022 12:52:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237900AbiIBMwJ (ORCPT ); Fri, 2 Sep 2022 08:52:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237748AbiIBMvT (ORCPT ); Fri, 2 Sep 2022 08:51:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0E5C3C8CB; Fri, 2 Sep 2022 05:37:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D228862181; Fri, 2 Sep 2022 12:27:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEDA4C433C1; Fri, 2 Sep 2022 12:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121668; bh=qObAQRL9jDvbNVUCBg+ifDtMBYI49zFZuQMYlD9sB0w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ulBxUM9WwWTEWnorfkHoueEPatANFVlg/vjgnskDfmIYcnOh/S/aWD3M3ZEuLEZzt FQmv1pOBNOGFiDFJ1E/k2/rY/uOOtt1CjcOQdUyWenhbExgQc5/Lq26EhSpO12jTNa 4eloWoKlCq3U0tuiykcrvET//ZJN5Ml3Plv0VPtk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "srivatsab@vmware.com, srivatsa@csail.mit.edu, akaher@vmware.com, amakhalov@vmware.com, vsirnapalli@vmware.com, sturlapati@vmware.com, bordoloih@vmware.com, keerthanak@vmware.com, Ankit Jain" , Mark Simmons , Daniel Bristot de Oliveira , "Peter Zijlstra (Intel)" , Juri Lelli , Ankit Jain Subject: [PATCH 5.4 08/77] sched/deadline: Unthrottle PI boosted threads while enqueuing Date: Fri, 2 Sep 2022 14:18:17 +0200 Message-Id: <20220902121403.891470207@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Daniel Bristot de Oliveira commit feff2e65efd8d84cf831668e182b2ce73c604bbb upstream. stress-ng has a test (stress-ng --cyclic) that creates a set of threads under SCHED_DEADLINE with the following parameters: dl_runtime =3D 10000 (10 us) dl_deadline =3D 100000 (100 us) dl_period =3D 100000 (100 us) These parameters are very aggressive. When using a system without HRTICK set, these threads can easily execute longer than the dl_runtime because the throttling happens with 1/HZ resolution. During the main part of the test, the system works just fine because the workload does not try to run over the 10 us. The problem happens at the end of the test, on the exit() path. During exit(), the threads need to do some cleanups that require real-time mutex locks, mainly those related to memory management, resulting in this scenario: Note: locks are rt_mutexes... ------------------------------------------------------------------------ TASK A: TASK B: TASK C: activation activation activation lock(a): OK! lock(b): OK! lock(a) -> block (task A owns it) -> self notice/set throttled +--< -> arm replenished timer | switch-out | lock(b) | -> B prio> | -> boost TASK B | unlock(a) switch-out | -> handle lock a to B | -> wakeup(B) | -> B is throttled: | -> do not enqueue | switch-out | | +---------------------> replenishment timer -> TASK B is boosted: -> do not enqueue ------------------------------------------------------------------------ BOOM: TASK B is runnable but !enqueued, holding TASK C: the system crashes with hung task C. This problem is avoided by removing the throttle state from the boosted thread while boosting it (by TASK A in the example above), allowing it to be queued and run boosted. The next replenishment will take care of the runtime overrun, pushing the deadline further away. See the "while (dl_se->runtime <=3D 0)" on replenish_dl_entity() for more information. Reported-by: Mark Simmons Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Tested-by: Mark Simmons Link: https://lkml.kernel.org/r/5076e003450835ec74e6fa5917d02c4fa41687e6.16= 00170294.git.bristot@redhat.com [Ankit: Regenerated the patch for v5.4.y] Signed-off-by: Ankit Jain Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/sched/deadline.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1484,6 +1484,27 @@ static void enqueue_task_dl(struct rq *r */ if (pi_task && dl_prio(pi_task->normal_prio) && p->dl.dl_boosted) { pi_se =3D &pi_task->dl; + /* + * Because of delays in the detection of the overrun of a + * thread's runtime, it might be the case that a thread + * goes to sleep in a rt mutex with negative runtime. As + * a consequence, the thread will be throttled. + * + * While waiting for the mutex, this thread can also be + * boosted via PI, resulting in a thread that is throttled + * and boosted at the same time. + * + * In this case, the boost overrides the throttle. + */ + if (p->dl.dl_throttled) { + /* + * The replenish timer needs to be canceled. No + * problem if it fires concurrently: boosted threads + * are ignored in dl_task_timer(). + */ + hrtimer_try_to_cancel(&p->dl.dl_timer); + p->dl.dl_throttled =3D 0; + } } else if (!dl_prio(p->normal_prio)) { /* * Special case in which we have a !SCHED_DEADLINE task From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08C7CECAAD5 for ; Fri, 2 Sep 2022 13:00:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238426AbiIBNAl (ORCPT ); Fri, 2 Sep 2022 09:00:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238627AbiIBM7L (ORCPT ); Fri, 2 Sep 2022 08:59:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 400324BD1E; Fri, 2 Sep 2022 05:40:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 76F9BB82A93; Fri, 2 Sep 2022 12:27:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DDAC7C433C1; Fri, 2 Sep 2022 12:27:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121671; bh=WGojnZaAgjfbz7fxvLxW6H3kXXrCxl98iHCBk+3tHhg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GuFYLZMPrLMIiC0nu9fyGCRvFcR24lmpYhf17owdJcxYY8EH5fqXGt2TibjuuJ3nM Uj/NZfNEru6uvOO4kkO0WpkVETn3AiLdHocgf9Qzag+efK1ImBse6iG6H07GUjIETG OtvVucFdS6Tx4/JMkM6U9GJOz4N4dQTAfPSWqXhQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "srivatsab@vmware.com, srivatsa@csail.mit.edu, akaher@vmware.com, amakhalov@vmware.com, vsirnapalli@vmware.com, sturlapati@vmware.com, bordoloih@vmware.com, keerthanak@vmware.com, Ankit Jain" , Lucas Stach , "Peter Zijlstra (Intel)" , Juri Lelli , Ankit Jain Subject: [PATCH 5.4 09/77] sched/deadline: Fix stale throttling on de-/boosted tasks Date: Fri, 2 Sep 2022 14:18:18 +0200 Message-Id: <20220902121403.924231907@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Lucas Stach commit 46fcc4b00c3cca8adb9b7c9afdd499f64e427135 upstream. When a boosted task gets throttled, what normally happens is that it's immediately enqueued again with ENQUEUE_REPLENISH, which replenishes the runtime and clears the dl_throttled flag. There is a special case however: if the throttling happened on sched-out and the task has been deboosted in the meantime, the replenish is skipped as the task will return to its normal scheduling class. This leaves the task with the dl_throttled flag set. Now if the task gets boosted up to the deadline scheduling class again while it is sleeping, it's still in the throttled state. The normal wakeup however will enqueue the task with ENQUEUE_REPLENISH not set, so we don't actually place it on the rq. Thus we end up with a task that is runnable, but not actually on the rq and neither a immediate replenishment happens, nor is the replenishment timer set up, so the task is stuck in forever-throttled limbo. Clear the dl_throttled flag before dropping back to the normal scheduling class to fix this issue. Signed-off-by: Lucas Stach Signed-off-by: Peter Zijlstra (Intel) Acked-by: Juri Lelli Link: https://lkml.kernel.org/r/20200831110719.2126930-1-l.stach@pengutroni= x.de [Ankit: Regenerated the patch for v5.4.y] Signed-off-by: Ankit Jain Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/sched/deadline.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1507,12 +1507,15 @@ static void enqueue_task_dl(struct rq *r } } else if (!dl_prio(p->normal_prio)) { /* - * Special case in which we have a !SCHED_DEADLINE task - * that is going to be deboosted, but exceeds its - * runtime while doing so. No point in replenishing - * it, as it's going to return back to its original - * scheduling class after this. + * Special case in which we have a !SCHED_DEADLINE task that is going + * to be deboosted, but exceeds its runtime while doing so. No point in + * replenishing it, as it's going to return back to its original + * scheduling class after this. If it has been throttled, we need to + * clear the flag, otherwise the task may wake up as throttled after + * being boosted again with no means to replenish the runtime and clear + * the throttle. */ + p->dl.dl_throttled =3D 0; BUG_ON(!p->dl.dl_boosted || flags !=3D ENQUEUE_REPLENISH); return; } From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F334BC38145 for ; Fri, 2 Sep 2022 12:32:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236800AbiIBMcw (ORCPT ); Fri, 2 Sep 2022 08:32:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236430AbiIBMbw (ORCPT ); Fri, 2 Sep 2022 08:31:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D62BBE1AB7; Fri, 2 Sep 2022 05:27:08 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 30499B82A99; Fri, 2 Sep 2022 12:26:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68CD1C433C1; Fri, 2 Sep 2022 12:26:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121616; bh=AClEHJ539pESV5C/kiQ6Dr8lUzujxS4TSprFNaTcZ0E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XKWquPQ8D0kvbwsTpJAxa4K0UxUTKp7XPL1Crqgkk3tRv2fz0DOSGke6KyMFKTdOy LXPLWIY/xkJRNG9JPm6ccsg/zlKjQ1qAF+lrW9m+1+d/ncNFLII8Yfc6HQzp9ZSare uXl3/l0ufV5y/O38IjuOMMuB8yEaUOK7NXhF29ns= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "srivatsab@vmware.com, srivatsa@csail.mit.edu, akaher@vmware.com, amakhalov@vmware.com, vsirnapalli@vmware.com, sturlapati@vmware.com, bordoloih@vmware.com, keerthanak@vmware.com, Ankit Jain" , Glenn Elliott , Daniel Bristot de Oliveira , Juri Lelli , "Peter Zijlstra (Intel)" , Ankit Jain Subject: [PATCH 5.4 10/77] sched/deadline: Fix priority inheritance with multiple scheduling classes Date: Fri, 2 Sep 2022 14:18:19 +0200 Message-Id: <20220902121403.961350037@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Juri Lelli commit 2279f540ea7d05f22d2f0c4224319330228586bc upstream. Glenn reported that "an application [he developed produces] a BUG in deadline.c when a SCHED_DEADLINE task contends with CFS tasks on nested PTHREAD_PRIO_INHERIT mutexes. I believe the bug is triggered when a CFS task that was boosted by a SCHED_DEADLINE task boosts another CFS task (nested priority inheritance). ------------[ cut here ]------------ kernel BUG at kernel/sched/deadline.c:1462! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 12 PID: 19171 Comm: dl_boost_bug Tainted: ... Hardware name: ... RIP: 0010:enqueue_task_dl+0x335/0x910 Code: ... RSP: 0018:ffffc9000c2bbc68 EFLAGS: 00010002 RAX: 0000000000000009 RBX: ffff888c0af94c00 RCX: ffffffff81e12500 RDX: 000000000000002e RSI: ffff888c0af94c00 RDI: ffff888c10b22600 RBP: ffffc9000c2bbd08 R08: 0000000000000009 R09: 0000000000000078 R10: ffffffff81e12440 R11: ffffffff81e1236c R12: ffff888bc8932600 R13: ffff888c0af94eb8 R14: ffff888c10b22600 R15: ffff888bc8932600 FS: 00007fa58ac55700(0000) GS:ffff888c10b00000(0000) knlGS:00000000000000= 00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa58b523230 CR3: 0000000bf44ab003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? intel_pstate_update_util_hwp+0x13/0x170 rt_mutex_setprio+0x1cc/0x4b0 task_blocks_on_rt_mutex+0x225/0x260 rt_spin_lock_slowlock_locked+0xab/0x2d0 rt_spin_lock_slowlock+0x50/0x80 hrtimer_grab_expiry_lock+0x20/0x30 hrtimer_cancel+0x13/0x30 do_nanosleep+0xa0/0x150 hrtimer_nanosleep+0xe1/0x230 ? __hrtimer_init_sleeper+0x60/0x60 __x64_sys_nanosleep+0x8d/0xa0 do_syscall_64+0x4a/0x100 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fa58b52330d ... ---[ end trace 0000000000000002 ]=E2=80=94 He also provided a simple reproducer creating the situation below: So the execution order of locking steps are the following (N1 and N2 are non-deadline tasks. D1 is a deadline task. M1 and M2 are mutexes that are enabled * with priority inheritance.) Time moves forward as this timeline goes down: N1 N2 D1 | | | | | | Lock(M1) | | | | | | Lock(M2) | | | | | | Lock(M2) | | | | Lock(M1) | | (!!bug triggered!) | Daniel reported a similar situation as well, by just letting ksoftirqd run with DEADLINE (and eventually block on a mutex). Problem is that boosted entities (Priority Inheritance) use static DEADLINE parameters of the top priority waiter. However, there might be cases where top waiter could be a non-DEADLINE entity that is currently boosted by a DEADLINE entity from a different lock chain (i.e., nested priority chains involving entities of non-DEADLINE classes). In this case, top waiter static DEADLINE parameters could be null (initialized to 0 at fork()) and replenish_dl_entity() would hit a BUG(). Fix this by keeping track of the original donor and using its parameters when a task is boosted. Reported-by: Glenn Elliott Reported-by: Daniel Bristot de Oliveira Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Tested-by: Daniel Bristot de Oliveira Link: https://lkml.kernel.org/r/20201117061432.517340-1-juri.lelli@redhat.c= om [Ankit: Regenerated the patch for v5.4.y] Signed-off-by: Ankit Jain Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/sched.h | 10 ++++ kernel/sched/core.c | 11 ++--- kernel/sched/deadline.c | 97 ++++++++++++++++++++++++++-----------------= ----- 3 files changed, 68 insertions(+), 50 deletions(-) --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -544,7 +544,6 @@ struct sched_dl_entity { * overruns. */ unsigned int dl_throttled : 1; - unsigned int dl_boosted : 1; unsigned int dl_yielded : 1; unsigned int dl_non_contending : 1; unsigned int dl_overrun : 1; @@ -563,6 +562,15 @@ struct sched_dl_entity { * time. */ struct hrtimer inactive_timer; + +#ifdef CONFIG_RT_MUTEXES + /* + * Priority Inheritance. When a DEADLINE scheduling entity is boosted + * pi_se points to the donor, otherwise points to the dl_se it belongs + * to (the original one/itself). + */ + struct sched_dl_entity *pi_se; +#endif }; =20 #ifdef CONFIG_UCLAMP_TASK --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4554,20 +4554,21 @@ void rt_mutex_setprio(struct task_struct if (!dl_prio(p->normal_prio) || (pi_task && dl_prio(pi_task->prio) && dl_entity_preempt(&pi_task->dl, &p->dl))) { - p->dl.dl_boosted =3D 1; + p->dl.pi_se =3D pi_task->dl.pi_se; queue_flag |=3D ENQUEUE_REPLENISH; - } else - p->dl.dl_boosted =3D 0; + } else { + p->dl.pi_se =3D &p->dl; + } p->sched_class =3D &dl_sched_class; } else if (rt_prio(prio)) { if (dl_prio(oldprio)) - p->dl.dl_boosted =3D 0; + p->dl.pi_se =3D &p->dl; if (oldprio < prio) queue_flag |=3D ENQUEUE_HEAD; p->sched_class =3D &rt_sched_class; } else { if (dl_prio(oldprio)) - p->dl.dl_boosted =3D 0; + p->dl.pi_se =3D &p->dl; if (rt_prio(oldprio)) p->rt.timeout =3D 0; p->sched_class =3D &fair_sched_class; --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -43,6 +43,28 @@ static inline int on_dl_rq(struct sched_ return !RB_EMPTY_NODE(&dl_se->rb_node); } =20 +#ifdef CONFIG_RT_MUTEXES +static inline struct sched_dl_entity *pi_of(struct sched_dl_entity *dl_se) +{ + return dl_se->pi_se; +} + +static inline bool is_dl_boosted(struct sched_dl_entity *dl_se) +{ + return pi_of(dl_se) !=3D dl_se; +} +#else +static inline struct sched_dl_entity *pi_of(struct sched_dl_entity *dl_se) +{ + return dl_se; +} + +static inline bool is_dl_boosted(struct sched_dl_entity *dl_se) +{ + return false; +} +#endif + #ifdef CONFIG_SMP static inline struct dl_bw *dl_bw_of(int i) { @@ -657,7 +679,7 @@ static inline void setup_new_dl_entity(s struct dl_rq *dl_rq =3D dl_rq_of_se(dl_se); struct rq *rq =3D rq_of_dl_rq(dl_rq); =20 - WARN_ON(dl_se->dl_boosted); + WARN_ON(is_dl_boosted(dl_se)); WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline)); =20 /* @@ -695,21 +717,20 @@ static inline void setup_new_dl_entity(s * could happen are, typically, a entity voluntarily trying to overcome its * runtime, or it just underestimated it during sched_setattr(). */ -static void replenish_dl_entity(struct sched_dl_entity *dl_se, - struct sched_dl_entity *pi_se) +static void replenish_dl_entity(struct sched_dl_entity *dl_se) { struct dl_rq *dl_rq =3D dl_rq_of_se(dl_se); struct rq *rq =3D rq_of_dl_rq(dl_rq); =20 - BUG_ON(pi_se->dl_runtime <=3D 0); + BUG_ON(pi_of(dl_se)->dl_runtime <=3D 0); =20 /* * This could be the case for a !-dl task that is boosted. * Just go with full inherited parameters. */ if (dl_se->dl_deadline =3D=3D 0) { - dl_se->deadline =3D rq_clock(rq) + pi_se->dl_deadline; - dl_se->runtime =3D pi_se->dl_runtime; + dl_se->deadline =3D rq_clock(rq) + pi_of(dl_se)->dl_deadline; + dl_se->runtime =3D pi_of(dl_se)->dl_runtime; } =20 if (dl_se->dl_yielded && dl_se->runtime > 0) @@ -722,8 +743,8 @@ static void replenish_dl_entity(struct s * arbitrary large. */ while (dl_se->runtime <=3D 0) { - dl_se->deadline +=3D pi_se->dl_period; - dl_se->runtime +=3D pi_se->dl_runtime; + dl_se->deadline +=3D pi_of(dl_se)->dl_period; + dl_se->runtime +=3D pi_of(dl_se)->dl_runtime; } =20 /* @@ -737,8 +758,8 @@ static void replenish_dl_entity(struct s */ if (dl_time_before(dl_se->deadline, rq_clock(rq))) { printk_deferred_once("sched: DL replenish lagged too much\n"); - dl_se->deadline =3D rq_clock(rq) + pi_se->dl_deadline; - dl_se->runtime =3D pi_se->dl_runtime; + dl_se->deadline =3D rq_clock(rq) + pi_of(dl_se)->dl_deadline; + dl_se->runtime =3D pi_of(dl_se)->dl_runtime; } =20 if (dl_se->dl_yielded) @@ -771,8 +792,7 @@ static void replenish_dl_entity(struct s * task with deadline equal to period this is the same of using * dl_period instead of dl_deadline in the equation above. */ -static bool dl_entity_overflow(struct sched_dl_entity *dl_se, - struct sched_dl_entity *pi_se, u64 t) +static bool dl_entity_overflow(struct sched_dl_entity *dl_se, u64 t) { u64 left, right; =20 @@ -794,9 +814,9 @@ static bool dl_entity_overflow(struct sc * of anything below microseconds resolution is actually fiction * (but still we want to give the user that illusion >;). */ - left =3D (pi_se->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_SCALE); + left =3D (pi_of(dl_se)->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_= SCALE); right =3D ((dl_se->deadline - t) >> DL_SCALE) * - (pi_se->dl_runtime >> DL_SCALE); + (pi_of(dl_se)->dl_runtime >> DL_SCALE); =20 return dl_time_before(right, left); } @@ -881,24 +901,23 @@ static inline bool dl_is_implicit(struct * Please refer to the comments update_dl_revised_wakeup() function to find * more about the Revised CBS rule. */ -static void update_dl_entity(struct sched_dl_entity *dl_se, - struct sched_dl_entity *pi_se) +static void update_dl_entity(struct sched_dl_entity *dl_se) { struct dl_rq *dl_rq =3D dl_rq_of_se(dl_se); struct rq *rq =3D rq_of_dl_rq(dl_rq); =20 if (dl_time_before(dl_se->deadline, rq_clock(rq)) || - dl_entity_overflow(dl_se, pi_se, rq_clock(rq))) { + dl_entity_overflow(dl_se, rq_clock(rq))) { =20 if (unlikely(!dl_is_implicit(dl_se) && !dl_time_before(dl_se->deadline, rq_clock(rq)) && - !dl_se->dl_boosted)){ + !is_dl_boosted(dl_se))) { update_dl_revised_wakeup(dl_se, rq); return; } =20 - dl_se->deadline =3D rq_clock(rq) + pi_se->dl_deadline; - dl_se->runtime =3D pi_se->dl_runtime; + dl_se->deadline =3D rq_clock(rq) + pi_of(dl_se)->dl_deadline; + dl_se->runtime =3D pi_of(dl_se)->dl_runtime; } } =20 @@ -997,7 +1016,7 @@ static enum hrtimer_restart dl_task_time * The task might have been boosted by someone else and might be in the * boosting/deboosting path, its not throttled. */ - if (dl_se->dl_boosted) + if (is_dl_boosted(dl_se)) goto unlock; =20 /* @@ -1025,7 +1044,7 @@ static enum hrtimer_restart dl_task_time * but do not enqueue -- wait for our wakeup to do that. */ if (!task_on_rq_queued(p)) { - replenish_dl_entity(dl_se, dl_se); + replenish_dl_entity(dl_se); goto unlock; } =20 @@ -1115,7 +1134,7 @@ static inline void dl_check_constrained_ =20 if (dl_time_before(dl_se->deadline, rq_clock(rq)) && dl_time_before(rq_clock(rq), dl_next_period(dl_se))) { - if (unlikely(dl_se->dl_boosted || !start_dl_timer(p))) + if (unlikely(is_dl_boosted(dl_se) || !start_dl_timer(p))) return; dl_se->dl_throttled =3D 1; if (dl_se->runtime > 0) @@ -1246,7 +1265,7 @@ throttle: dl_se->dl_overrun =3D 1; =20 __dequeue_task_dl(rq, curr, 0); - if (unlikely(dl_se->dl_boosted || !start_dl_timer(curr))) + if (unlikely(is_dl_boosted(dl_se) || !start_dl_timer(curr))) enqueue_task_dl(rq, curr, ENQUEUE_REPLENISH); =20 if (!is_leftmost(curr, &rq->dl)) @@ -1440,8 +1459,7 @@ static void __dequeue_dl_entity(struct s } =20 static void -enqueue_dl_entity(struct sched_dl_entity *dl_se, - struct sched_dl_entity *pi_se, int flags) +enqueue_dl_entity(struct sched_dl_entity *dl_se, int flags) { BUG_ON(on_dl_rq(dl_se)); =20 @@ -1452,9 +1470,9 @@ enqueue_dl_entity(struct sched_dl_entity */ if (flags & ENQUEUE_WAKEUP) { task_contending(dl_se, flags); - update_dl_entity(dl_se, pi_se); + update_dl_entity(dl_se); } else if (flags & ENQUEUE_REPLENISH) { - replenish_dl_entity(dl_se, pi_se); + replenish_dl_entity(dl_se); } else if ((flags & ENQUEUE_RESTORE) && dl_time_before(dl_se->deadline, rq_clock(rq_of_dl_rq(dl_rq_of_se(dl_se))))) { @@ -1471,19 +1489,7 @@ static void dequeue_dl_entity(struct sch =20 static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flag= s) { - struct task_struct *pi_task =3D rt_mutex_get_top_task(p); - struct sched_dl_entity *pi_se =3D &p->dl; - - /* - * Use the scheduling parameters of the top pi-waiter task if: - * - we have a top pi-waiter which is a SCHED_DEADLINE task AND - * - our dl_boosted is set (i.e. the pi-waiter's (absolute) deadline is - * smaller than our deadline OR we are a !SCHED_DEADLINE task getting - * boosted due to a SCHED_DEADLINE pi-waiter). - * Otherwise we keep our runtime and deadline. - */ - if (pi_task && dl_prio(pi_task->normal_prio) && p->dl.dl_boosted) { - pi_se =3D &pi_task->dl; + if (is_dl_boosted(&p->dl)) { /* * Because of delays in the detection of the overrun of a * thread's runtime, it might be the case that a thread @@ -1516,7 +1522,7 @@ static void enqueue_task_dl(struct rq *r * the throttle. */ p->dl.dl_throttled =3D 0; - BUG_ON(!p->dl.dl_boosted || flags !=3D ENQUEUE_REPLENISH); + BUG_ON(!is_dl_boosted(&p->dl) || flags !=3D ENQUEUE_REPLENISH); return; } =20 @@ -1553,7 +1559,7 @@ static void enqueue_task_dl(struct rq *r return; } =20 - enqueue_dl_entity(&p->dl, pi_se, flags); + enqueue_dl_entity(&p->dl, flags); =20 if (!task_current(rq, p) && p->nr_cpus_allowed > 1) enqueue_pushable_dl_task(rq, p); @@ -2722,11 +2728,14 @@ void __dl_clear_params(struct task_struc dl_se->dl_bw =3D 0; dl_se->dl_density =3D 0; =20 - dl_se->dl_boosted =3D 0; dl_se->dl_throttled =3D 0; dl_se->dl_yielded =3D 0; dl_se->dl_non_contending =3D 0; dl_se->dl_overrun =3D 0; + +#ifdef CONFIG_RT_MUTEXES + dl_se->pi_se =3D dl_se; +#endif } =20 bool dl_param_changed(struct task_struct *p, const struct sched_attr *attr) From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49C9EECAAD5 for ; Fri, 2 Sep 2022 12:34:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236802AbiIBMeS (ORCPT ); Fri, 2 Sep 2022 08:34:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236485AbiIBMdH (ORCPT ); Fri, 2 Sep 2022 08:33:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84F6BDCFC8; Fri, 2 Sep 2022 05:27:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4350EB82A9D; Fri, 2 Sep 2022 12:27:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94750C433C1; Fri, 2 Sep 2022 12:26:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121620; bh=bRiPDlXCDnM6znqFqZQEveROcMOJjK1l/Tq9ZMM5NYk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JtmJ51XYJ/Ac9oNtuIBMHgFoVjcyEAFuszRfuhBUKpi9W7QHwd0a0x4BB8Bg8dPPr DVWCf4OL7DL1d5OtvX7Q55CsYfSvuFKmjIaqsEU75lr2lXvlNCHeSiAuiHUpT1KxG/ A3dzKxcTVKj4q/LXDOmoWHtzHi4s16TzHgWNrw98= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "srivatsab@vmware.com, srivatsa@csail.mit.edu, akaher@vmware.com, amakhalov@vmware.com, vsirnapalli@vmware.com, sturlapati@vmware.com, bordoloih@vmware.com, keerthanak@vmware.com, Ankit Jain" , Hui Su , "Peter Zijlstra (Intel)" , Daniel Bristot de Oliveira , Ankit Jain Subject: [PATCH 5.4 11/77] kernel/sched: Remove dl_boosted flag comment Date: Fri, 2 Sep 2022 14:18:20 +0200 Message-Id: <20220902121403.999666791@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hui Su commit 0e3872499de1a1230cef5221607d71aa09264bd5 upstream. since commit 2279f540ea7d ("sched/deadline: Fix priority inheritance with multiple scheduling classes"), we should not keep it here. Signed-off-by: Hui Su Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Daniel Bristot de Oliveira Link: https://lore.kernel.org/r/20220107095254.GA49258@localhost.localdomain [Ankit: Regenerated the patch for v5.4.y] Signed-off-by: Ankit Jain Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/sched.h | 4 ---- 1 file changed, 4 deletions(-) --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -526,10 +526,6 @@ struct sched_dl_entity { * task has to wait for a replenishment to be performed at the * next firing of dl_timer. * - * @dl_boosted tells if we are boosted due to DI. If so we are - * outside bandwidth enforcement mechanism (but only until we - * exit the critical section); - * * @dl_yielded tells if task gave up the CPU before consuming * all its available runtime during the last job. * From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B859C38145 for ; Fri, 2 Sep 2022 12:36:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237013AbiIBMgz (ORCPT ); Fri, 2 Sep 2022 08:36:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236307AbiIBMgB (ORCPT ); Fri, 2 Sep 2022 08:36:01 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED082DF08E; Fri, 2 Sep 2022 05:28:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7D11E62175; Fri, 2 Sep 2022 12:27:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F4F0C433C1; Fri, 2 Sep 2022 12:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121622; bh=nFoK8rVsPQz6rYmkyOvn9UVwRfW92AskwAEHqocBEC4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LGwYrI9gPU5HDSiBVXUORtVUwkOcGlf6+rhsEstc1aZn/7gK2BxH9BeXYsP9eADKk xlDK+us3c3jlw3TsVAUrYCMjoamP+oKvW8CSYPyHKuzPgaUjeyAqZOm8Ba6wuPWjQo UgoP7TZqUzUs76S9pZ4OVXmCB2p4/9CN5IHce5Dc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xin Xiong , Xin Tan , Steffen Klassert , Sasha Levin Subject: [PATCH 5.4 12/77] xfrm: fix refcount leak in __xfrm_policy_check() Date: Fri, 2 Sep 2022 14:18:21 +0200 Message-Id: <20220902121404.047115996@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Xin Xiong [ Upstream commit 9c9cb23e00ddf45679b21b4dacc11d1ae7961ebe ] The issue happens on an error path in __xfrm_policy_check(). When the fetching process of the object `pols[1]` fails, the function simply returns 0, forgetting to decrement the reference count of `pols[0]`, which is incremented earlier by either xfrm_sk_policy_lookup() or xfrm_policy_lookup(). This may result in memory leaks. Fix it by decreasing the reference count of `pols[0]` in that path. Fixes: 134b0fc544ba ("IPsec: propagate security module errors up from flow_= cache_lookup") Signed-off-by: Xin Xiong Signed-off-by: Xin Tan Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/xfrm/xfrm_policy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index 28a8cdef8e51f..6f58be5a17711 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -3619,6 +3619,7 @@ int __xfrm_policy_check(struct sock *sk, int dir, str= uct sk_buff *skb, if (pols[1]) { if (IS_ERR(pols[1])) { XFRM_INC_STATS(net, LINUX_MIB_XFRMINPOLERROR); + xfrm_pol_put(pols[0]); return 0; } pols[1]->curlft.use_time =3D ktime_get_real_seconds(); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE245C38145 for ; Fri, 2 Sep 2022 13:04:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238695AbiIBNDl (ORCPT ); Fri, 2 Sep 2022 09:03:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236362AbiIBNDE (ORCPT ); Fri, 2 Sep 2022 09:03:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FEDC10DE72; Fri, 2 Sep 2022 05:41:47 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 58C6462162; Fri, 2 Sep 2022 12:27:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CA3EC433D6; Fri, 2 Sep 2022 12:27:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121625; bh=ApNfnb3FFa3CMZAD9qK8lMfCD5QMDVBULyhY9SBxFn0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lai89Atjv8L3hmrlkt463ckhLCklHyoJwpR1imTccwhf4hUED02pF/0HpAi4hsaCw JzBR6LSKR/xiI+KptCSOieQpeimx8KiA/mVKN+ESDbPu6dY0piLeOzVyLmPEFnS8WS PfbogGrk8I536HGUHu4jNUq/RZkvEFE4ALoFin2E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Abhishek Shah , Herbert Xu , Steffen Klassert , Sasha Levin Subject: [PATCH 5.4 13/77] af_key: Do not call xfrm_probe_algs in parallel Date: Fri, 2 Sep 2022 14:18:22 +0200 Message-Id: <20220902121404.080846598@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Herbert Xu [ Upstream commit ba953a9d89a00c078b85f4b190bc1dde66fe16b5 ] When namespace support was added to xfrm/afkey, it caused the previously single-threaded call to xfrm_probe_algs to become multi-threaded. This is buggy and needs to be fixed with a mutex. Reported-by: Abhishek Shah Fixes: 283bc9f35bbb ("xfrm: Namespacify xfrm state/policy locks") Signed-off-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/key/af_key.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/key/af_key.c b/net/key/af_key.c index 32fe99cd01fc8..c06cc48c68c90 100644 --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -1701,9 +1701,12 @@ static int pfkey_register(struct sock *sk, struct sk= _buff *skb, const struct sad pfk->registered |=3D (1<sadb_msg_satype); } =20 + mutex_lock(&pfkey_mutex); xfrm_probe_algs(); =20 supp_skb =3D compose_sadb_supported(hdr, GFP_KERNEL | __GFP_ZERO); + mutex_unlock(&pfkey_mutex); + if (!supp_skb) { if (hdr->sadb_msg_satype !=3D SADB_SATYPE_UNSPEC) pfk->registered &=3D ~(1<sadb_msg_satype); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1474FECAAD5 for ; Fri, 2 Sep 2022 12:32:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236794AbiIBMcr (ORCPT ); Fri, 2 Sep 2022 08:32:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236439AbiIBMbl (ORCPT ); Fri, 2 Sep 2022 08:31:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C516EE1AB9; Fri, 2 Sep 2022 05:27:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 37B7662178; Fri, 2 Sep 2022 12:27:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44C78C433C1; Fri, 2 Sep 2022 12:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121628; bh=kbqhYeilcXusCl2mgIc1i1PvjLcthAyrfbJIfvIOEj0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QuDpzGb8XWWjG0GNaKGC1fjwzIV8V/h/uqv9ifn/e1uCiMT0d5pjnvRQO8TxjI9KF GVR73UIT1qF34ScWmVtyqEgDU03DXrduB6/1m8BvlgY/bFO5GpFGd4G69/vzRvPAIV m0HJ3MTCXMGu6r2LhQVDfsNCzPLkAftJgkltYdd0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Sasha Levin Subject: [PATCH 5.4 14/77] SUNRPC: RPC level errors should set task->tk_rpc_status Date: Fri, 2 Sep 2022 14:18:23 +0200 Message-Id: <20220902121404.110025520@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Trond Myklebust [ Upstream commit ed06fce0b034b2e25bd93430f5c4cbb28036cc1a ] Fix up a case in call_encode() where we're failing to set task->tk_rpc_status when an RPC level error occurred. Fixes: 9c5948c24869 ("SUNRPC: task should be exit if encode return EKEYEXPI= RED more times") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/sunrpc/clnt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c index 08e1ccc01e983..1893203cc94fc 100644 --- a/net/sunrpc/clnt.c +++ b/net/sunrpc/clnt.c @@ -1896,7 +1896,7 @@ call_encode(struct rpc_task *task) break; case -EKEYEXPIRED: if (!task->tk_cred_retry) { - rpc_exit(task, task->tk_status); + rpc_call_rpcerror(task, task->tk_status); } else { task->tk_action =3D call_refresh; task->tk_cred_retry--; --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A544C6FA85 for ; Fri, 2 Sep 2022 12:34:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236490AbiIBMeL (ORCPT ); Fri, 2 Sep 2022 08:34:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236771AbiIBMch (ORCPT ); Fri, 2 Sep 2022 08:32:37 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88B36D6326; Fri, 2 Sep 2022 05:27:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E56C7B829B6; Fri, 2 Sep 2022 12:27:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5012CC433D6; Fri, 2 Sep 2022 12:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121631; bh=IKqqejYC51+KE+xS6pnujKBsGdECRe7c/5XlbeSemxM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fpOmweiydQSlntTGcvudOCMhHb1aHtAJ+vbsJBHxyDpXZsAZmmWgdYqdssGdjofkd HoXqTWolUy1Pun6TsosC7audahQEuGkB/JqF7GSwWNy8mAC96JAHHdWVVjiAbFnG8C JhUUCesPEQxl7w2xLGsrw/jxSM6fCRTAKAIk+8QI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bernard Pidoux , Francois Romieu , Thomas DL9SAU Osterried , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 15/77] rose: check NULL rose_loopback_neigh->loopback Date: Fri, 2 Sep 2022 14:18:24 +0200 Message-Id: <20220902121404.142699750@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Bernard Pidoux [ Upstream commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ] Commit 3b3fd068c56e3fbea30090859216a368398e39bf added NULL check for `rose_loopback_neigh->dev` in rose_loopback_timer() but omitted to check rose_loopback_neigh->loopback. It thus prevents *all* rose connect. The reason is that a special rose_neigh loopback has a NULL device. /proc/net/rose_neigh illustrates it via rose_neigh_show() function : [...] seq_printf(seq, "%05d %-9s %-4s %3d %3d %3s %3s %3lu %3lu", rose_neigh->number, (rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(buf, &rose_neigh->callsign= ), rose_neigh->dev ? rose_neigh->dev->name : "???", rose_neigh->count, /proc/net/rose_neigh displays special rose_loopback_neigh->loopback as callsign RSLOOP-0: addr callsign dev count use mode restart t0 tf digipeaters 00001 RSLOOP-0 ??? 1 2 DCE yes 0 0 By checking rose_loopback_neigh->loopback, rose_rx_call_request() is called even in case rose_loopback_neigh->dev is NULL. This repairs rose connection= s. Verification with rose client application FPAC: FPAC-Node v 4.1.3 (built Aug 5 2022) for LINUX (help =3D h) F6BVP-4 (Commands =3D ?) : u Users - AX.25 Level 2 sessions : Port Callsign Callsign AX.25 state ROSE state NetRom status axudp F6BVP-5 -> F6BVP-9 Connected Connected --------- Fixes: 3b3fd068c56e ("rose: Fix Null pointer dereference in rose_send_frame= ()") Signed-off-by: Bernard Pidoux Suggested-by: Francois Romieu Cc: Thomas DL9SAU Osterried Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/rose/rose_loopback.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c index 11c45c8c6c164..036d92c0ad794 100644 --- a/net/rose/rose_loopback.c +++ b/net/rose/rose_loopback.c @@ -96,7 +96,8 @@ static void rose_loopback_timer(struct timer_list *unused) } =20 if (frametype =3D=3D ROSE_CALL_REQUEST) { - if (!rose_loopback_neigh->dev) { + if (!rose_loopback_neigh->dev && + !rose_loopback_neigh->loopback) { kfree_skb(skb); continue; } --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 291C7C38145 for ; Fri, 2 Sep 2022 12:36:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237049AbiIBMgv (ORCPT ); Fri, 2 Sep 2022 08:36:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236718AbiIBMf6 (ORCPT ); Fri, 2 Sep 2022 08:35:58 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17AA8DDB46; Fri, 2 Sep 2022 05:29:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 52A34B82AA7; Fri, 2 Sep 2022 12:27:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5672AC433D6; Fri, 2 Sep 2022 12:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121635; bh=2V1w68Fy2o1YhSqtTCc+epSatNmmazG7elgRFq6rYWU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P7P5jS48qWFFWJWDT47tze/NW/MdnM/HAQMWY8c6WXyCgcDmNlFKAL4Hr08j0bRwe OcVxW+KTs/+wuskY57LQiH+xb+UMI+iZRINIkVHt/QZ4ZJsaQ58GuAF5mqSybWy+tv CNsW4M+6kqxJVb5uPdulmAvd8YiuHItvcy36aTDo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vlad Buslov , Roi Dayan , Saeed Mahameed , Sasha Levin Subject: [PATCH 5.4 16/77] net/mlx5e: Properly disable vlan strip on non-UL reps Date: Fri, 2 Sep 2022 14:18:25 +0200 Message-Id: <20220902121404.186661786@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vlad Buslov [ Upstream commit f37044fd759b6bc40b6398a978e0b1acdf717372 ] When querying mlx5 non-uplink representors capabilities with ethtool rx-vlan-offload is marked as "off [fixed]". However, it is actually always enabled because mlx5e_params->vlan_strip_disable is 0 by default when initializing struct mlx5e_params instance. Fix the issue by explicitly setting the vlan_strip_disable to 'true' for non-uplink representors. Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors") Signed-off-by: Vlad Buslov Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net= /ethernet/mellanox/mlx5/core/en_rep.c index 88b51f64a64ea..f448a139e222e 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c @@ -1434,6 +1434,8 @@ static void mlx5e_build_rep_params(struct net_device = *netdev) =20 params->num_tc =3D 1; params->tunneled_offload_en =3D false; + if (rep->vport !=3D MLX5_VPORT_UPLINK) + params->vlan_strip_disable =3D true; =20 mlx5_query_min_inline(mdev, ¶ms->tx_min_inline_mode); =20 --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D062EC38145 for ; Fri, 2 Sep 2022 12:33:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236288AbiIBMd1 (ORCPT ); Fri, 2 Sep 2022 08:33:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236594AbiIBMc3 (ORCPT ); Fri, 2 Sep 2022 08:32:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B9D7E2C48; Fri, 2 Sep 2022 05:27:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5A714B82AA1; Fri, 2 Sep 2022 12:27:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1E0FC43142; Fri, 2 Sep 2022 12:27:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121638; bh=zFzdsXRNGhgpzL0zy6R6uex/IZJ/4hFDVtMV0UFxGGQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nkfge/YHGBiS88Od/englGEB8q01UjlCPro340LFXlSmKmwFn+ZvHaOZw3e0mL3IQ 9sEyVtLIQIPBvo9Iyd/N5L2CX9TKR92/RUW/Owjo8gfc+XFNiOEjQc9d6BjE9Zhkyo chV6EnLYXsQcCdAIoanSoGdh8b/6T7OMMHJida4g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sergei Antonov , Andrew Lunn , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 17/77] net: moxa: get rid of asymmetry in DMA mapping/unmapping Date: Fri, 2 Sep 2022 14:18:26 +0200 Message-Id: <20220902121404.221001880@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Sergei Antonov [ Upstream commit 0ee7828dfc56e97d71e51e6374dc7b4eb2b6e081 ] Since priv->rx_mapping[i] is maped in moxart_mac_open(), we should unmap it from moxart_mac_stop(). Fixes 2 warnings. 1. During error unwinding in moxart_mac_probe(): "goto init_fail;", then moxart_mac_free_memory() calls dma_unmap_single() with priv->rx_mapping[i] pointers zeroed. WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:963 check_unmap+0x704/0x980 DMA-API: moxart-ethernet 92000000.mac: device driver tries to free DMA memo= ry it has not allocated [device address=3D0x0000000000000000] [size=3D1600 = bytes] CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0+ #60 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0xbc/0x1f0 __warn from warn_slowpath_fmt+0x94/0xc8 warn_slowpath_fmt from check_unmap+0x704/0x980 check_unmap from debug_dma_unmap_page+0x8c/0x9c debug_dma_unmap_page from moxart_mac_free_memory+0x3c/0xa8 moxart_mac_free_memory from moxart_mac_probe+0x190/0x218 moxart_mac_probe from platform_probe+0x48/0x88 platform_probe from really_probe+0xc0/0x2e4 2. After commands: ip link set dev eth0 down ip link set dev eth0 up WARNING: CPU: 0 PID: 55 at kernel/dma/debug.c:570 add_dma_entry+0x204/0x2ec DMA-API: moxart-ethernet 92000000.mac: cacheline tracking EEXIST, overlappi= ng mappings aren't supported CPU: 0 PID: 55 Comm: ip Not tainted 5.19.0+ #57 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0xbc/0x1f0 __warn from warn_slowpath_fmt+0x94/0xc8 warn_slowpath_fmt from add_dma_entry+0x204/0x2ec add_dma_entry from dma_map_page_attrs+0x110/0x328 dma_map_page_attrs from moxart_mac_open+0x134/0x320 moxart_mac_open from __dev_open+0x11c/0x1ec __dev_open from __dev_change_flags+0x194/0x22c __dev_change_flags from dev_change_flags+0x14/0x44 dev_change_flags from devinet_ioctl+0x6d4/0x93c devinet_ioctl from inet_ioctl+0x1ac/0x25c v1 -> v2: Extraneous change removed. Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Sergei Antonov Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220819110519.1230877-1-saproj@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/moxa/moxart_ether.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/etherne= t/moxa/moxart_ether.c index 383d72415c659..87327086ea8ca 100644 --- a/drivers/net/ethernet/moxa/moxart_ether.c +++ b/drivers/net/ethernet/moxa/moxart_ether.c @@ -74,11 +74,6 @@ static int moxart_set_mac_address(struct net_device *nde= v, void *addr) static void moxart_mac_free_memory(struct net_device *ndev) { struct moxart_mac_priv_t *priv =3D netdev_priv(ndev); - int i; - - for (i =3D 0; i < RX_DESC_NUM; i++) - dma_unmap_single(&priv->pdev->dev, priv->rx_mapping[i], - priv->rx_buf_size, DMA_FROM_DEVICE); =20 if (priv->tx_desc_base) dma_free_coherent(&priv->pdev->dev, @@ -193,6 +188,7 @@ static int moxart_mac_open(struct net_device *ndev) static int moxart_mac_stop(struct net_device *ndev) { struct moxart_mac_priv_t *priv =3D netdev_priv(ndev); + int i; =20 napi_disable(&priv->napi); =20 @@ -204,6 +200,11 @@ static int moxart_mac_stop(struct net_device *ndev) /* disable all functions */ writel(0, priv->base + REG_MAC_CTRL); =20 + /* unmap areas mapped in moxart_mac_setup_desc_ring() */ + for (i =3D 0; i < RX_DESC_NUM; i++) + dma_unmap_single(&priv->pdev->dev, priv->rx_mapping[i], + priv->rx_buf_size, DMA_FROM_DEVICE); + return 0; } =20 --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91C21C54EE9 for ; Fri, 2 Sep 2022 12:53:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237959AbiIBMxY (ORCPT ); Fri, 2 Sep 2022 08:53:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237789AbiIBMwd (ORCPT ); Fri, 2 Sep 2022 08:52:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C557B40E38; Fri, 2 Sep 2022 05:37:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 822AD6216B; Fri, 2 Sep 2022 12:27:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C21DC433D6; Fri, 2 Sep 2022 12:27:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121641; bh=gt0UaEL2EYFti/7td2KjomCYoDqgD0W6yquoeZjAdmw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RcGff9eCakdeaIV/3OM2AjxMXft7xoW7H/AeQQZ3OQn3eHMUxrjYdDVTrYjJW7ZOA XS0Znjy+XtJvwsnMVwF1H98YRn64amY0fLaOmTN9qKoDEX44NhdXHmOY71uyKLK1S7 XBHrAPxy6Sr5yIEvFjpcQaIs+nNYlM/nMYW+hPb0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jonathan Toppins , Jay Vosburgh , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 18/77] bonding: 802.3ad: fix no transmission of LACPDUs Date: Fri, 2 Sep 2022 14:18:27 +0200 Message-Id: <20220902121404.250299542@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jonathan Toppins [ Upstream commit d745b5062ad2b5da90a5e728d7ca884fc07315fd ] This is caused by the global variable ad_ticks_per_sec being zero as demonstrated by the reproducer script discussed below. This causes all timer values in __ad_timer_to_ticks to be zero, resulting in the periodic timer to never fire. To reproduce: Run the script in `tools/testing/selftests/drivers/net/bonding/bond-break-lacpdu-tx.sh` which puts bonding into a state where it never transmits LACPDUs. line 44: ip link add fbond type bond mode 4 miimon 200 \ xmit_hash_policy 1 ad_actor_sys_prio 65535 lacp_rate fast setting bond param: ad_actor_sys_prio given: params.ad_actor_system =3D 0 call stack: bond_option_ad_actor_sys_prio() -> bond_3ad_update_ad_actor_settings() -> set ad.system.sys_priority =3D bond->params.ad_actor_sys_prio -> ad.system.sys_mac_addr =3D bond->dev->dev_addr; because params.ad_actor_system =3D=3D 0 results: ad.system.sys_mac_addr =3D bond->dev->dev_addr line 48: ip link set fbond address 52:54:00:3B:7C:A6 setting bond MAC addr call stack: bond->dev->dev_addr =3D new_mac line 52: ip link set fbond type bond ad_actor_sys_prio 65535 setting bond param: ad_actor_sys_prio given: params.ad_actor_system =3D 0 call stack: bond_option_ad_actor_sys_prio() -> bond_3ad_update_ad_actor_settings() -> set ad.system.sys_priority =3D bond->params.ad_actor_sys_prio -> ad.system.sys_mac_addr =3D bond->dev->dev_addr; because params.ad_actor_system =3D=3D 0 results: ad.system.sys_mac_addr =3D bond->dev->dev_addr line 60: ip link set veth1-bond down master fbond given: params.ad_actor_system =3D 0 params.mode =3D BOND_MODE_8023AD ad.system.sys_mac_addr =3D=3D bond->dev->dev_addr call stack: bond_enslave -> bond_3ad_initialize(); because first slave -> if ad.system.sys_mac_addr !=3D bond->dev->dev_addr return results: Nothing is run in bond_3ad_initialize() because dev_addr equals sys_mac_addr leaving the global ad_ticks_per_sec zero as it is never initialized anywhere else. The if check around the contents of bond_3ad_initialize() is no longer needed due to commit 5ee14e6d336f ("bonding: 3ad: apply ad_actor settings changes immediately") which sets ad.system.sys_mac_addr if any one of the bonding parameters whos set function calls bond_3ad_update_ad_actor_settings(). This is because if ad.system.sys_mac_addr is zero it will be set to the current bond mac address, this causes the if check to never be true. Fixes: 5ee14e6d336f ("bonding: 3ad: apply ad_actor settings changes immedia= tely") Signed-off-by: Jonathan Toppins Acked-by: Jay Vosburgh Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/bonding/bond_3ad.c | 38 ++++++++++++++-------------------- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c index 31ed7616e84e7..0d6cd2a4cc416 100644 --- a/drivers/net/bonding/bond_3ad.c +++ b/drivers/net/bonding/bond_3ad.c @@ -1997,30 +1997,24 @@ void bond_3ad_initiate_agg_selection(struct bonding= *bond, int timeout) */ void bond_3ad_initialize(struct bonding *bond, u16 tick_resolution) { - /* check that the bond is not initialized yet */ - if (!MAC_ADDRESS_EQUAL(&(BOND_AD_INFO(bond).system.sys_mac_addr), - bond->dev->dev_addr)) { - - BOND_AD_INFO(bond).aggregator_identifier =3D 0; - - BOND_AD_INFO(bond).system.sys_priority =3D - bond->params.ad_actor_sys_prio; - if (is_zero_ether_addr(bond->params.ad_actor_system)) - BOND_AD_INFO(bond).system.sys_mac_addr =3D - *((struct mac_addr *)bond->dev->dev_addr); - else - BOND_AD_INFO(bond).system.sys_mac_addr =3D - *((struct mac_addr *)bond->params.ad_actor_system); + BOND_AD_INFO(bond).aggregator_identifier =3D 0; + BOND_AD_INFO(bond).system.sys_priority =3D + bond->params.ad_actor_sys_prio; + if (is_zero_ether_addr(bond->params.ad_actor_system)) + BOND_AD_INFO(bond).system.sys_mac_addr =3D + *((struct mac_addr *)bond->dev->dev_addr); + else + BOND_AD_INFO(bond).system.sys_mac_addr =3D + *((struct mac_addr *)bond->params.ad_actor_system); =20 - /* initialize how many times this module is called in one - * second (should be about every 100ms) - */ - ad_ticks_per_sec =3D tick_resolution; + /* initialize how many times this module is called in one + * second (should be about every 100ms) + */ + ad_ticks_per_sec =3D tick_resolution; =20 - bond_3ad_initiate_agg_selection(bond, - AD_AGGREGATOR_SELECTION_TIMER * - ad_ticks_per_sec); - } + bond_3ad_initiate_agg_selection(bond, + AD_AGGREGATOR_SELECTION_TIMER * + ad_ticks_per_sec); } =20 /** --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E62DAC54EE9 for ; Fri, 2 Sep 2022 12:34:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236719AbiIBMeO (ORCPT ); Fri, 2 Sep 2022 08:34:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236307AbiIBMdF (ORCPT ); Fri, 2 Sep 2022 08:33:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE39EDD4E8; Fri, 2 Sep 2022 05:27:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 16628B82AB6; Fri, 2 Sep 2022 12:27:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A90BC433C1; Fri, 2 Sep 2022 12:27:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121643; bh=Sz3Q4UxT7dqoQblVzdJOQZ/hjUT/fosBNY6GHX19QdM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HrOjPGvxUtAI0boJvAL/HPRkRrhP2G6m3g0wUBnU775c2H03dPiQ9C7wICrW0H2fm CsczwrUukwGf7bpmPLgpAUqLLCh5cwOo7HSjyTZdqiWzJXxDz6mpDaSupTh3VATlIs XMY/3XttTvtMLRT8H5U1JMoQ79KErXMSwDXBFBe4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mahesh Bandewar , Sainath Grandhi , =?UTF-8?q?Maciej=20=C5=BBenczykowski?= , Paolo Abeni , Sasha Levin Subject: [PATCH 5.4 19/77] net: ipvtap - add __init/__exit annotations to module init/exit funcs Date: Fri, 2 Sep 2022 14:18:28 +0200 Message-Id: <20220902121404.283202582@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Maciej =C5=BBenczykowski [ Upstream commit 4b2e3a17e9f279325712b79fb01d1493f9e3e005 ] Looks to have been left out in an oversight. Cc: Mahesh Bandewar Cc: Sainath Grandhi Fixes: 235a9d89da97 ('ipvtap: IP-VLAN based tap driver') Signed-off-by: Maciej =C5=BBenczykowski Link: https://lore.kernel.org/r/20220821130808.12143-1-zenczykowski@gmail.c= om Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ipvlan/ipvtap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ipvlan/ipvtap.c b/drivers/net/ipvlan/ipvtap.c index 1cedb634f4f7b..f01078b2581ce 100644 --- a/drivers/net/ipvlan/ipvtap.c +++ b/drivers/net/ipvlan/ipvtap.c @@ -194,7 +194,7 @@ static struct notifier_block ipvtap_notifier_block __re= ad_mostly =3D { .notifier_call =3D ipvtap_device_event, }; =20 -static int ipvtap_init(void) +static int __init ipvtap_init(void) { int err; =20 @@ -228,7 +228,7 @@ static int ipvtap_init(void) } module_init(ipvtap_init); =20 -static void ipvtap_exit(void) +static void __exit ipvtap_exit(void) { rtnl_link_unregister(&ipvtap_link_ops); unregister_netdevice_notifier(&ipvtap_notifier_block); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B77CBECAAD5 for ; Fri, 2 Sep 2022 12:34:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236820AbiIBMeV (ORCPT ); Fri, 2 Sep 2022 08:34:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236814AbiIBMdI (ORCPT ); Fri, 2 Sep 2022 08:33:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC0422D1F2; Fri, 2 Sep 2022 05:27:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5AABBB82A9B; Fri, 2 Sep 2022 12:27:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BF4CC433C1; Fri, 2 Sep 2022 12:27:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121650; bh=pmq28BXMj4Tdpb6qQ51Uy3s38O2jMo6EChWRxf7GiOo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZXGDSvTKMBtjqBOC6RTCM3rbECMrRzvYA+IDIidOZb104lx1/dK7gwywq5WWg9i7i XDXNUByyQqxFpW1NM3fgr4Rym8YVyYVR2PmlJcKjL2JQOCvsvx1rnDzv4zz/zqtALp 3BMC1/qQOIYoYrCHiG+5AGc4pTYM66lFfOjnGHIU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Harshit Mogalapalli , syzkaller , Florian Westphal , Sasha Levin Subject: [PATCH 5.4 20/77] netfilter: ebtables: reject blobs that dont provide all entry points Date: Fri, 2 Sep 2022 14:18:29 +0200 Message-Id: <20220902121404.317136695@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Florian Westphal [ Upstream commit 7997eff82828304b780dc0a39707e1946d6f1ebf ] Harshit Mogalapalli says: In ebt_do_table() function dereferencing 'private->hook_entry[hook]' can lead to NULL pointer dereference. [..] Kernel panic: general protection fault, probably for non-canonical address 0xdffffc000000= 0005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [..] RIP: 0010:ebt_do_table+0x1dc/0x1ce0 Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 5c 16 00 00 48 b8 00 00 00 00 00 = fc ff df 49 8b 6c df 08 48 8d 7d 2c 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 8= 9 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 88 [..] Call Trace: nf_hook_slow+0xb1/0x170 __br_forward+0x289/0x730 maybe_deliver+0x24b/0x380 br_flood+0xc6/0x390 br_dev_xmit+0xa2e/0x12c0 For some reason ebtables rejects blobs that provide entry points that are not supported by the table, but what it should instead reject is the opposite: blobs that DO NOT provide an entry point supported by the table. t->valid_hooks is the bitmask of hooks (input, forward ...) that will see packets. Providing an entry point that is not support is harmless (never called/used), but the inverse isn't: it results in a crash because the ebtables traverser doesn't expect a NULL blob for a location its receiving packets for. Instead of fixing all the individual checks, do what iptables is doing and reject all blobs that differ from the expected hooks. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Harshit Mogalapalli Reported-by: syzkaller Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/netfilter_bridge/ebtables.h | 4 ---- net/bridge/netfilter/ebtable_broute.c | 8 -------- net/bridge/netfilter/ebtable_filter.c | 8 -------- net/bridge/netfilter/ebtable_nat.c | 8 -------- net/bridge/netfilter/ebtables.c | 8 +------- 5 files changed, 1 insertion(+), 35 deletions(-) diff --git a/include/linux/netfilter_bridge/ebtables.h b/include/linux/netf= ilter_bridge/ebtables.h index db472c9cd8e9d..f0d846df3a424 100644 --- a/include/linux/netfilter_bridge/ebtables.h +++ b/include/linux/netfilter_bridge/ebtables.h @@ -94,10 +94,6 @@ struct ebt_table { struct ebt_replace_kernel *table; unsigned int valid_hooks; rwlock_t lock; - /* e.g. could be the table explicitly only allows certain - * matches, targets, ... 0 =3D=3D let it in */ - int (*check)(const struct ebt_table_info *info, - unsigned int valid_hooks); /* the data used by the kernel */ struct ebt_table_info *private; struct module *me; diff --git a/net/bridge/netfilter/ebtable_broute.c b/net/bridge/netfilter/e= btable_broute.c index 32bc2821027f3..57f91efce0f73 100644 --- a/net/bridge/netfilter/ebtable_broute.c +++ b/net/bridge/netfilter/ebtable_broute.c @@ -36,18 +36,10 @@ static struct ebt_replace_kernel initial_table =3D { .entries =3D (char *)&initial_chain, }; =20 -static int check(const struct ebt_table_info *info, unsigned int valid_hoo= ks) -{ - if (valid_hooks & ~(1 << NF_BR_BROUTING)) - return -EINVAL; - return 0; -} - static const struct ebt_table broute_table =3D { .name =3D "broute", .table =3D &initial_table, .valid_hooks =3D 1 << NF_BR_BROUTING, - .check =3D check, .me =3D THIS_MODULE, }; =20 diff --git a/net/bridge/netfilter/ebtable_filter.c b/net/bridge/netfilter/e= btable_filter.c index bcf982e12f16b..7f2e620f4978f 100644 --- a/net/bridge/netfilter/ebtable_filter.c +++ b/net/bridge/netfilter/ebtable_filter.c @@ -43,18 +43,10 @@ static struct ebt_replace_kernel initial_table =3D { .entries =3D (char *)initial_chains, }; =20 -static int check(const struct ebt_table_info *info, unsigned int valid_hoo= ks) -{ - if (valid_hooks & ~FILTER_VALID_HOOKS) - return -EINVAL; - return 0; -} - static const struct ebt_table frame_filter =3D { .name =3D "filter", .table =3D &initial_table, .valid_hooks =3D FILTER_VALID_HOOKS, - .check =3D check, .me =3D THIS_MODULE, }; =20 diff --git a/net/bridge/netfilter/ebtable_nat.c b/net/bridge/netfilter/ebta= ble_nat.c index 0d092773f8161..1743a105485c4 100644 --- a/net/bridge/netfilter/ebtable_nat.c +++ b/net/bridge/netfilter/ebtable_nat.c @@ -43,18 +43,10 @@ static struct ebt_replace_kernel initial_table =3D { .entries =3D (char *)initial_chains, }; =20 -static int check(const struct ebt_table_info *info, unsigned int valid_hoo= ks) -{ - if (valid_hooks & ~NAT_VALID_HOOKS) - return -EINVAL; - return 0; -} - static const struct ebt_table frame_nat =3D { .name =3D "nat", .table =3D &initial_table, .valid_hooks =3D NAT_VALID_HOOKS, - .check =3D check, .me =3D THIS_MODULE, }; =20 diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtable= s.c index d9375c52f50e6..ddb988c339c17 100644 --- a/net/bridge/netfilter/ebtables.c +++ b/net/bridge/netfilter/ebtables.c @@ -999,8 +999,7 @@ static int do_replace_finish(struct net *net, struct eb= t_replace *repl, goto free_iterate; } =20 - /* the table doesn't like it */ - if (t->check && (ret =3D t->check(newinfo, repl->valid_hooks))) + if (repl->valid_hooks !=3D t->valid_hooks) goto free_unlock; =20 if (repl->num_counters && repl->num_counters !=3D t->private->nentries) { @@ -1193,11 +1192,6 @@ int ebt_register_table(struct net *net, const struct= ebt_table *input_table, if (ret !=3D 0) goto free_chainstack; =20 - if (table->check && table->check(newinfo, table->valid_hooks)) { - ret =3D -EINVAL; - goto free_chainstack; - } - table->private =3D newinfo; rwlock_init(&table->lock); mutex_lock(&ebt_mutex); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E844C6FA82 for ; Fri, 2 Sep 2022 12:42:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237180AbiIBMmH (ORCPT ); Fri, 2 Sep 2022 08:42:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237173AbiIBMkc (ORCPT ); Fri, 2 Sep 2022 08:40:32 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68ADAE68C6; Fri, 2 Sep 2022 05:31:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 07CA5B82A9B; Fri, 2 Sep 2022 12:29:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B10AC433D6; Fri, 2 Sep 2022 12:29:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121779; bh=ra/Uw8WmSXQfY+fMpLEKrLdp7DcB7dUfee/hSdOc/sc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rFYiwa/gVl1HeFpFDOvuPKbDs+dM9Ws1JF1lHhm/23QHyzPJP5byls2I2zALviarR 200irtTrWrJQArRcHwndksDibgAjv6Vl7W4d9Wyr9RZKmLyi6zgj9DDIiq+sTfnMf5 cnCSy22fi50bRO5QlkqpOYsIQv3U/mYdCkZL5pZQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vikas Gupta , Michael Chan , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 21/77] bnxt_en: fix NQ resource accounting during vf creation on 57500 chips Date: Fri, 2 Sep 2022 14:18:30 +0200 Message-Id: <20220902121404.354208596@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vikas Gupta [ Upstream commit 09a89cc59ad67794a11e1d3dd13c5b3172adcc51 ] There are 2 issues: 1. We should decrement hw_resc->max_nqs instead of hw_resc->max_irqs with the number of NQs assigned to the VFs. The IRQs are fixed on each function and cannot be re-assigned. Only the NQs are being assigned to the VFs. 2. vf_msix is the total number of NQs to be assigned to the VFs. So we should decrement vf_msix from hw_resc->max_nqs. Fixes: b16b68918674 ("bnxt_en: Add SR-IOV support for 57500 chips.") Signed-off-by: Vikas Gupta Signed-off-by: Michael Chan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/= ethernet/broadcom/bnxt/bnxt_sriov.c index 452be9749827a..3434ad6824a05 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c @@ -597,7 +597,7 @@ static int bnxt_hwrm_func_vf_resc_cfg(struct bnxt *bp, = int num_vfs, bool reset) hw_resc->max_stat_ctxs -=3D le16_to_cpu(req.min_stat_ctx) * n; hw_resc->max_vnics -=3D le16_to_cpu(req.min_vnics) * n; if (bp->flags & BNXT_FLAG_CHIP_P5) - hw_resc->max_irqs -=3D vf_msix * n; + hw_resc->max_nqs -=3D vf_msix; =20 rc =3D pf->active_vfs; } --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 418A3ECAAD5 for ; Fri, 2 Sep 2022 12:37:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236934AbiIBMhd (ORCPT ); Fri, 2 Sep 2022 08:37:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237062AbiIBMhA (ORCPT ); Fri, 2 Sep 2022 08:37:00 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F49FE5886; Fri, 2 Sep 2022 05:29:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DFC8AB829B6; Fri, 2 Sep 2022 12:27:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EC89C433D6; Fri, 2 Sep 2022 12:27:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121677; bh=X1ADLifz4xkdtxx8IQXklXNBOLgY87zEzsW+DZA+a/k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ds1sv1rqgF5yX1Y9PqtaBJbMNSEBhir7SVZqhkL87bPjdQRd514x2vkUva/ud8zQq ZDOqjNZXU+fus/KUYj6ZhwpP9nUPNPD4ReQ06OWX0U5rBxcF+7tfvov7JYfETcKtW+ EnURGxPTyl/Ln/5FKhRUmp0gVn/ZCJet7mxMmTvk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.4 22/77] netfilter: nft_payload: report ERANGE for too long offset and length Date: Fri, 2 Sep 2022 14:18:31 +0200 Message-Id: <20220902121404.392669371@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pablo Neira Ayuso [ Upstream commit 94254f990c07e9ddf1634e0b727fab821c3b5bf9 ] Instead of offset and length are truncation to u8, report ERANGE. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/nft_payload.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nft_payload.c b/net/netfilter/nft_payload.c index cf0512fc648e7..7520ec17cabb7 100644 --- a/net/netfilter/nft_payload.c +++ b/net/netfilter/nft_payload.c @@ -624,6 +624,7 @@ nft_payload_select_ops(const struct nft_ctx *ctx, { enum nft_payload_bases base; unsigned int offset, len; + int err; =20 if (tb[NFTA_PAYLOAD_BASE] =3D=3D NULL || tb[NFTA_PAYLOAD_OFFSET] =3D=3D NULL || @@ -649,8 +650,13 @@ nft_payload_select_ops(const struct nft_ctx *ctx, if (tb[NFTA_PAYLOAD_DREG] =3D=3D NULL) return ERR_PTR(-EINVAL); =20 - offset =3D ntohl(nla_get_be32(tb[NFTA_PAYLOAD_OFFSET])); - len =3D ntohl(nla_get_be32(tb[NFTA_PAYLOAD_LEN])); + err =3D nft_parse_u32_check(tb[NFTA_PAYLOAD_OFFSET], U8_MAX, &offset); + if (err < 0) + return ERR_PTR(err); + + err =3D nft_parse_u32_check(tb[NFTA_PAYLOAD_LEN], U8_MAX, &len); + if (err < 0) + return ERR_PTR(err); =20 if (len <=3D 4 && is_power_of_2(len) && IS_ALIGNED(offset, len) && base !=3D NFT_PAYLOAD_LL_HEADER) --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B23C7C54EE9 for ; Fri, 2 Sep 2022 12:36:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236840AbiIBMgD (ORCPT ); Fri, 2 Sep 2022 08:36:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236759AbiIBMeO (ORCPT ); Fri, 2 Sep 2022 08:34:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1814BD9EBC; Fri, 2 Sep 2022 05:28:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 12CDE6218D; Fri, 2 Sep 2022 12:28:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2216BC433C1; Fri, 2 Sep 2022 12:28:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121711; bh=02dvi00mHdGtZ2LxDeSycdfEgjyDOflIKnkQinHHrZg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dR4Rmkpb08hi1RGDUD+h74aG4YJnY18mAvMxq9DdDZOHvIVq3ZILSG310NSWGu0uR BdBHthNR3R+b9Iex724MztBnxQHcXzYIe+kTPLza2LKJBrHDXBaSeYJPysd56UGsuo eJijuq8jCq/rWA6HG73pHQSEcbjxkA2++Jiq3hNg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.4 23/77] netfilter: nft_payload: do not truncate csum_offset and csum_type Date: Fri, 2 Sep 2022 14:18:32 +0200 Message-Id: <20220902121404.420648109@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pablo Neira Ayuso [ Upstream commit 7044ab281febae9e2fa9b0b247693d6026166293 ] Instead report ERANGE if csum_offset is too long, and EOPNOTSUPP if type is not support. Fixes: 7ec3f7b47b8d ("netfilter: nft_payload: add packet mangling support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/nft_payload.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/net/netfilter/nft_payload.c b/net/netfilter/nft_payload.c index 7520ec17cabb7..6ed6ccef5e1ad 100644 --- a/net/netfilter/nft_payload.c +++ b/net/netfilter/nft_payload.c @@ -558,6 +558,8 @@ static int nft_payload_set_init(const struct nft_ctx *c= tx, const struct nlattr * const tb[]) { struct nft_payload_set *priv =3D nft_expr_priv(expr); + u32 csum_offset, csum_type =3D NFT_PAYLOAD_CSUM_NONE; + int err; =20 priv->base =3D ntohl(nla_get_be32(tb[NFTA_PAYLOAD_BASE])); priv->offset =3D ntohl(nla_get_be32(tb[NFTA_PAYLOAD_OFFSET])); @@ -565,11 +567,15 @@ static int nft_payload_set_init(const struct nft_ctx = *ctx, priv->sreg =3D nft_parse_register(tb[NFTA_PAYLOAD_SREG]); =20 if (tb[NFTA_PAYLOAD_CSUM_TYPE]) - priv->csum_type =3D - ntohl(nla_get_be32(tb[NFTA_PAYLOAD_CSUM_TYPE])); - if (tb[NFTA_PAYLOAD_CSUM_OFFSET]) - priv->csum_offset =3D - ntohl(nla_get_be32(tb[NFTA_PAYLOAD_CSUM_OFFSET])); + csum_type =3D ntohl(nla_get_be32(tb[NFTA_PAYLOAD_CSUM_TYPE])); + if (tb[NFTA_PAYLOAD_CSUM_OFFSET]) { + err =3D nft_parse_u32_check(tb[NFTA_PAYLOAD_CSUM_OFFSET], U8_MAX, + &csum_offset); + if (err < 0) + return err; + + priv->csum_offset =3D csum_offset; + } if (tb[NFTA_PAYLOAD_CSUM_FLAGS]) { u32 flags; =20 @@ -580,13 +586,14 @@ static int nft_payload_set_init(const struct nft_ctx = *ctx, priv->csum_flags =3D flags; } =20 - switch (priv->csum_type) { + switch (csum_type) { case NFT_PAYLOAD_CSUM_NONE: case NFT_PAYLOAD_CSUM_INET: break; default: return -EOPNOTSUPP; } + priv->csum_type =3D csum_type; =20 return nft_validate_register_load(priv->sreg, priv->len); } --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 361A6C38145 for ; Fri, 2 Sep 2022 12:41:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237275AbiIBMlH (ORCPT ); Fri, 2 Sep 2022 08:41:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237226AbiIBMiu (ORCPT ); Fri, 2 Sep 2022 08:38:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68818220EC; Fri, 2 Sep 2022 05:30:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5D8706217A; Fri, 2 Sep 2022 12:29:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 507E3C433D7; Fri, 2 Sep 2022 12:29:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121744; bh=rXtFO/uek9ssxy6G6iRJq92+PbXKnX93fIwM3lb08pg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=blAPWDeYO36cr+un9hoZVSWWo72P/kdNzSB2wc5dEHNgC1JvBbG+V+6ne6YjqmtP4 5l+0EtNghqN6s9u7MgbQ64CRx2EJhLVyKsJGKoAiiT9pPDb0Fz/p+4QStkbY1O00zU qXDMtmU0k5PtNvM4WkMgVoOHQmSAtYGLjMUpwcX0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.4 24/77] netfilter: nft_osf: restrict osf to ipv4, ipv6 and inet families Date: Fri, 2 Sep 2022 14:18:33 +0200 Message-Id: <20220902121404.459178343@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pablo Neira Ayuso [ Upstream commit 5f3b7aae14a706d0d7da9f9e39def52ff5fc3d39 ] As it was originally intended, restrict extension to supported families. Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprin= t module in nft_osf") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/nft_osf.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nft_osf.c b/net/netfilter/nft_osf.c index 4911f8eb394ff..d966a3aff1d33 100644 --- a/net/netfilter/nft_osf.c +++ b/net/netfilter/nft_osf.c @@ -115,9 +115,21 @@ static int nft_osf_validate(const struct nft_ctx *ctx, const struct nft_expr *expr, const struct nft_data **data) { - return nft_chain_validate_hooks(ctx->chain, (1 << NF_INET_LOCAL_IN) | - (1 << NF_INET_PRE_ROUTING) | - (1 << NF_INET_FORWARD)); + unsigned int hooks; + + switch (ctx->family) { + case NFPROTO_IPV4: + case NFPROTO_IPV6: + case NFPROTO_INET: + hooks =3D (1 << NF_INET_LOCAL_IN) | + (1 << NF_INET_PRE_ROUTING) | + (1 << NF_INET_FORWARD); + break; + default: + return -EOPNOTSUPP; + } + + return nft_chain_validate_hooks(ctx->chain, hooks); } =20 static struct nft_expr_type nft_osf_type; --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1968C54EE9 for ; Fri, 2 Sep 2022 12:42:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237319AbiIBMmn (ORCPT ); Fri, 2 Sep 2022 08:42:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237031AbiIBMls (ORCPT ); Fri, 2 Sep 2022 08:41:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18AD3E869C; Fri, 2 Sep 2022 05:31:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3BCFF620B6; Fri, 2 Sep 2022 12:29:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30DBEC433C1; Fri, 2 Sep 2022 12:29:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121760; bh=P+jaSS/ABgscCL7bOLfDbwgtwfZD4mI/GtjODIiIDI0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yanoOMFn4dFi/Cxec7xHng3g9FSG8EFKrICf2gHm7NwGcyBmctgsFGOoyIu4A6ha+ 3yfQt87+UrIsAMmlkoBD2RcrLBmbNMcu7oQRvix+EUd1W30YwJnTe1Y8ymZf6ekxQ2 Y0ZNrWB3CtkLVO/tN5WgMU6EW9AMN9oQIdV7xclA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.4 25/77] netfilter: nft_tunnel: restrict it to netdev family Date: Fri, 2 Sep 2022 14:18:34 +0200 Message-Id: <20220902121404.488271284@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pablo Neira Ayuso [ Upstream commit 01e4092d53bc4fe122a6e4b6d664adbd57528ca3 ] Only allow to use this expression from NFPROTO_NETDEV family. Fixes: af308b94a2a4 ("netfilter: nf_tables: add tunnel support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/nft_tunnel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/netfilter/nft_tunnel.c b/net/netfilter/nft_tunnel.c index 1effd4878619f..4e850c81ad8d8 100644 --- a/net/netfilter/nft_tunnel.c +++ b/net/netfilter/nft_tunnel.c @@ -134,6 +134,7 @@ static const struct nft_expr_ops nft_tunnel_get_ops =3D= { =20 static struct nft_expr_type nft_tunnel_type __read_mostly =3D { .name =3D "tunnel", + .family =3D NFPROTO_NETDEV, .ops =3D &nft_tunnel_get_ops, .policy =3D nft_tunnel_policy, .maxattr =3D NFTA_TUNNEL_MAX, --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91F9BECAAD5 for ; Fri, 2 Sep 2022 14:45:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235644AbiIBOp0 (ORCPT ); Fri, 2 Sep 2022 10:45:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236684AbiIBOot (ORCPT ); Fri, 2 Sep 2022 10:44:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC83A1208EC; Fri, 2 Sep 2022 07:05:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 51065B82A98; Fri, 2 Sep 2022 12:29:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B7BDC43141; Fri, 2 Sep 2022 12:29:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121764; bh=/EW6F/J4y5L/YIuTw42ImToh41zLmkwyEW0r/Ibql/Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lv01Q8nylIFpEDkoYq3p9o7BcSLOg5XwxsjK412suAdk6nbZOFKjAHz5kocOnYdp9 GeC0Db/JBEokfvELamIu/UzF/ylgYC/5gZa6ASX6ABSILKDT5ITvkArlo6RcLk/k2B WxyBuYbc7Z3QeLsnDCnmoSgo76Qb7TqOkArFLykM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 26/77] net: Fix data-races around weight_p and dev_weight_[rt]x_bias. Date: Fri, 2 Sep 2022 14:18:35 +0200 Message-Id: <20220902121404.515887262@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit bf955b5ab8f6f7b0632cdef8e36b14e4f6e77829 ] While reading weight_p, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Also, dev_[rt]x_weight can be read/written at the same time. So, we need to use READ_ONCE() and WRITE_ONCE() for its access. Moreover, to use the same weight_p while changing dev_[rt]x_weight, we add a mutex in proc_do_dev_weight(). Fixes: 3d48b53fb2ae ("net: dev_weight: TX/RX orthogonality") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/dev.c | 2 +- net/core/sysctl_net_core.c | 15 +++++++++------ net/sched/sch_generic.c | 2 +- 3 files changed, 11 insertions(+), 8 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index a03036456221b..517fb03a0bb89 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -5892,7 +5892,7 @@ static int process_backlog(struct napi_struct *napi, = int quota) net_rps_action_and_irq_enable(sd); } =20 - napi->weight =3D dev_rx_weight; + napi->weight =3D READ_ONCE(dev_rx_weight); while (again) { struct sk_buff *skb; =20 diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c index 48041f50ecfb4..586598887095d 100644 --- a/net/core/sysctl_net_core.c +++ b/net/core/sysctl_net_core.c @@ -238,14 +238,17 @@ static int set_default_qdisc(struct ctl_table *table,= int write, static int proc_do_dev_weight(struct ctl_table *table, int write, void __user *buffer, size_t *lenp, loff_t *ppos) { - int ret; + static DEFINE_MUTEX(dev_weight_mutex); + int ret, weight; =20 + mutex_lock(&dev_weight_mutex); ret =3D proc_dointvec(table, write, buffer, lenp, ppos); - if (ret !=3D 0) - return ret; - - dev_rx_weight =3D weight_p * dev_weight_rx_bias; - dev_tx_weight =3D weight_p * dev_weight_tx_bias; + if (!ret && write) { + weight =3D READ_ONCE(weight_p); + WRITE_ONCE(dev_rx_weight, weight * dev_weight_rx_bias); + WRITE_ONCE(dev_tx_weight, weight * dev_weight_tx_bias); + } + mutex_unlock(&dev_weight_mutex); =20 return ret; } diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index ae5847de94c88..81fcf6c5bde96 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -403,7 +403,7 @@ static inline bool qdisc_restart(struct Qdisc *q, int *= packets) =20 void __qdisc_run(struct Qdisc *q) { - int quota =3D dev_tx_weight; + int quota =3D READ_ONCE(dev_tx_weight); int packets; =20 while (qdisc_restart(q, &packets)) { --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78F76C38145 for ; Fri, 2 Sep 2022 12:40:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236420AbiIBMk0 (ORCPT ); Fri, 2 Sep 2022 08:40:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236274AbiIBMi1 (ORCPT ); Fri, 2 Sep 2022 08:38:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C2C713DC1; Fri, 2 Sep 2022 05:30:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DC43B62175; Fri, 2 Sep 2022 12:29:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0A0BC433D6; Fri, 2 Sep 2022 12:29:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121767; bh=9NWEiSryDCA9PIKWIcExTflup0XRLRkcGw2V8ePGtIs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=guereO6JVavvwR5KAE+ln0vN0JQJfg9TD05HSONDZvNjPAlvm3JZOkNQwVMZ9ElkY BI1p4bcMOz1QUB1KC+FmPVdn2T78cg1UTgpAkRK0e6wlD6Ihg8j4OLLPsm3of+iKqT kFlB330EENnoDTFhvDOBcQzv9TG9YOeLzIMjImi0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 27/77] net: Fix data-races around netdev_tstamp_prequeue. Date: Fri, 2 Sep 2022 14:18:36 +0200 Message-Id: <20220902121404.544964153@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 61adf447e38664447526698872e21c04623afb8e ] While reading netdev_tstamp_prequeue, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. Fixes: 3b098e2d7c69 ("net: Consistent skb timestamping") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/dev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 517fb03a0bb89..99b0025864984 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4411,7 +4411,7 @@ static int netif_rx_internal(struct sk_buff *skb) { int ret; =20 - net_timestamp_check(netdev_tstamp_prequeue, skb); + net_timestamp_check(READ_ONCE(netdev_tstamp_prequeue), skb); =20 trace_netif_rx(skb); =20 @@ -4753,7 +4753,7 @@ static int __netif_receive_skb_core(struct sk_buff **= pskb, bool pfmemalloc, int ret =3D NET_RX_DROP; __be16 type; =20 - net_timestamp_check(!netdev_tstamp_prequeue, skb); + net_timestamp_check(!READ_ONCE(netdev_tstamp_prequeue), skb); =20 trace_netif_receive_skb(skb); =20 @@ -5135,7 +5135,7 @@ static int netif_receive_skb_internal(struct sk_buff = *skb) { int ret; =20 - net_timestamp_check(netdev_tstamp_prequeue, skb); + net_timestamp_check(READ_ONCE(netdev_tstamp_prequeue), skb); =20 if (skb_defer_rx_timestamp(skb)) return NET_RX_SUCCESS; @@ -5165,7 +5165,7 @@ static void netif_receive_skb_list_internal(struct li= st_head *head) =20 INIT_LIST_HEAD(&sublist); list_for_each_entry_safe(skb, next, head, list) { - net_timestamp_check(netdev_tstamp_prequeue, skb); + net_timestamp_check(READ_ONCE(netdev_tstamp_prequeue), skb); skb_list_del_init(skb); if (!skb_defer_rx_timestamp(skb)) list_add_tail(&skb->list, &sublist); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A95CECAAD5 for ; Fri, 2 Sep 2022 12:40:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237215AbiIBMkp (ORCPT ); Fri, 2 Sep 2022 08:40:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237177AbiIBMim (ORCPT ); Fri, 2 Sep 2022 08:38:42 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A35F32EE2; Fri, 2 Sep 2022 05:30:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ED79862192; Fri, 2 Sep 2022 12:29:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA119C433C1; Fri, 2 Sep 2022 12:29:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121770; bh=FufMUVUaQh+PDh29tlw9bNgetLwgT2UPVsGlg+Vo9Jk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qK8r1vH/U8TlQCH0Ar9MeVidJCO/LVGAkqh1n+wBg1Cz1JOwhqNv0htF9cb5EBPG7 DjJYFEOmXfmjBUTbLiXR73K6hKiBwS13RLR+/ZrktTnMl9JesbNcvznFs7E3Tag0gu 6+caHst0t3DEVuTS5pSnzO9lJE4VmdohPi6Je4uw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 28/77] ratelimit: Fix data-races in ___ratelimit(). Date: Fri, 2 Sep 2022 14:18:37 +0200 Message-Id: <20220902121404.582894486@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 6bae8ceb90ba76cdba39496db936164fa672b9be ] While reading rs->interval and rs->burst, they can be changed concurrently via sysctl (e.g. net_ratelimit_state). Thus, we need to add READ_ONCE() to their readers. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- lib/ratelimit.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/lib/ratelimit.c b/lib/ratelimit.c index e01a93f46f833..ce945c17980b9 100644 --- a/lib/ratelimit.c +++ b/lib/ratelimit.c @@ -26,10 +26,16 @@ */ int ___ratelimit(struct ratelimit_state *rs, const char *func) { + /* Paired with WRITE_ONCE() in .proc_handler(). + * Changing two values seperately could be inconsistent + * and some message could be lost. (See: net_ratelimit_state). + */ + int interval =3D READ_ONCE(rs->interval); + int burst =3D READ_ONCE(rs->burst); unsigned long flags; int ret; =20 - if (!rs->interval) + if (!interval) return 1; =20 /* @@ -44,7 +50,7 @@ int ___ratelimit(struct ratelimit_state *rs, const char *= func) if (!rs->begin) rs->begin =3D jiffies; =20 - if (time_is_before_jiffies(rs->begin + rs->interval)) { + if (time_is_before_jiffies(rs->begin + interval)) { if (rs->missed) { if (!(rs->flags & RATELIMIT_MSG_ON_RELEASE)) { printk_deferred(KERN_WARNING @@ -56,7 +62,7 @@ int ___ratelimit(struct ratelimit_state *rs, const char *= func) rs->begin =3D jiffies; rs->printed =3D 0; } - if (rs->burst && rs->burst > rs->printed) { + if (burst && burst > rs->printed) { rs->printed++; ret =3D 1; } else { --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B094ECAAD5 for ; Fri, 2 Sep 2022 13:12:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238747AbiIBNMG (ORCPT ); Fri, 2 Sep 2022 09:12:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236072AbiIBNLn (ORCPT ); Fri, 2 Sep 2022 09:11:43 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92C12120F9E; Fri, 2 Sep 2022 05:48:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E3BC362191; Fri, 2 Sep 2022 12:29:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00055C433C1; Fri, 2 Sep 2022 12:29:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121773; bh=VAG5GdEg7FqIlZauGvChtJWSA4hc+7rDVvVB3fLDugo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HltL6vOalS9VMcX7OmS7ywEaDHpDSIBMnw0lfAJEEvBYReNuQVsMIztVCPnlm5KJ6 VRVkr67p7lsR6O2xGMKbafw6nMR/LLpuJ3vvjUyLz31ioZEyzylbPmAhbOfxscjRre rjn0JaC6ZMkeyn3fK/KNAAbUfsZ+uAXcHWoldQg4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 29/77] net: Fix a data-race around sysctl_tstamp_allow_data. Date: Fri, 2 Sep 2022 14:18:38 +0200 Message-Id: <20220902121404.611613476@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit d2154b0afa73c0159b2856f875c6b4fe7cf6a95e ] While reading sysctl_tstamp_allow_data, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/skbuff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 5bdb3cd20d619..c9fe2c0b8cae3 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4564,7 +4564,7 @@ static bool skb_may_tx_timestamp(struct sock *sk, boo= l tsonly) { bool ret; =20 - if (likely(sysctl_tstamp_allow_data || tsonly)) + if (likely(READ_ONCE(sysctl_tstamp_allow_data) || tsonly)) return true; =20 read_lock_bh(&sk->sk_callback_lock); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4EB2C54EE9 for ; Fri, 2 Sep 2022 13:52:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233539AbiIBNw0 (ORCPT ); Fri, 2 Sep 2022 09:52:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236787AbiIBNvz (ORCPT ); Fri, 2 Sep 2022 09:51:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA6BAC12E1; Fri, 2 Sep 2022 06:26:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A55F9B829B6; Fri, 2 Sep 2022 12:29:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDCC9C433D6; Fri, 2 Sep 2022 12:29:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121776; bh=gdQ/KPd8CRekFKLKlOAVuXZbutNkpThhu5T6EwGvljg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BeDybXvKbhG4/IKgYCw0SxZp925A7hDJOvLGaR1tDIsukLZNkK7PVeAaWpv3424cv Nb3nfI0ZLPhZoXp1dlLu/MfTv/Xcq6fFf/l8Iyaya3AqjMJ1nhnrQP+lFgGfBWyTWh hgKcw2J+22BSynalx88FhpzeefW2HixjKyfPgyIw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 30/77] net: Fix a data-race around sysctl_net_busy_poll. Date: Fri, 2 Sep 2022 14:18:39 +0200 Message-Id: <20220902121404.640131055@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit c42b7cddea47503411bfb5f2f93a4154aaffa2d9 ] While reading sysctl_net_busy_poll, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Fixes: 060212928670 ("net: add low latency socket poll") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/net/busy_poll.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h index 9899b9af7f22f..16258c0c7319e 100644 --- a/include/net/busy_poll.h +++ b/include/net/busy_poll.h @@ -31,7 +31,7 @@ extern unsigned int sysctl_net_busy_poll __read_mostly; =20 static inline bool net_busy_loop_on(void) { - return sysctl_net_busy_poll; + return READ_ONCE(sysctl_net_busy_poll); } =20 static inline bool sk_can_busy_loop(const struct sock *sk) --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 441FFC38145 for ; Fri, 2 Sep 2022 12:34:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236886AbiIBMev (ORCPT ); Fri, 2 Sep 2022 08:34:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236921AbiIBMdo (ORCPT ); Fri, 2 Sep 2022 08:33:44 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E848FE3420; Fri, 2 Sep 2022 05:28:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 11954B82AA5; Fri, 2 Sep 2022 12:28:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50655C433C1; Fri, 2 Sep 2022 12:28:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121680; bh=MUaU73BWKwBTtGsQu2MymRJAHGJQxN5FzuhKUXGRAns=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k5qEtf2kIx9jDLjEUZGzDYVP5pvLxBoVglI2E8UpxYn4Spvu6f5F1B7vnpo0Mz7ia CrOUjtJeerH4XM/Dv5N5MNUKGIpuhzGmapEaTE9vdLg6DE57F0b82xm+zcpfIFWj+c ssn122FXg9//cTv0n8yi0NrCeRmsIlx4CSEQxV0s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 31/77] net: Fix a data-race around sysctl_net_busy_read. Date: Fri, 2 Sep 2022 14:18:40 +0200 Message-Id: <20220902121404.678101927@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit e59ef36f0795696ab229569c153936bfd068d21c ] While reading sysctl_net_busy_read, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Fixes: 2d48d67fa8cd ("net: poll/select low latency socket support") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/sock.c b/net/core/sock.c index c84f68bff7f58..a2b12a5cf42bc 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -2946,7 +2946,7 @@ void sock_init_data(struct socket *sock, struct sock = *sk) =20 #ifdef CONFIG_NET_RX_BUSY_POLL sk->sk_napi_id =3D 0; - sk->sk_ll_usec =3D sysctl_net_busy_read; + sk->sk_ll_usec =3D READ_ONCE(sysctl_net_busy_read); #endif =20 sk->sk_max_pacing_rate =3D ~0UL; --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17351C54EE9 for ; Fri, 2 Sep 2022 12:35:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236909AbiIBMfK (ORCPT ); Fri, 2 Sep 2022 08:35:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236936AbiIBMdq (ORCPT ); Fri, 2 Sep 2022 08:33:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE8A3E3438; Fri, 2 Sep 2022 05:28:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 158CFB82AA1; Fri, 2 Sep 2022 12:28:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DDB7C433C1; Fri, 2 Sep 2022 12:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121683; bh=bjlUEf+Dr1gI09ygxVRd1FmBAP970UMclWHUNlzSSjI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rE2jXoE3vAgqf4mqK9lGxlFKjuee/htTOmDdygFkhVCH0sGNRXpfDU9i/t3aTN9Xk BlaejM7Th1ssUN7/aboVh1W0OeT2Yg39G4LydONHzqC0NxLs0ZHcgWaz178q8rox4J rWkYLSet+cp+XypbUEHF16lwa1Nz2w1GYAGbU220= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 32/77] net: Fix a data-race around netdev_budget. Date: Fri, 2 Sep 2022 14:18:41 +0200 Message-Id: <20220902121404.710820787@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 2e0c42374ee32e72948559d2ae2f7ba3dc6b977c ] While reading netdev_budget, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Fixes: 51b0bdedb8e7 ("[NET]: Separate two usages of netdev_max_backlog.") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 99b0025864984..7c19e672dde84 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6394,7 +6394,7 @@ static __latent_entropy void net_rx_action(struct sof= tirq_action *h) struct softnet_data *sd =3D this_cpu_ptr(&softnet_data); unsigned long time_limit =3D jiffies + usecs_to_jiffies(netdev_budget_usecs); - int budget =3D netdev_budget; + int budget =3D READ_ONCE(netdev_budget); LIST_HEAD(list); LIST_HEAD(repoll); =20 --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 887E2C38145 for ; Fri, 2 Sep 2022 12:35:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236927AbiIBMfW (ORCPT ); Fri, 2 Sep 2022 08:35:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236957AbiIBMdy (ORCPT ); Fri, 2 Sep 2022 08:33:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9DBFE395D; Fri, 2 Sep 2022 05:28:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8772062160; Fri, 2 Sep 2022 12:28:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6473EC433D7; Fri, 2 Sep 2022 12:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121687; bh=RiliGPSZwKdFTnul30LcNjErRFxYycneIXzWkkJauHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fGTKDkDe/2a07v4r8vFl3Z2ZKWGUiRi0BX2EcSM+53H5DwMNqGrA5v6UojIhvmhIr tXiBhrm795DF7wih5wTOb5KvBALQ5pbd2tSFZl2UygaIx66ML9EWHL2RRX9p7qIBqU v7fxB+1oOvE24wr5GXof7jSod1/z6mpdOqHRMAeM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 33/77] net: Fix a data-race around netdev_budget_usecs. Date: Fri, 2 Sep 2022 14:18:42 +0200 Message-Id: <20220902121404.739072097@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit fa45d484c52c73f79db2c23b0cdfc6c6455093ad ] While reading netdev_budget_usecs, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Fixes: 7acf8a1e8a28 ("Replace 2 jiffies with sysctl netdev_budget_usecs to = enable softirq tuning") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 7c19e672dde84..25b4fe06fbb4e 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6393,7 +6393,7 @@ static __latent_entropy void net_rx_action(struct sof= tirq_action *h) { struct softnet_data *sd =3D this_cpu_ptr(&softnet_data); unsigned long time_limit =3D jiffies + - usecs_to_jiffies(netdev_budget_usecs); + usecs_to_jiffies(READ_ONCE(netdev_budget_usecs)); int budget =3D READ_ONCE(netdev_budget); LIST_HEAD(list); LIST_HEAD(repoll); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 179DDC38145 for ; Fri, 2 Sep 2022 12:36:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236894AbiIBMgI (ORCPT ); Fri, 2 Sep 2022 08:36:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236761AbiIBMeO (ORCPT ); Fri, 2 Sep 2022 08:34:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF9F6E39A5; Fri, 2 Sep 2022 05:28:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7644862180; Fri, 2 Sep 2022 12:28:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75B49C433D6; Fri, 2 Sep 2022 12:28:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121689; bh=bHz25WY47fF99xCkNTtdyucgM4/0bYVDXbB1OFIFlLA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EwKObwL7PUvgGbf9YX+KI6IQmfPT1UOP91LRS7v6vckWxiWfhazxdw8jeVEgcYkSf SUKU7XVdpgieoQR5LRvWFT6oflDRMKd0ggOjmOdoewJcAIEBRRWwgkaEYAZRyvR0lA xyRUyUy+/cYgBQ9oUZ9nyrwmOpI9tWKvAJ2ohLBY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 34/77] net: Fix a data-race around sysctl_somaxconn. Date: Fri, 2 Sep 2022 14:18:43 +0200 Message-Id: <20220902121404.772034607@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 3c9ba81d72047f2e81bb535d42856517b613aba7 ] While reading sysctl_somaxconn, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/socket.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/socket.c b/net/socket.c index 94358566c9d10..02feaf5bd84a3 100644 --- a/net/socket.c +++ b/net/socket.c @@ -1661,7 +1661,7 @@ int __sys_listen(int fd, int backlog) =20 sock =3D sockfd_lookup_light(fd, &err, &fput_needed); if (sock) { - somaxconn =3D sock_net(sock->sk)->core.sysctl_somaxconn; + somaxconn =3D READ_ONCE(sock_net(sock->sk)->core.sysctl_somaxconn); if ((unsigned int)backlog > somaxconn) backlog =3D somaxconn; =20 --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D91A4ECAAD5 for ; Fri, 2 Sep 2022 12:52:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237783AbiIBMwb (ORCPT ); Fri, 2 Sep 2022 08:52:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237839AbiIBMvW (ORCPT ); Fri, 2 Sep 2022 08:51:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD14EF8278; Fri, 2 Sep 2022 05:37:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A0A8E6217E; Fri, 2 Sep 2022 12:28:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 965F5C433B5; Fri, 2 Sep 2022 12:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121693; bh=OO1G1jDZihidEmUZy6sJubKsxM9ByjH1uhBM6pruH74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MhhEwzMFk/cxJOg7Q85jsK/oTvMcQPBK6QbX0P1xhpeATjxhdiPKSGE/HlKIjBFrw WIYpffvzKZYrMgQoT5TcbwmHCWPuzh7u9/eCutVfIR7JOlwfDTeeeaHeREcg7wMF8E 2Qy+6QXCFQW8T0C2gjXUZdXRBpFMcVGjLgZhI/Ys= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Steve Payne , Ilya Evenbach , Jacob Keller , Tony Nguyen , Sasha Levin , Gurucharan Subject: [PATCH 5.4 35/77] ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter Date: Fri, 2 Sep 2022 14:18:44 +0200 Message-Id: <20220902121404.810415471@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jacob Keller [ Upstream commit 25d7a5f5a6bb15a2dae0a3f39ea5dda215024726 ] The ixgbe_ptp_start_cyclecounter is intended to be called whenever the cyclecounter parameters need to be changed. Since commit a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices"), this function has cleared the SYSTIME registers and reset the TSAUXC DISABLE_SYSTIME bit. While these need to be cleared during ixgbe_ptp_reset, it is wrong to clear them during ixgbe_ptp_start_cyclecounter. This function may be called during both reset and link status change. When link changes, the SYSTIME counter is still operating normally, but the cyclecounter should be updated to account for the possibly changed parameters. Clearing SYSTIME when link changes causes the timecounter to jump because the cycle counter now reads zero. Extract the SYSTIME initialization out to a new function and call this during ixgbe_ptp_reset. This prevents the timecounter adjustment and avoids an unnecessary reset of the current time. This also restores the original SYSTIME clearing that occurred during ixgbe_ptp_reset before the commit above. Reported-by: Steve Payne Reported-by: Ilya Evenbach Fixes: a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices") Signed-off-by: Jacob Keller Tested-by: Gurucharan (A Contingent worker at Int= el) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 59 +++++++++++++++----- 1 file changed, 46 insertions(+), 13 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/eth= ernet/intel/ixgbe/ixgbe_ptp.c index 0be13a90ff792..d155181b939e4 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c @@ -1211,7 +1211,6 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapte= r *adapter) struct cyclecounter cc; unsigned long flags; u32 incval =3D 0; - u32 tsauxc =3D 0; u32 fuse0 =3D 0; =20 /* For some of the boards below this mask is technically incorrect. @@ -1246,18 +1245,6 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapt= er *adapter) case ixgbe_mac_x550em_a: case ixgbe_mac_X550: cc.read =3D ixgbe_ptp_read_X550; - - /* enable SYSTIME counter */ - IXGBE_WRITE_REG(hw, IXGBE_SYSTIMR, 0); - IXGBE_WRITE_REG(hw, IXGBE_SYSTIML, 0); - IXGBE_WRITE_REG(hw, IXGBE_SYSTIMH, 0); - tsauxc =3D IXGBE_READ_REG(hw, IXGBE_TSAUXC); - IXGBE_WRITE_REG(hw, IXGBE_TSAUXC, - tsauxc & ~IXGBE_TSAUXC_DISABLE_SYSTIME); - IXGBE_WRITE_REG(hw, IXGBE_TSIM, IXGBE_TSIM_TXTS); - IXGBE_WRITE_REG(hw, IXGBE_EIMS, IXGBE_EIMS_TIMESYNC); - - IXGBE_WRITE_FLUSH(hw); break; case ixgbe_mac_X540: cc.read =3D ixgbe_ptp_read_82599; @@ -1289,6 +1276,50 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapt= er *adapter) spin_unlock_irqrestore(&adapter->tmreg_lock, flags); } =20 +/** + * ixgbe_ptp_init_systime - Initialize SYSTIME registers + * @adapter: the ixgbe private board structure + * + * Initialize and start the SYSTIME registers. + */ +static void ixgbe_ptp_init_systime(struct ixgbe_adapter *adapter) +{ + struct ixgbe_hw *hw =3D &adapter->hw; + u32 tsauxc; + + switch (hw->mac.type) { + case ixgbe_mac_X550EM_x: + case ixgbe_mac_x550em_a: + case ixgbe_mac_X550: + tsauxc =3D IXGBE_READ_REG(hw, IXGBE_TSAUXC); + + /* Reset SYSTIME registers to 0 */ + IXGBE_WRITE_REG(hw, IXGBE_SYSTIMR, 0); + IXGBE_WRITE_REG(hw, IXGBE_SYSTIML, 0); + IXGBE_WRITE_REG(hw, IXGBE_SYSTIMH, 0); + + /* Reset interrupt settings */ + IXGBE_WRITE_REG(hw, IXGBE_TSIM, IXGBE_TSIM_TXTS); + IXGBE_WRITE_REG(hw, IXGBE_EIMS, IXGBE_EIMS_TIMESYNC); + + /* Activate the SYSTIME counter */ + IXGBE_WRITE_REG(hw, IXGBE_TSAUXC, + tsauxc & ~IXGBE_TSAUXC_DISABLE_SYSTIME); + break; + case ixgbe_mac_X540: + case ixgbe_mac_82599EB: + /* Reset SYSTIME registers to 0 */ + IXGBE_WRITE_REG(hw, IXGBE_SYSTIML, 0); + IXGBE_WRITE_REG(hw, IXGBE_SYSTIMH, 0); + break; + default: + /* Other devices aren't supported */ + return; + }; + + IXGBE_WRITE_FLUSH(hw); +} + /** * ixgbe_ptp_reset * @adapter: the ixgbe private board structure @@ -1315,6 +1346,8 @@ void ixgbe_ptp_reset(struct ixgbe_adapter *adapter) =20 ixgbe_ptp_start_cyclecounter(adapter); =20 + ixgbe_ptp_init_systime(adapter); + spin_lock_irqsave(&adapter->tmreg_lock, flags); timecounter_init(&adapter->hw_tc, &adapter->hw_cc, ktime_to_ns(ktime_get_real())); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E290ECAAD5 for ; Fri, 2 Sep 2022 12:36:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236961AbiIBMgd (ORCPT ); Fri, 2 Sep 2022 08:36:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236945AbiIBMf3 (ORCPT ); Fri, 2 Sep 2022 08:35:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52EC7D9D64; Fri, 2 Sep 2022 05:28:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CB6C36212F; Fri, 2 Sep 2022 12:28:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1255C433C1; Fri, 2 Sep 2022 12:28:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121696; bh=6mqy5Wkl20w3CMC3oxYQb1A16d6We5aBAIxQMRwkoiM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R9j0otvSFSU0yvvzTRUvV33r6RfJrcxizPJzh9B00dLJFobsrnEIzJvuVr+XnMSiY Ay9hc70X91J1vqb5pi0hoRN6XEoeDhtRd6XACUzji1nMGulLWoPdnZDnE8tiSMF4fr W8/GEInCk7JfnA9Al3F+6v7yYUDVAPc2MRpx7cEQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qu Wenruo , Filipe Manana , David Sterba Subject: [PATCH 5.4 36/77] btrfs: fix silent failure when deleting root reference Date: Fri, 2 Sep 2022 14:18:45 +0200 Message-Id: <20220902121404.848682885@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Filipe Manana commit 47bf225a8d2cccb15f7e8d4a1ed9b757dd86afd7 upstream. At btrfs_del_root_ref(), if btrfs_search_slot() returns an error, we end up returning from the function with a value of 0 (success). This happens because the function returns the value stored in the variable 'err', which is 0, while the error value we got from btrfs_search_slot() is stored in the 'ret' variable. So fix it by setting 'err' with the error value. Fixes: 8289ed9f93bef2 ("btrfs: replace the BUG_ON in btrfs_del_root_ref wit= h proper error handling") CC: stable@vger.kernel.org # 5.16+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/root-tree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/fs/btrfs/root-tree.c +++ b/fs/btrfs/root-tree.c @@ -371,9 +371,10 @@ int btrfs_del_root_ref(struct btrfs_tran key.offset =3D ref_id; again: ret =3D btrfs_search_slot(trans, tree_root, &key, path, -1, 1); - if (ret < 0) + if (ret < 0) { + err =3D ret; goto out; - if (ret =3D=3D 0) { + } else if (ret =3D=3D 0) { leaf =3D path->nodes[0]; ref =3D btrfs_item_ptr(leaf, path->slots[0], struct btrfs_root_ref); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F26BECAAD5 for ; Fri, 2 Sep 2022 12:58:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238240AbiIBM6T (ORCPT ); Fri, 2 Sep 2022 08:58:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238196AbiIBM4m (ORCPT ); Fri, 2 Sep 2022 08:56:42 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEC266B8D4; Fri, 2 Sep 2022 05:39:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DC4B0620C5; Fri, 2 Sep 2022 12:28:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2F84C433D7; Fri, 2 Sep 2022 12:28:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121699; bh=viyntUJVeoiLePXjjdQmgHgxrdmmNar39wGScCadoLk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XpI0XTIjBa4bKcMB2/9hMXr4BLtNptcVzgUoE4vbCsYGgpoU5nj5bhIZ62c6QairJ PHnH3k1K8EnuyP5JB1mTqEa24ewDTo0gM5RP96/GuBkQJfVNkP+cFjhXRz7YuZwPwX KBfLA/NYw6gLOl0hqb+prnsH7e6pHXXkZEsnfvfo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Anand Jain , David Sterba Subject: [PATCH 5.4 37/77] btrfs: replace: drop assert for suspended replace Date: Fri, 2 Sep 2022 14:18:46 +0200 Message-Id: <20220902121404.886346717@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Anand Jain commit 59a3991984dbc1fc47e5651a265c5200bd85464e upstream. If the filesystem mounts with the replace-operation in a suspended state and try to cancel the suspended replace-operation, we hit the assert. The assert came from the commit fe97e2e173af ("btrfs: dev-replace: replace's scrub must not be running in suspended state") that was actually not required. So just remove it. $ mount /dev/sda5 /btrfs BTRFS info (device sda5): cannot continue dev_replace, tgtdev is missing BTRFS info (device sda5): you may cancel the operation after 'mount -o = degraded' $ mount -o degraded /dev/sda5 /btrfs <-- success. $ btrfs replace cancel /btrfs kernel: assertion failed: ret !=3D -ENOTCONN, in fs/btrfs/dev-replace.c= :1131 kernel: ------------[ cut here ]------------ kernel: kernel BUG at fs/btrfs/ctree.h:3750! After the patch: $ btrfs replace cancel /btrfs BTRFS info (device sda5): suspended dev_replace from /dev/sda5 (devid 1= ) to canceled Fixes: fe97e2e173af ("btrfs: dev-replace: replace's scrub must not be runni= ng in suspended state") CC: stable@vger.kernel.org # 5.0+ Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/dev-replace.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/btrfs/dev-replace.c +++ b/fs/btrfs/dev-replace.c @@ -918,8 +918,7 @@ int btrfs_dev_replace_cancel(struct btrf up_write(&dev_replace->rwsem); =20 /* Scrub for replace must not be running in suspended state */ - ret =3D btrfs_scrub_cancel(fs_info); - ASSERT(ret !=3D -ENOTCONN); + btrfs_scrub_cancel(fs_info); =20 trans =3D btrfs_start_transaction(root, 0); if (IS_ERR(trans)) { From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CB14ECAAD5 for ; Fri, 2 Sep 2022 12:39:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237151AbiIBMii (ORCPT ); Fri, 2 Sep 2022 08:38:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237113AbiIBMhx (ORCPT ); Fri, 2 Sep 2022 08:37:53 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBDD76582B; Fri, 2 Sep 2022 05:29:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C29D7B82AA0; Fri, 2 Sep 2022 12:28:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22A2AC433C1; Fri, 2 Sep 2022 12:28:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121702; bh=zNWRUZADOgj+xnYc4FqfxSrVRPcHNXVyJfRGwVPcYK4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lc+UacfzIW3DyGxmd3fLp9VUMYiY7rsL251NMV9ToSOuIkUd5rzIqLL03s+6qbJRP 6B7N7Qn7fiHK1n5VwtuPJ/WlMQg1RFE2Cd2SHpJJJfIi3C2YUlVHV/CZ+/2NVTYepO mOWuPrQfMfr2w6bgEnHGRekq0nj6ZEV+ygr5zBjQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Samuel Greiner , Anand Jain , David Sterba Subject: [PATCH 5.4 38/77] btrfs: add info when mount fails due to stale replace target Date: Fri, 2 Sep 2022 14:18:47 +0200 Message-Id: <20220902121404.916620561@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Anand Jain commit f2c3bec215694fb8bc0ef5010f2a758d1906fc2d upstream. If the replace target device reappears after the suspended replace is cancelled, it blocks the mount operation as it can't find the matching replace-item in the metadata. As shown below, BTRFS error (device sda5): replace devid present without an active repla= ce item To overcome this situation, the user can run the command btrfs device scan --forget and try the mount command again. And also, to avoid repeating the issue, superblock on the devid=3D0 must be wiped. wipefs -a device-path-to-devid=3D0. This patch adds some info when this situation occurs. Reported-by: Samuel Greiner Link: https://lore.kernel.org/linux-btrfs/b4f62b10-b295-26ea-71f9-9a5c9299d= 42c@balkonien.org/T/ CC: stable@vger.kernel.org # 5.0+ Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/dev-replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/btrfs/dev-replace.c +++ b/fs/btrfs/dev-replace.c @@ -125,7 +125,7 @@ no_valid_dev_replace_entry_found: if (btrfs_find_device(fs_info->fs_devices, BTRFS_DEV_REPLACE_DEVID, NULL, NULL, false)) { btrfs_err(fs_info, - "replace devid present without an active replace item"); +"replace without active item, run 'device scan --forget' on the target dev= ice"); ret =3D -EUCLEAN; } else { dev_replace->srcdev =3D NULL; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07A16C6FA82 for ; Fri, 2 Sep 2022 12:40:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237100AbiIBMkV (ORCPT ); Fri, 2 Sep 2022 08:40:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237109AbiIBMiZ (ORCPT ); Fri, 2 Sep 2022 08:38:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A24E14D14; Fri, 2 Sep 2022 05:29:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 24C776212E; Fri, 2 Sep 2022 12:28:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 278F4C433D6; Fri, 2 Sep 2022 12:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121705; bh=lcyJE0m0RvTkV7SS8mQ29O1jB6tQLac53XR7vc6SdT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YYpIWZPNERB6jbq8oUW3LTfxZvSsb0IpWvMvqUfelKyw/0VaTp2Lf1WVOEz+BJBbF flu5ZglV1kHaH84sGn678mc3XrBcgzCh4+CcxLeT2hK0HqVQpzhvCq117QM0EstQQJ 6gmhazqm4Fn0WZycPSdogt3ZapseUDB6pCYUeQqk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qu Wenruo , Filipe Manana , Goldwyn Rodrigues , David Sterba Subject: [PATCH 5.4 39/77] btrfs: check if root is readonly while setting security xattr Date: Fri, 2 Sep 2022 14:18:48 +0200 Message-Id: <20220902121404.952779080@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Goldwyn Rodrigues commit b51111271b0352aa596c5ae8faf06939e91b3b68 upstream. For a filesystem which has btrfs read-only property set to true, all write operations including xattr should be denied. However, security xattr can still be changed even if btrfs ro property is true. This happens because xattr_permission() does not have any restrictions on security.*, system.* and in some cases trusted.* from VFS and the decision is left to the underlying filesystem. See comments in xattr_permission() for more details. This patch checks if the root is read-only before performing the set xattr operation. Testcase: DEV=3D/dev/vdb MNT=3D/mnt mkfs.btrfs -f $DEV mount $DEV $MNT echo "file one" > $MNT/f1 setfattr -n "security.one" -v 2 $MNT/f1 btrfs property set /mnt ro true setfattr -n "security.one" -v 1 $MNT/f1 umount $MNT CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Goldwyn Rodrigues Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/xattr.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/btrfs/xattr.c +++ b/fs/btrfs/xattr.c @@ -387,6 +387,9 @@ static int btrfs_xattr_handler_set(const const char *name, const void *buffer, size_t size, int flags) { + if (btrfs_root_readonly(BTRFS_I(inode)->root)) + return -EROFS; + name =3D xattr_full_name(handler, name); return btrfs_setxattr_trans(inode, name, buffer, size, flags); } From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2C53C38145 for ; Fri, 2 Sep 2022 12:36:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236989AbiIBMf7 (ORCPT ); Fri, 2 Sep 2022 08:35:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236565AbiIBMeM (ORCPT ); Fri, 2 Sep 2022 08:34:12 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77D42D632F; Fri, 2 Sep 2022 05:28:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 273FA62160; Fri, 2 Sep 2022 12:28:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BC77C433D6; Fri, 2 Sep 2022 12:28:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121708; bh=eimgQIMxHZOEPBtE5nCL9Itkgzj3zGOzM7yaxfP4ZyQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E9L1T/1ETqzvVmFpm6xkhmWVMFqggDJh89QYIvSglmqqzleXLo63UaIkDICK9hYX7 /tr6XooYHxo+xMbq5A9dr7WUIxqbivgbSNvXule4chDkJuLlrAW6qa4TyC5+aGA8+E rz7xLiFpAqKlfNk9xGFv2cXLaYgMKDEGOHs9BpJ0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chen Zhongjin , Ingo Molnar , "Steven Rostedt (Google)" Subject: [PATCH 5.4 40/77] x86/unwind/orc: Unwind ftrace trampolines with correct ORC entry Date: Fri, 2 Sep 2022 14:18:49 +0200 Message-Id: <20220902121404.981315369@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Chen Zhongjin commit fc2e426b1161761561624ebd43ce8c8d2fa058da upstream. When meeting ftrace trampolines in ORC unwinding, unwinder uses address of ftrace_{regs_}call address to find the ORC entry, which gets next frame = at sp+176. If there is an IRQ hitting at sub $0xa8,%rsp, the next frame should be sp+8 instead of 176. It makes unwinder skip correct frame and throw warnings such as "wrong direction" or "can't access registers", etc, depending on the content of the incorrect frame address. By adding the base address ftrace_{regs_}caller with the offset *ip - ops->trampoline*, we can get the correct address to find the ORC entr= y. Also change "caller" to "tramp_addr" to make variable name conform to its content. [ mingo: Clarified the changelog a bit. ] Fixes: 6be7fa3c74d1 ("ftrace, orc, x86: Handle ftrace dynamically allocated= trampolines") Signed-off-by: Chen Zhongjin Signed-off-by: Ingo Molnar Reviewed-by: Steven Rostedt (Google) Cc: Link: https://lore.kernel.org/r/20220819084334.244016-1-chenzhongjin@huawei= .com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kernel/unwind_orc.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) --- a/arch/x86/kernel/unwind_orc.c +++ b/arch/x86/kernel/unwind_orc.c @@ -90,22 +90,27 @@ static struct orc_entry *orc_find(unsign static struct orc_entry *orc_ftrace_find(unsigned long ip) { struct ftrace_ops *ops; - unsigned long caller; + unsigned long tramp_addr, offset; =20 ops =3D ftrace_ops_trampoline(ip); if (!ops) return NULL; =20 + /* Set tramp_addr to the start of the code copied by the trampoline */ if (ops->flags & FTRACE_OPS_FL_SAVE_REGS) - caller =3D (unsigned long)ftrace_regs_call; + tramp_addr =3D (unsigned long)ftrace_regs_caller; else - caller =3D (unsigned long)ftrace_call; + tramp_addr =3D (unsigned long)ftrace_caller; + + /* Now place tramp_addr to the location within the trampoline ip is at */ + offset =3D ip - ops->trampoline; + tramp_addr +=3D offset; =20 /* Prevent unlikely recursion */ - if (ip =3D=3D caller) + if (ip =3D=3D tramp_addr) return NULL; =20 - return orc_find(caller); + return orc_find(tramp_addr); } #else static struct orc_entry *orc_ftrace_find(unsigned long ip) From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADBD3ECAAD5 for ; Fri, 2 Sep 2022 12:40:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237207AbiIBMki (ORCPT ); Fri, 2 Sep 2022 08:40:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237176AbiIBMim (ORCPT ); Fri, 2 Sep 2022 08:38:42 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FED250063; Fri, 2 Sep 2022 05:30:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A4A00B82AA1; Fri, 2 Sep 2022 12:28:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0432DC433C1; Fri, 2 Sep 2022 12:28:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121714; bh=WyLP5ydkN6YSnIDeflr0Opmd73Mf9jckl4YO+rrhNWc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ReEw3j/c+ZjjcFWWHHLPPhuOn4+JHFMCFZUADtOzXB3l4uHErzWtXMuc7/2hrqCz1 yWf8bagSXpTXEI+4AKAeybz2ANrSEZRTJBoSWObmYEPXsZnbLFnmj3SKCuec1Nyx4e UjhJL+hW9e1R+b+EpJS+Iugmi567sOrKeDRJtWx4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Matthew Wilcox (Oracle)" , Siddh Raman Pant , Christoph Hellwig , Jens Axboe , syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com Subject: [PATCH 5.4 41/77] loop: Check for overflow while configuring loop Date: Fri, 2 Sep 2022 14:18:50 +0200 Message-Id: <20220902121405.014969652@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Siddh Raman Pant commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 upstream. The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset =3D info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=3Dc620fe14aac810396d3c3edc= 9ad73848bf69a29e Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.c= om Cc: stable@vger.kernel.org Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Siddh Raman Pant Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/block/loop.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1397,6 +1397,11 @@ loop_get_status(struct loop_device *lo, info->lo_number =3D lo->lo_number; info->lo_offset =3D lo->lo_offset; info->lo_sizelimit =3D lo->lo_sizelimit; + + /* loff_t vars have been assigned __u64 */ + if (lo->lo_offset < 0 || lo->lo_sizelimit < 0) + return -EOVERFLOW; + info->lo_flags =3D lo->lo_flags; memcpy(info->lo_file_name, lo->lo_file_name, LO_NAME_SIZE); memcpy(info->lo_crypt_name, lo->lo_crypt_name, LO_NAME_SIZE); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C502AECAAD5 for ; Fri, 2 Sep 2022 12:41:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236502AbiIBMld (ORCPT ); Fri, 2 Sep 2022 08:41:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237334AbiIBMjQ (ORCPT ); Fri, 2 Sep 2022 08:39:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A92263AD; Fri, 2 Sep 2022 05:30:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2029762109; Fri, 2 Sep 2022 12:28:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22F26C433C1; Fri, 2 Sep 2022 12:28:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121717; bh=dwulq3C42+QL6V1OJqh9EVSXbXuaeZA6njsv2Gq/iEI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v6Ar2SGZSxOt8cH1N4sKFDjTU7UKIggsaZTJYm9rBB8eCEFhG3pz3FvgBniNpmmyu rgamyLU+OiJy6fe3rdOV7auzORKHMg8sS8YJ6bcdKTXiHygZ+Bz4IETjQ8u6GP4cad qWZ9uemA+Hx3Jv2KHVmftUIDrdHVcMM+8+66FvXg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Quanyang Wang , Ard Biesheuvel , Arnd Bergmann , Thierry Reding , Andrew Morton Subject: [PATCH 5.4 42/77] asm-generic: sections: refactor memory_intersects Date: Fri, 2 Sep 2022 14:18:51 +0200 Message-Id: <20220902121405.050717759@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Quanyang Wang commit 0c7d7cc2b4fe2e74ef8728f030f0f1674f9f6aee upstream. There are two problems with the current code of memory_intersects: First, it doesn't check whether the region (begin, end) falls inside the region (virt, vend), that is (virt < begin && vend > end). The second problem is if vend is equal to begin, it will return true but this is wrong since vend (virt + size) is not the last address of the memory region but (virt + size -1) is. The wrong determination will trigger the misreporting when the function check_for_illegal_area calls memory_intersects to check if the dma region intersects with stext region. The misreporting is as below (stext is at 0x80100000): WARNING: CPU: 0 PID: 77 at kernel/dma/debug.c:1073 check_for_illegal_area+= 0x130/0x168 DMA-API: chipidea-usb2 e0002000.usb: device driver maps memory from kernel= text or rodata [addr=3D800f0000] [len=3D65536] Modules linked in: CPU: 1 PID: 77 Comm: usb-storage Not tainted 5.19.0-yocto-standard #5 Hardware name: Xilinx Zynq Platform unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0xb0/0x198 __warn from warn_slowpath_fmt+0x80/0xb4 warn_slowpath_fmt from check_for_illegal_area+0x130/0x168 check_for_illegal_area from debug_dma_map_sg+0x94/0x368 debug_dma_map_sg from __dma_map_sg_attrs+0x114/0x128 __dma_map_sg_attrs from dma_map_sg_attrs+0x18/0x24 dma_map_sg_attrs from usb_hcd_map_urb_for_dma+0x250/0x3b4 usb_hcd_map_urb_for_dma from usb_hcd_submit_urb+0x194/0x214 usb_hcd_submit_urb from usb_sg_wait+0xa4/0x118 usb_sg_wait from usb_stor_bulk_transfer_sglist+0xa0/0xec usb_stor_bulk_transfer_sglist from usb_stor_bulk_srb+0x38/0x70 usb_stor_bulk_srb from usb_stor_Bulk_transport+0x150/0x360 usb_stor_Bulk_transport from usb_stor_invoke_transport+0x38/0x440 usb_stor_invoke_transport from usb_stor_control_thread+0x1e0/0x238 usb_stor_control_thread from kthread+0xf8/0x104 kthread from ret_from_fork+0x14/0x2c Refactor memory_intersects to fix the two problems above. Before the 1d7db834a027e ("dma-debug: use memory_intersects() directly"), memory_intersects is called only by printk_late_init: printk_late_init -> init_section_intersects ->memory_intersects. There were few places where memory_intersects was called. When commit 1d7db834a027e ("dma-debug: use memory_intersects() directly") was merged and CONFIG_DMA_API_DEBUG is enabled, the DMA subsystem uses it to check for an illegal area and the calltrace above is triggered. [akpm@linux-foundation.org: fix nearby comment typo] Link: https://lkml.kernel.org/r/20220819081145.948016-1-quanyang.wang@windr= iver.com Fixes: 979559362516 ("asm/sections: add helpers to check for section data") Signed-off-by: Quanyang Wang Cc: Ard Biesheuvel Cc: Arnd Bergmann Cc: Thierry Reding Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/asm-generic/sections.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/include/asm-generic/sections.h +++ b/include/asm-generic/sections.h @@ -114,7 +114,7 @@ static inline bool memory_contains(void /** * memory_intersects - checks if the region occupied by an object intersec= ts * with another memory region - * @begin: virtual address of the beginning of the memory regien + * @begin: virtual address of the beginning of the memory region * @end: virtual address of the end of the memory region * @virt: virtual address of the memory object * @size: size of the memory object @@ -127,7 +127,10 @@ static inline bool memory_intersects(voi { void *vend =3D virt + size; =20 - return (virt >=3D begin && virt < end) || (vend >=3D begin && vend < end); + if (virt < end && vend > begin) + return true; + + return false; } =20 /** From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC02CECAAD5 for ; Fri, 2 Sep 2022 12:41:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237227AbiIBMli (ORCPT ); Fri, 2 Sep 2022 08:41:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237356AbiIBMjZ (ORCPT ); Fri, 2 Sep 2022 08:39:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1723BA1A74; Fri, 2 Sep 2022 05:30:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AFAEDB82AA3; Fri, 2 Sep 2022 12:28:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2774AC433C1; Fri, 2 Sep 2022 12:28:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121720; bh=GuzXSFrL/EBvMxMZXb2JOrr+YkM+uKtUf0mRfOOrHEM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AYt9DSztylV8zpd6cZcWTc9OA83VCViHYcmxlI9GcgT2We4eqsrW9SJwsDAHGevQ5 LfYlrLzUEiantoueES1HYgOiqXvyoMcqy0K6qgWmt7P2gRKnw07ySlGxfnkVYz75x9 NZzqKvnDPLTYKgUkmQ2Qo9g0VI/V1CiavvwA4dZI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , Gerald Schaefer , Heiko Carstens , Vasily Gorbik Subject: [PATCH 5.4 43/77] s390: fix double free of GS and RI CBs on fork() failure Date: Fri, 2 Sep 2022 14:18:52 +0200 Message-Id: <20220902121405.088058691@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Brian Foster commit 13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9 upstream. The pointers for guarded storage and runtime instrumentation control blocks are stored in the thread_struct of the associated task. These pointers are initially copied on fork() via arch_dup_task_struct() and then cleared via copy_thread() before fork() returns. If fork() happens to fail after the initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via free_task() -> arch_release_task_struct(). This results in a double free of the guarded storage and runtime info structs because the fields in the failed task still refer to memory associated with the source task. This problem can manifest as a BUG_ON() in set_freepointer() (with CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled) when running trinity syscall fuzz tests on s390x. To avoid this problem, clear the associated pointer fields in arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread() because it resides in thread stack memory and that is where stack info is copied. Signed-off-by: Brian Foster Fixes: 8d9047f8b967c ("s390/runtime instrumentation: simplify task exit han= dling") Fixes: 7b83c6297d2fc ("s390/guarded storage: simplify task exit handling") Cc: # 4.15 Reviewed-by: Gerald Schaefer Reviewed-by: Heiko Carstens Link: https://lore.kernel.org/r/20220816155407.537372-1-bfoster@redhat.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/kernel/process.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) --- a/arch/s390/kernel/process.c +++ b/arch/s390/kernel/process.c @@ -76,6 +76,18 @@ int arch_dup_task_struct(struct task_str =20 memcpy(dst, src, arch_task_struct_size); dst->thread.fpu.regs =3D dst->thread.fpu.fprs; + + /* + * Don't transfer over the runtime instrumentation or the guarded + * storage control block pointers. These fields are cleared here instead + * of in copy_thread() to avoid premature freeing of associated memory + * on fork() failure. Wait to clear the RI flag because ->stack still + * refers to the source thread. + */ + dst->thread.ri_cb =3D NULL; + dst->thread.gs_cb =3D NULL; + dst->thread.gs_bc_cb =3D NULL; + return 0; } =20 @@ -133,13 +145,11 @@ int copy_thread_tls(unsigned long clone_ frame->childregs.flags =3D 0; if (new_stackp) frame->childregs.gprs[15] =3D new_stackp; - - /* Don't copy runtime instrumentation info */ - p->thread.ri_cb =3D NULL; + /* + * Clear the runtime instrumentation flag after the above childregs + * copy. The CB pointer was already cleared in arch_dup_task_struct(). + */ frame->childregs.psw.mask &=3D ~PSW_MASK_RI; - /* Don't copy guarded storage control block */ - p->thread.gs_cb =3D NULL; - p->thread.gs_bc_cb =3D NULL; =20 /* Set a new TLS ? */ if (clone_flags & CLONE_SETTLS) { From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8E63ECAAD5 for ; Fri, 2 Sep 2022 12:40:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237032AbiIBMkC (ORCPT ); Fri, 2 Sep 2022 08:40:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236947AbiIBMiR (ORCPT ); Fri, 2 Sep 2022 08:38:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A52D65E6; Fri, 2 Sep 2022 05:30:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 111B462160; Fri, 2 Sep 2022 12:28:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19934C433C1; Fri, 2 Sep 2022 12:28:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121723; bh=j/8XAWMQ7PlP+5WrROnEfX7lfhQhIwUDBWAojUg3vvM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bce+ex7L1Isuslx8Z5x0OKXBF8m02AmNP+lbK0/sIMcnvNLZX+f/oVfO9FadtgbEm Bkt+/tdt8ADZc/1+EEgIdCExc3MSiRSNtWJJnhg51a2XGOC4PZqB2tkKDk1cb19/Lo G0mz4nxDjtPvMib5chsCUMoBXgemLyydD/3Lmo8A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeremy Linton , Jeremy Linton , Riwen Lu , "Rafael J. Wysocki" Subject: [PATCH 5.4 44/77] ACPI: processor: Remove freq Qos request for all CPUs Date: Fri, 2 Sep 2022 14:18:53 +0200 Message-Id: <20220902121405.116990661@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Riwen Lu commit 36527b9d882362567ceb4eea8666813280f30e6f upstream. The freq Qos request would be removed repeatedly if the cpufreq policy relates to more than one CPU. Then, it would cause the "called for unknown object" warning. Remove the freq Qos request for each CPU relates to the cpufreq policy, instead of removing repeatedly for the last CPU of it. Fixes: a1bb46c36ce3 ("ACPI: processor: Add QoS requests for all CPUs") Reported-by: Jeremy Linton Tested-by: Jeremy Linton Signed-off-by: Riwen Lu Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/processor_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/acpi/processor_thermal.c +++ b/drivers/acpi/processor_thermal.c @@ -150,7 +150,7 @@ void acpi_thermal_cpufreq_exit(struct cp unsigned int cpu; =20 for_each_cpu(cpu, policy->related_cpus) { - struct acpi_processor *pr =3D per_cpu(processors, policy->cpu); + struct acpi_processor *pr =3D per_cpu(processors, cpu); =20 if (pr) freq_qos_remove_request(&pr->thermal_req); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A07EC38145 for ; Fri, 2 Sep 2022 12:40:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237230AbiIBMkt (ORCPT ); Fri, 2 Sep 2022 08:40:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237172AbiIBMil (ORCPT ); Fri, 2 Sep 2022 08:38:41 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93C443FA11; Fri, 2 Sep 2022 05:30:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CEB21B82AA5; Fri, 2 Sep 2022 12:28:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01041C433D6; Fri, 2 Sep 2022 12:28:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121726; bh=e7iSAsuMgLzDD22dnjqsXL2x5AyqGYLuAhRZDowhmYM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YiuxYFqTD3SHywplhLDPoE3SJ76ck4TprfwGJ9f75efu8E4nqivmhe2yiD5i59aGf CZjz/ZlLJbOf8xOeACcF3jioGwwOTn1pCnXRbkvd8lJgbmoxGi8CFADBM6NFU8vB82 DZTUDcctI1joYCVYicVPpNyBo1BOgeKkCERoWvAU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Hildenbrand , Mike Kravetz , Peter Feiner , "Kirill A. Shutemov" , Cyrill Gorcunov , Pavel Emelyanov , Jamie Liu , Hugh Dickins , Naoya Horiguchi , Bjorn Helgaas , Muchun Song , Peter Xu , Andrew Morton Subject: [PATCH 5.4 45/77] mm/hugetlb: fix hugetlb not supporting softdirty tracking Date: Fri, 2 Sep 2022 14:18:54 +0200 Message-Id: <20220902121405.146172884@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: David Hildenbrand commit f96f7a40874d7c746680c0b9f57cef2262ae551f upstream. Patch series "mm/hugetlb: fix write-fault handling for shared mappings", v2. I observed that hugetlb does not support/expect write-faults in shared mappings that would have to map the R/O-mapped page writable -- and I found two case where we could currently get such faults and would erroneously map an anon page into a shared mapping. Reproducers part of the patches. I propose to backport both fixes to stable trees. The first fix needs a small adjustment. This patch (of 2): Staring at hugetlb_wp(), one might wonder where all the logic for shared mappings is when stumbling over a write-protected page in a shared mapping. In fact, there is none, and so far we thought we could get away with that because e.g., mprotect() should always do the right thing and map all pages directly writable. Looks like we were wrong: Reviewed-by: Mike Kravetz Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee -------------------------------------------------------------------------- #include #include #include #include #include #include #include #define HUGETLB_SIZE (2 * 1024 * 1024u) static void clear_softdirty(void) { int fd =3D open("/proc/self/clear_refs", O_WRONLY); const char *ctrl =3D "4"; int ret; if (fd < 0) { fprintf(stderr, "open(clear_refs) failed\n"); exit(1); } ret =3D write(fd, ctrl, strlen(ctrl)); if (ret !=3D strlen(ctrl)) { fprintf(stderr, "write(clear_refs) failed\n"); exit(1); } close(fd); } int main(int argc, char **argv) { char *map; int fd; fd =3D open("/dev/hugepages/tmp", O_RDWR | O_CREAT); if (!fd) { fprintf(stderr, "open() failed\n"); return -errno; } if (ftruncate(fd, HUGETLB_SIZE)) { fprintf(stderr, "ftruncate() failed\n"); return -errno; } map =3D mmap(NULL, HUGETLB_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED,= fd, 0); if (map =3D=3D MAP_FAILED) { fprintf(stderr, "mmap() failed\n"); return -errno; } *map =3D 0; if (mprotect(map, HUGETLB_SIZE, PROT_READ)) { fprintf(stderr, "mmprotect() failed\n"); return -errno; } clear_softdirty(); if (mprotect(map, HUGETLB_SIZE, PROT_READ|PROT_WRITE)) { fprintf(stderr, "mmprotect() failed\n"); return -errno; } *map =3D 0; return 0; } -------------------------------------------------------------------------- Above test fails with SIGBUS when there is only a single free hugetlb page. # echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # ./test Bus error (core dumped) And worse, with sufficient free hugetlb pages it will map an anonymous page into a shared mapping, for example, messing up accounting during unmap and breaking MAP_SHARED semantics: # echo 2 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # ./test # cat /proc/meminfo | grep HugePages_ HugePages_Total: 2 HugePages_Free: 1 HugePages_Rsvd: 18446744073709551615 HugePages_Surp: 0 Reason in this particular case is that vma_wants_writenotify() will return "true", removing VM_SHARED in vma_set_page_prot() to map pages write-protected. Let's teach vma_wants_writenotify() that hugetlb does not support softdirty tracking. Link: https://lkml.kernel.org/r/20220811103435.188481-1-david@redhat.com Link: https://lkml.kernel.org/r/20220811103435.188481-2-david@redhat.com Fixes: 64e455079e1b ("mm: softdirty: enable write notifications on VMAs aft= er VM_SOFTDIRTY cleared") Signed-off-by: David Hildenbrand Reviewed-by: Mike Kravetz Cc: Peter Feiner Cc: Kirill A. Shutemov Cc: Cyrill Gorcunov Cc: Pavel Emelyanov Cc: Jamie Liu Cc: Hugh Dickins Cc: Naoya Horiguchi Cc: Bjorn Helgaas Cc: Muchun Song Cc: Peter Xu Cc: [3.18+] Signed-off-by: Andrew Morton Signed-off-by: David Hildenbrand Signed-off-by: Greg Kroah-Hartman --- mm/mmap.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1679,8 +1679,12 @@ int vma_wants_writenotify(struct vm_area pgprot_val(vm_pgprot_modify(vm_page_prot, vm_flags))) return 0; =20 - /* Do we need to track softdirty? */ - if (IS_ENABLED(CONFIG_MEM_SOFT_DIRTY) && !(vm_flags & VM_SOFTDIRTY)) + /* + * Do we need to track softdirty? hugetlb does not support softdirty + * tracking yet. + */ + if (IS_ENABLED(CONFIG_MEM_SOFT_DIRTY) && !(vm_flags & VM_SOFTDIRTY) && + !is_vm_hugetlb_page(vma)) return 1; =20 /* Specialty mapping? */ From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5F3DC54EE9 for ; Fri, 2 Sep 2022 12:37:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236916AbiIBMhB (ORCPT ); Fri, 2 Sep 2022 08:37:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237022AbiIBMgS (ORCPT ); Fri, 2 Sep 2022 08:36:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D03CDF4E9; Fri, 2 Sep 2022 05:28:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1C9C7620B6; Fri, 2 Sep 2022 12:28:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1191BC433D6; Fri, 2 Sep 2022 12:28:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121729; bh=GTRHNUjiLIuDq28pzbsM/VXRXBn3isvL/+qqfFlwepA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TqsvRHYmM+n97QOZVikbv7S9zm8q4YHWhFBmtK5QBxTBKvz+A6SqhRay4UJGm/fHn 3+MrC705A4jV94duxdNA8vQ5JrwYW3KUsnon/+Eh6XK1NKnm12xcO7eFaY+sWKnVE/ gFi0CrO0OlT41dxrzsR9cgI5WwO+IFSiDGZjqvDA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikulas Patocka , Guoqing Jiang , Song Liu Subject: [PATCH 5.4 46/77] md: call __md_stop_writes in md_stop Date: Fri, 2 Sep 2022 14:18:55 +0200 Message-Id: <20220902121405.184054467@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Guoqing Jiang commit 0dd84b319352bb8ba64752d4e45396d8b13e6018 upstream. >From the link [1], we can see raid1d was running even after the path raid_dtr -> md_stop -> __md_stop. Let's stop write first in destructor to align with normal md-raid to fix the KASAN issue. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_= sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a Fixes: 48df498daf62 ("md: move bitmap_destroy to the beginning of __md_stop= ") Reported-by: Mikulas Patocka Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/md/md.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -6094,6 +6094,7 @@ void md_stop(struct mddev *mddev) /* stop the array and free an attached data structures. * This is called from dm-raid */ + __md_stop_writes(mddev); __md_stop(mddev); bioset_exit(&mddev->bio_set); bioset_exit(&mddev->sync_set); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5151C6FA82 for ; Fri, 2 Sep 2022 13:47:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236909AbiIBNr2 (ORCPT ); Fri, 2 Sep 2022 09:47:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236951AbiIBNrJ (ORCPT ); Fri, 2 Sep 2022 09:47:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7178323168; Fri, 2 Sep 2022 06:22:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 59EF462180; Fri, 2 Sep 2022 12:28:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55629C433C1; Fri, 2 Sep 2022 12:28:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121732; bh=GXpS0K7nMoJ0lD89ZTWvPSyPpAQxwDn/AVLCeVa0IZw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PCmoN/aRW1pVkxKaYE3PG4TqTs7BgucLTThPLfmVpcueWr8kOWBGXfLYgoh5KVuLT JNWsBtzJHMgiQJnnVO8EgsGDbKPGTLmnq6S5IRYjnrJxBPAMnriV1anjIFBxz24MGD 4wekye8glsLuNwcnVVsGX8tk1TVpKfw34zJKqoNQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephane Eranian , "Peter Zijlstra (Intel)" , Kan Liang Subject: [PATCH 5.4 47/77] perf/x86/intel/uncore: Fix broken read_counter() for SNB IMC PMU Date: Fri, 2 Sep 2022 14:18:56 +0200 Message-Id: <20220902121405.211947115@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Stephane Eranian commit 11745ecfe8fea4b4a4c322967a7605d2ecbd5080 upstream. Existing code was generating bogus counts for the SNB IMC bandwidth counter= s: $ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ 1.000327813 1,024.03 MiB uncore_imc/data_reads/ 1.000327813 20.73 MiB uncore_imc/data_writes/ 2.000580153 261,120.00 MiB uncore_imc/data_reads/ 2.000580153 23.28 MiB uncore_imc/data_writes/ The problem was introduced by commit: 07ce734dd8ad ("perf/x86/intel/uncore: Clean up client IMC") Where the read_counter callback was replace to point to the generic uncore_mmio_read_counter() function. The SNB IMC counters are freerunnig 32-bit counters laid out contiguously in MMIO. But uncore_mmio_read_counter() is using a readq() call to read from MMIO therefore reading 64-bit from MMIO. Although this is okay for the uncore_perf_event_update() function because it is shifting the value based on the actual counter width to compute a delta, it is not okay for the uncore_pmu_event_start() which is simply reading the counter and therefore priming the event->prev_count with a bogus value which is responsible for causing bogus deltas in the perf stat command above. The fix is to reintroduce the custom callback for read_counter for the SNB IMC PMU and use readl() instead of readq(). With the change the output of perf stat is back to normal: $ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ 1.000120987 296.94 MiB uncore_imc/data_reads/ 1.000120987 138.42 MiB uncore_imc/data_writes/ 2.000403144 175.91 MiB uncore_imc/data_reads/ 2.000403144 68.50 MiB uncore_imc/data_writes/ Fixes: 07ce734dd8ad ("perf/x86/intel/uncore: Clean up client IMC") Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20220803160031.1379788-1-eranian@google.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/events/intel/uncore_snb.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/arch/x86/events/intel/uncore_snb.c +++ b/arch/x86/events/intel/uncore_snb.c @@ -575,6 +575,22 @@ int snb_pci2phy_map_init(int devid) return 0; } =20 +static u64 snb_uncore_imc_read_counter(struct intel_uncore_box *box, struc= t perf_event *event) +{ + struct hw_perf_event *hwc =3D &event->hw; + + /* + * SNB IMC counters are 32-bit and are laid out back to back + * in MMIO space. Therefore we must use a 32-bit accessor function + * using readq() from uncore_mmio_read_counter() causes problems + * because it is reading 64-bit at a time. This is okay for the + * uncore_perf_event_update() function because it drops the upper + * 32-bits but not okay for plain uncore_read_counter() as invoked + * in uncore_pmu_event_start(). + */ + return (u64)readl(box->io_addr + hwc->event_base); +} + static struct pmu snb_uncore_imc_pmu =3D { .task_ctx_nr =3D perf_invalid_context, .event_init =3D snb_uncore_imc_event_init, @@ -594,7 +610,7 @@ static struct intel_uncore_ops snb_uncor .disable_event =3D snb_uncore_imc_disable_event, .enable_event =3D snb_uncore_imc_enable_event, .hw_config =3D snb_uncore_imc_hw_config, - .read_counter =3D uncore_mmio_read_counter, + .read_counter =3D snb_uncore_imc_read_counter, }; =20 static struct intel_uncore_type snb_uncore_imc =3D { From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0F61ECAAD5 for ; Fri, 2 Sep 2022 12:37:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237027AbiIBMhE (ORCPT ); Fri, 2 Sep 2022 08:37:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236910AbiIBMg1 (ORCPT ); Fri, 2 Sep 2022 08:36:27 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 461C71D0F1; Fri, 2 Sep 2022 05:29:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E13CCB82A9B; Fri, 2 Sep 2022 12:28:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D7C6C433C1; Fri, 2 Sep 2022 12:28:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121735; bh=DEATEnYUWeZlx0T33Q2V5HdpONmNFsiiqbbVGmxrerY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xVXF494lxZchIr9TzZG53C40m1C/ZMIF97lpivdKqM+05x3z+bwVpqYfH/LD3/fbW 4VM8F+WrITKnFrNLdAkHAqoiovYwWVgi8plgGKUNSRXpszk8EQ3ebwrh2nySt9h9zT A15jKcud1h+HCyJ1GKa9WslaHEMYK8XvyJup7QXU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Kelley , Saurabh Sengar , "Martin K. Petersen" Subject: [PATCH 5.4 48/77] scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq Date: Fri, 2 Sep 2022 14:18:57 +0200 Message-Id: <20220902121405.241549357@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Saurabh Sengar commit d957e7ffb2c72410bcc1a514153a46719255a5da upstream. storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_= lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 ch= eck_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azur= e #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual= Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- Link: https://lore.kernel.org/r/1659628534-17539-1-git-send-email-ssengar@l= inux.microsoft.com Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to= be issued per lun") Reviewed-by: Michael Kelley Signed-off-by: Saurabh Sengar Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/scsi/storvsc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1846,7 +1846,7 @@ static int storvsc_probe(struct hv_devic */ host_dev->handle_error_wq =3D alloc_ordered_workqueue("storvsc_error_wq_%d", - WQ_MEM_RECLAIM, + 0, host->host_no); if (!host_dev->handle_error_wq) goto err_out2; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D5E9C38145 for ; Fri, 2 Sep 2022 12:40:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237256AbiIBMkz (ORCPT ); Fri, 2 Sep 2022 08:40:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237192AbiIBMio (ORCPT ); Fri, 2 Sep 2022 08:38:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BC1F357D4; Fri, 2 Sep 2022 05:30:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2EEA26212F; Fri, 2 Sep 2022 12:28:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E23BC433D6; Fri, 2 Sep 2022 12:28:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121738; bh=UuMUeBmpGk/Mnp+63zDG82AHnd7WX/mFvSbFWECgQbo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UB4yKmBrCOdDaRXGiKBEFqpy5bb5J9FQKbCgdxdGNNNdw+g/ZF6Wsjsc52XWuyWLK Pk/GxGGLEsVAZxPu3cbf5wc7xNIQ4Ir3Xw6E/BWJkEupX50mUK8n51dp1tZyt/O3IZ r6mnsh01uoIs3hrVOmgmQSu0vH2Ezu/a6JT0vbg4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Jann Horn Subject: [PATCH 5.4 49/77] mm: Force TLB flush for PFNMAP mappings before unlink_file_vma() Date: Fri, 2 Sep 2022 14:18:58 +0200 Message-Id: <20220902121405.269688237@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jann Horn commit b67fbebd4cf980aecbcc750e1462128bffe8ae15 upstream. Some drivers rely on having all VMAs through which a PFN might be accessible listed in the rmap for correctness. However, on X86, it was possible for a VMA with stale TLB entries to not be listed in the rmap. This was fixed in mainline with commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"), but that commit relies on preceding refactoring in commit 18ba064e42df3 ("mmu_gather: Let there be one tlb_{start,end}_vma() implementation") and commit 1e9fdf21a4339 ("mmu_gather: Remove per arch tlb_{start,end}_vma()"). This patch provides equivalent protection without needing that refactoring, by forcing a TLB flush between removing PTEs in unmap_vmas() and the call to unlink_file_vma() in free_pgtables(). [This is a stable-specific rewrite of the upstream commit!] Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- mm/mmap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2610,6 +2610,18 @@ static void unmap_region(struct mm_struc tlb_gather_mmu(&tlb, mm, start, end); update_hiwater_rss(mm); unmap_vmas(&tlb, vma, start, end); + + /* + * Ensure we have no stale TLB entries by the time this mapping is + * removed from the rmap. + * Note that we don't have to worry about nested flushes here because + * we're holding the mm semaphore for removing the mapping - so any + * concurrent flush in this region has to be coming through the rmap, + * and we synchronize against that using the rmap lock. + */ + if ((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) !=3D 0) + tlb_flush_mmu(&tlb); + free_pgtables(&tlb, vma, prev ? prev->vm_end : FIRST_USER_ADDRESS, next ? next->vm_start : USER_PGTABLES_CEILING); tlb_finish_mmu(&tlb, start, end); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3120ECAAD5 for ; Fri, 2 Sep 2022 12:37:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236975AbiIBMhN (ORCPT ); Fri, 2 Sep 2022 08:37:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237034AbiIBMgd (ORCPT ); Fri, 2 Sep 2022 08:36:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86259D5E90; Fri, 2 Sep 2022 05:29:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DB13AB82A71; Fri, 2 Sep 2022 12:29:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37A54C433D6; Fri, 2 Sep 2022 12:29:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121741; bh=8pl/xxUZx0RNJID+u/1oHv09CR39OevBrabcZIHbLFw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AJiyt8Jwo5ZLS6UPftya8VAP69JmVU9c0mlTK2hkdyP+BWd6bBiI7ePp3cWFKli8v B0GZ0XttE2BJzmlEHdftNjrvsd2x2ITwVrB0H3P4usPsP4N3dCzzZf+AYA2TnFEq6W VqJP1BmBZHe3rMz0Rzq47/zYOghZkzzhNPPqNTL4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Hildenbrand , Heiko Carstens , Gerald Schaefer , Vasily Gorbik Subject: [PATCH 5.4 50/77] s390/mm: do not trigger write fault when vma does not allow VM_WRITE Date: Fri, 2 Sep 2022 14:18:59 +0200 Message-Id: <20220902121405.298833488@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Gerald Schaefer commit 41ac42f137080bc230b5882e3c88c392ab7f2d32 upstream. For non-protection pXd_none() page faults in do_dat_exception(), we call do_exception() with access =3D=3D (VM_READ | VM_WRITE | VM_EXEC). In do_exception(), vma->vm_flags is checked against that before calling handle_mm_fault(). Since commit 92f842eac7ee3 ("[S390] store indication fault optimization"), we call handle_mm_fault() with FAULT_FLAG_WRITE, when recognizing that it was a write access. However, the vma flags check is still only checking against (VM_READ | VM_WRITE | VM_EXEC), and therefore also calling handle_mm_fault() with FAULT_FLAG_WRITE in cases where the vma does not allow VM_WRITE. Fix this by changing access check in do_exception() to VM_WRITE only, when recognizing write access. Link: https://lkml.kernel.org/r/20220811103435.188481-3-david@redhat.com Fixes: 92f842eac7ee3 ("[S390] store indication fault optimization") Cc: Reported-by: David Hildenbrand Reviewed-by: Heiko Carstens Signed-off-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Gerald Schaefer Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/mm/fault.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -432,7 +432,9 @@ static inline vm_fault_t do_exception(st flags =3D FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE; if (user_mode(regs)) flags |=3D FAULT_FLAG_USER; - if (access =3D=3D VM_WRITE || (trans_exc_code & store_indication) =3D=3D = 0x400) + if ((trans_exc_code & store_indication) =3D=3D 0x400) + access =3D VM_WRITE; + if (access =3D=3D VM_WRITE) flags |=3D FAULT_FLAG_WRITE; down_read(&mm->mmap_sem); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF674C38145 for ; Fri, 2 Sep 2022 12:37:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237036AbiIBMhh (ORCPT ); Fri, 2 Sep 2022 08:37:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236966AbiIBMhJ (ORCPT ); Fri, 2 Sep 2022 08:37:09 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FF4C19C35; Fri, 2 Sep 2022 05:29:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 490E4B82AA6; Fri, 2 Sep 2022 12:29:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93806C433D7; Fri, 2 Sep 2022 12:29:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121748; bh=dAZ++zgFyxETpcFEO9icyMCEuUpUUDFg9OWT0kwHLNM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CyZWoV6mjtQ8Q3JKB/l/yo+4SxFPKDfvbECJUId/YYdJNoQLKrPY41hWqjNWF4+nz vc022FWw9bH1z4yubIhd+qZMMXllc7BSS0aMFHz4VxBHg66C0oPBuPQ1Zo9u3sFCSE oXvLorknXxHlbSt1e2yizXUwH7wT50t3CVaiijdY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrew Cooper , Tony Luck , Pawan Gupta , Borislav Petkov Subject: [PATCH 5.4 51/77] x86/bugs: Add "unknown" reporting for MMIO Stale Data Date: Fri, 2 Sep 2022 14:19:00 +0200 Message-Id: <20220902121405.344334240@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 7df548840c496b0141fb2404b889c346380c2b22 upstream. Older Intel CPUs that are not in the affected processor list for MMIO Stale Data vulnerabilities currently report "Not affected" in sysfs, which may not be correct. Vulnerability status for these older CPUs is unknown. Add known-not-affected CPUs to the whitelist. Report "unknown" mitigation status for CPUs that are not in blacklist, whitelist and also don't enumerate MSR ARCH_CAPABILITIES bits that reflect hardware immunity to MMIO Stale Data vulnerabilities. Mitigation is not deployed when the status is unknown. [ bp: Massage, fixup. ] Fixes: 8d50cdf8b834 ("x86/speculation/mmio: Add sysfs reporting for Process= or MMIO Stale Data") Suggested-by: Andrew Cooper Suggested-by: Tony Luck Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/a932c154772f2121794a5f2eded1a11013114711.16= 57846269.git.pawan.kumar.gupta@linux.intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 14 +++ arch/x86/include/asm/cpufeatures.h | 3=20 arch/x86/kernel/cpu/bugs.c | 14 +++ arch/x86/kernel/cpu/common.c | 40 +++= +++---- 4 files changed, 54 insertions(+), 17 deletions(-) --- a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst +++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst @@ -230,6 +230,20 @@ The possible values in this file are: * - 'Mitigation: Clear CPU buffers' - The processor is vulnerable and the CPU buffer clearing mitigatio= n is enabled. + * - 'Unknown: No mitigations' + - The processor vulnerability status is unknown because it is + out of Servicing period. Mitigation is not attempted. + +Definitions: +------------ + +Servicing period: The process of providing functional and security updates= to +Intel processors or platforms, utilizing the Intel Platform Update (IPU) +process or other similar mechanisms. + +End of Servicing Updates (ESU): ESU is the date at which Intel will no +longer provide Servicing, such as through IPU or other similar update +processes. ESU dates will typically be aligned to end of quarter. =20 If the processor is vulnerable then the following information is appended = to the above information: --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -407,6 +407,7 @@ #define X86_BUG_ITLB_MULTIHIT X86_BUG(23) /* CPU may incur MCE during cer= tain page attribute changes */ #define X86_BUG_SRBDS X86_BUG(24) /* CPU may leak RNG bits if not mitiga= ted */ #define X86_BUG_MMIO_STALE_DATA X86_BUG(25) /* CPU is affected by Process= or MMIO Stale Data vulnerabilities */ -#define X86_BUG_EIBRS_PBRSB X86_BUG(26) /* EIBRS is vulnerable to Post Ba= rrier RSB Predictions */ +#define X86_BUG_MMIO_UNKNOWN X86_BUG(26) /* CPU is too old and its MMIO S= tale Data status is unknown */ +#define X86_BUG_EIBRS_PBRSB X86_BUG(27) /* EIBRS is vulnerable to Post Ba= rrier RSB Predictions */ =20 #endif /* _ASM_X86_CPUFEATURES_H */ --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -396,7 +396,8 @@ static void __init mmio_select_mitigatio u64 ia32_cap; =20 if (!boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA) || - cpu_mitigations_off()) { + boot_cpu_has_bug(X86_BUG_MMIO_UNKNOWN) || + cpu_mitigations_off()) { mmio_mitigation =3D MMIO_MITIGATION_OFF; return; } @@ -501,6 +502,8 @@ out: pr_info("TAA: %s\n", taa_strings[taa_mitigation]); if (boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA)) pr_info("MMIO Stale Data: %s\n", mmio_strings[mmio_mitigation]); + else if (boot_cpu_has_bug(X86_BUG_MMIO_UNKNOWN)) + pr_info("MMIO Stale Data: Unknown: No mitigations\n"); } =20 static void __init md_clear_select_mitigation(void) @@ -1880,6 +1883,9 @@ static ssize_t tsx_async_abort_show_stat =20 static ssize_t mmio_stale_data_show_state(char *buf) { + if (boot_cpu_has_bug(X86_BUG_MMIO_UNKNOWN)) + return sysfs_emit(buf, "Unknown: No mitigations\n"); + if (mmio_mitigation =3D=3D MMIO_MITIGATION_OFF) return sysfs_emit(buf, "%s\n", mmio_strings[mmio_mitigation]); =20 @@ -2007,6 +2013,7 @@ static ssize_t cpu_show_common(struct de return srbds_show_state(buf); =20 case X86_BUG_MMIO_STALE_DATA: + case X86_BUG_MMIO_UNKNOWN: return mmio_stale_data_show_state(buf); =20 default: @@ -2063,6 +2070,9 @@ ssize_t cpu_show_srbds(struct device *de =20 ssize_t cpu_show_mmio_stale_data(struct device *dev, struct device_attribu= te *attr, char *buf) { - return cpu_show_common(dev, attr, buf, X86_BUG_MMIO_STALE_DATA); + if (boot_cpu_has_bug(X86_BUG_MMIO_UNKNOWN)) + return cpu_show_common(dev, attr, buf, X86_BUG_MMIO_UNKNOWN); + else + return cpu_show_common(dev, attr, buf, X86_BUG_MMIO_STALE_DATA); } #endif --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1026,6 +1026,7 @@ static void identify_cpu_without_cpuid(s #define NO_ITLB_MULTIHIT BIT(7) #define NO_SPECTRE_V2 BIT(8) #define NO_EIBRS_PBRSB BIT(9) +#define NO_MMIO BIT(10) =20 #define VULNWL(_vendor, _family, _model, _whitelist) \ { X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist } @@ -1046,6 +1047,11 @@ static const __initconst struct x86_cpu_ VULNWL(NSC, 5, X86_MODEL_ANY, NO_SPECULATION), =20 /* Intel Family 6 */ + VULNWL_INTEL(TIGERLAKE, NO_MMIO), + VULNWL_INTEL(TIGERLAKE_L, NO_MMIO), + VULNWL_INTEL(ALDERLAKE, NO_MMIO), + VULNWL_INTEL(ALDERLAKE_L, NO_MMIO), + VULNWL_INTEL(ATOM_SALTWELL, NO_SPECULATION | NO_ITLB_MULTIHIT), VULNWL_INTEL(ATOM_SALTWELL_TABLET, NO_SPECULATION | NO_ITLB_MULTIHIT), VULNWL_INTEL(ATOM_SALTWELL_MID, NO_SPECULATION | NO_ITLB_MULTIHIT), @@ -1064,9 +1070,9 @@ static const __initconst struct x86_cpu_ VULNWL_INTEL(ATOM_AIRMONT_MID, NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITL= B_MULTIHIT), VULNWL_INTEL(ATOM_AIRMONT_NP, NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT), =20 - VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTI= HIT), - VULNWL_INTEL(ATOM_GOLDMONT_D, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MUL= TIHIT), - VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_M= ULTIHIT | NO_EIBRS_PBRSB), + VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTI= HIT | NO_MMIO), + VULNWL_INTEL(ATOM_GOLDMONT_D, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MUL= TIHIT | NO_MMIO), + VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_M= ULTIHIT | NO_MMIO | NO_EIBRS_PBRSB), =20 /* * Technically, swapgs isn't serializing on AMD (despite it previously @@ -1081,18 +1087,18 @@ static const __initconst struct x86_cpu_ VULNWL_INTEL(ATOM_TREMONT_D, NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB), =20 /* AMD Family 0xf - 0x12 */ - VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT), - VULNWL_AMD(0x10, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT), - VULNWL_AMD(0x11, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT), - VULNWL_AMD(0x12, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT), + VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT | NO_MMIO), + VULNWL_AMD(0x10, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT | NO_MMIO), + VULNWL_AMD(0x11, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT | NO_MMIO), + VULNWL_AMD(0x12, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT | NO_MMIO), =20 /* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */ - VULNWL_AMD(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS | N= O_ITLB_MULTIHIT), - VULNWL_HYGON(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS |= NO_ITLB_MULTIHIT), + VULNWL_AMD(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS | N= O_ITLB_MULTIHIT | NO_MMIO), + VULNWL_HYGON(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS |= NO_ITLB_MULTIHIT | NO_MMIO), =20 /* Zhaoxin Family 7 */ - VULNWL(CENTAUR, 7, X86_MODEL_ANY, NO_SPECTRE_V2), - VULNWL(ZHAOXIN, 7, X86_MODEL_ANY, NO_SPECTRE_V2), + VULNWL(CENTAUR, 7, X86_MODEL_ANY, NO_SPECTRE_V2 | NO_MMIO), + VULNWL(ZHAOXIN, 7, X86_MODEL_ANY, NO_SPECTRE_V2 | NO_MMIO), {} }; =20 @@ -1234,10 +1240,16 @@ static void __init cpu_set_bug_bits(stru * Affected CPU list is generally enough to enumerate the vulnerability, * but for virtualization case check for ARCH_CAP MSR bits also, VMM may * not want the guest to enumerate the bug. + * + * Set X86_BUG_MMIO_UNKNOWN for CPUs that are neither in the blacklist, + * nor in the whitelist and also don't enumerate MSR ARCH_CAP MMIO bits. */ - if (cpu_matches(cpu_vuln_blacklist, MMIO) && - !arch_cap_mmio_immune(ia32_cap)) - setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA); + if (!arch_cap_mmio_immune(ia32_cap)) { + if (cpu_matches(cpu_vuln_blacklist, MMIO)) + setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA); + else if (!cpu_matches(cpu_vuln_whitelist, NO_MMIO)) + setup_force_cpu_bug(X86_BUG_MMIO_UNKNOWN); + } =20 if (cpu_has(c, X86_FEATURE_IBRS_ENHANCED) && !cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) && From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A25FECAAD5 for ; Fri, 2 Sep 2022 13:40:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236723AbiIBNkx (ORCPT ); Fri, 2 Sep 2022 09:40:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236490AbiIBNkO (ORCPT ); Fri, 2 Sep 2022 09:40:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E460CF8F6B; Fri, 2 Sep 2022 06:17:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8EFED6218F; Fri, 2 Sep 2022 12:29:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D58EC433D6; Fri, 2 Sep 2022 12:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121751; bh=eD8hPXiqhltoVaonaNs7OuOm9CRuggKzV8BzNUVDAgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JY6oaeTaHlikcg3UQFCsRHSJ9dDQgzUjPVKXFdF4QdD9CYKrFc9sz8+GktbQ2sW6x Rbalq9gcWiHC0yfBZ9TQtihk6yjS2PYGzo3OZqzTC9BEVXjXwJnM+rSIM8lRfw4eES G1fN9wYnZEetjFYsNMb/LEGMe70lHF3Nob6lbVks= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jing Leng , Masahiro Yamada , Nicolas Schier Subject: [PATCH 5.4 52/77] kbuild: Fix include path in scripts/Makefile.modpost Date: Fri, 2 Sep 2022 14:19:01 +0200 Message-Id: <20220902121405.386283923@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jing Leng commit 23a0cb8e3225122496bfa79172005c587c2d64bf upstream. When building an external module, if users don't need to separate the compilation output and source code, they run the following command: "make -C $(LINUX_SRC_DIR) M=3D$(PWD)". At this point, "$(KBUILD_EXTMOD)" and "$(src)" are the same. If they need to separate them, they run "make -C $(KERNEL_SRC_DIR) O=3D$(KERNEL_OUT_DIR) M=3D$(OUT_DIR) src=3D$(PWD)". Before running the command, they need to copy "Kbuild" or "Makefile" to "$(OUT_DIR)" to prevent compilation failure. So the kernel should change the included path to avoid the copy operation. Signed-off-by: Jing Leng [masahiro: I do not think "M=3D$(OUT_DIR) src=3D$(PWD)" is the official way, but this patch is a nice clean up anyway.] Signed-off-by: Masahiro Yamada [nsc: updated context for v4.19] Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- scripts/Makefile.modpost | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/scripts/Makefile.modpost +++ b/scripts/Makefile.modpost @@ -75,8 +75,7 @@ obj :=3D $(KBUILD_EXTMOD) src :=3D $(obj) =20 # Include the module's Makefile to find KBUILD_EXTRA_SYMBOLS -include $(if $(wildcard $(KBUILD_EXTMOD)/Kbuild), \ - $(KBUILD_EXTMOD)/Kbuild, $(KBUILD_EXTMOD)/Makefile) +include $(if $(wildcard $(src)/Kbuild), $(src)/Kbuild, $(src)/Makefile) endif =20 MODPOST +=3D $(subst -i,-n,$(filter -i,$(MAKEFLAGS))) -s -T - $(wildcard v= mlinux) From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F1EAC38145 for ; Fri, 2 Sep 2022 12:52:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237949AbiIBMwn (ORCPT ); Fri, 2 Sep 2022 08:52:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237792AbiIBMvn (ORCPT ); Fri, 2 Sep 2022 08:51:43 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB918E340E; Fri, 2 Sep 2022 05:37:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C074F6211D; Fri, 2 Sep 2022 12:29:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B770DC433C1; Fri, 2 Sep 2022 12:29:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121754; bh=mHzs6d5hxU1i6+1Mo1KuGNkiU33DBxG/VTXMU/Qg5zw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LtG509XWJPdOKuWPczs28bXumTt83PlwTGHtTgMS5SK+ha3Hvt91lFj3EXz7pqluJ I8uquRWBDBraAeNSSW4zziFE5JTAqKgyvnssehWLiE0XoD9ler9GjvCndz4nCklnnt PqBFNs759PlkrOCEroRxLUwr5WCt9iyCDaQm74WY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Luiz Augusto von Dentz , Sudip Mukherjee Subject: [PATCH 5.4 53/77] Bluetooth: L2CAP: Fix build errors in some archs Date: Fri, 2 Sep 2022 14:19:02 +0200 Message-Id: <20220902121405.425755290@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz commit b840304fb46cdf7012722f456bce06f151b3e81b upstream. This attempts to fix the follow errors: In function 'memcmp', inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9, inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15: ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=3Dstringop-overread] 44 | #define __underlying_memcmp __builtin_memcmp | ^ ./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp' 420 | return __underlying_memcmp(p, q, size); | ^~~~~~~~~~~~~~~~~~~ In function 'memcmp', inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9, inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15: ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=3Dstringop-overread] 44 | #define __underlying_memcmp __builtin_memcmp | ^ ./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp' 420 | return __underlying_memcmp(p, q, size); | ^~~~~~~~~~~~~~~~~~~ Fixes: 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regres= sion") Signed-off-by: Luiz Augusto von Dentz Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/bluetooth/l2cap_core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -1835,11 +1835,11 @@ static struct l2cap_chan *l2cap_global_c src_match =3D !bacmp(&c->src, src); dst_match =3D !bacmp(&c->dst, dst); if (src_match && dst_match) { - c =3D l2cap_chan_hold_unless_zero(c); - if (c) { - read_unlock(&chan_list_lock); - return c; - } + if (!l2cap_chan_hold_unless_zero(c)) + continue; + + read_unlock(&chan_list_lock); + return c; } =20 /* Closest match */ From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12707C38145 for ; Fri, 2 Sep 2022 12:37:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237043AbiIBMhU (ORCPT ); Fri, 2 Sep 2022 08:37:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236502AbiIBMgi (ORCPT ); Fri, 2 Sep 2022 08:36:38 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A84C1E42C7; Fri, 2 Sep 2022 05:29:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AB718B82A9B; Fri, 2 Sep 2022 12:29:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2AE2C433B5; Fri, 2 Sep 2022 12:29:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121757; bh=Bs2CQBsnUjpIZ+XxHHFSiRhfkB928kkGSKMck2e8gws=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K3j3IgD1kKVWm2WE1xMlpJp7t/UoCnTyVE3LyLmUtYIImTcovHGhQKRWAFFKze3Jl PQ3qrbKeUGVelThdnauWqVr7EDhsheRiASKpDjCFZucGhP2n5LOO8cgqA9SqDheazO 9TZVPmQu2N60ADZdJOfXPLFBM+H913ssFSuLtZMU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Lee Jones , Jiri Kosina Subject: [PATCH 5.4 54/77] HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report Date: Fri, 2 Sep 2022 14:19:03 +0200 Message-Id: <20220902121405.472911966@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Lee Jones commit cd11d1a6114bd4bc6450ae59f6e110ec47362126 upstream. It is possible for a malicious device to forgo submitting a Feature Report. The HID Steam driver presently makes no prevision for this and de-references the 'struct hid_report' pointer obtained from the HID devices without first checking its validity. Let's change that. Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Fixes: c164d6abf3841 ("HID: add driver for Valve Steam Controller") Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hid/hid-steam.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/hid/hid-steam.c +++ b/drivers/hid/hid-steam.c @@ -134,6 +134,11 @@ static int steam_recv_report(struct stea int ret; =20 r =3D steam->hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0]; + if (!r) { + hid_err(steam->hdev, "No HID_FEATURE_REPORT submitted - nothing to read= \n"); + return -EINVAL; + } + if (hid_report_len(r) < 64) return -EINVAL; =20 @@ -165,6 +170,11 @@ static int steam_send_report(struct stea int ret; =20 r =3D steam->hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0]; + if (!r) { + hid_err(steam->hdev, "No HID_FEATURE_REPORT submitted - nothing to read= \n"); + return -EINVAL; + } + if (hid_report_len(r) < 64) return -EINVAL; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33056ECAAD5 for ; Fri, 2 Sep 2022 13:30:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237067AbiIBNaG (ORCPT ); Fri, 2 Sep 2022 09:30:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237050AbiIBN3k (ORCPT ); Fri, 2 Sep 2022 09:29:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 445F8A8CC3; Fri, 2 Sep 2022 06:08:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BC32D62193; Fri, 2 Sep 2022 12:30:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9A13C433D7; Fri, 2 Sep 2022 12:30:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121851; bh=FPoyrBdRQibOZ+hIZy1TDUbafagBBcvlydMp5oRLLEY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FcTiwUiSolWYb7iFoO5ROwkOna6c/nGGyLwFNAEFWaOIIcib5s/3qvojGp0XRGI2i sc1UJfiU3CdiBx76crbrnUmm6MuuqaoKcTuo7pEo4PcDEiP0WMpn/kGTyg8KUjYWIT 99jszdnmQwztAyeZUghVHfwDxZcdNAXfRZnJl7No= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com, Gerd Hoffmann , Vivek Kasireddy Subject: [PATCH 5.4 55/77] udmabuf: Set the DMA mask for the udmabuf device (v2) Date: Fri, 2 Sep 2022 14:19:04 +0200 Message-Id: <20220902121405.506732199@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vivek Kasireddy commit 9e9fa6a9198b767b00f48160800128e83a038f9f upstream. If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com Cc: Gerd Hoffmann Signed-off-by: Vivek Kasireddy Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1= -vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -287,7 +287,23 @@ static struct miscdevice udmabuf_misc =3D =20 static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret =3D misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret =3D dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } =20 static void __exit udmabuf_dev_exit(void) From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA8C4ECAAD5 for ; Fri, 2 Sep 2022 12:39:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236234AbiIBMj4 (ORCPT ); Fri, 2 Sep 2022 08:39:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237053AbiIBMiM (ORCPT ); Fri, 2 Sep 2022 08:38:12 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27B83B33; Fri, 2 Sep 2022 05:29:44 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 34084B82A9D; Fri, 2 Sep 2022 12:29:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67E5DC433D6; Fri, 2 Sep 2022 12:29:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121782; bh=GYn0TkjAII05z9pCYcIRoOHlN6MT+QAzlIGZeA4VpQE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x4ujdBviWpoho88IUaNa6EDko6JlN07Yygk5NWzS8ZxENdZXRpyL+OcBpemKDyM9j o3wfFd1VSWQ4dbrCt1vfluNNjjyqhJn8WGUPGtQT+4BZnQpG1Ti0kg/Qni0g+DxJ41 0PU/qp9nmtqo7aufypa8LxGeQd4wX1/t0fo4mvac= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com, Dongliang Mu , Hans Verkuil , Mauro Carvalho Chehab Subject: [PATCH 5.4 56/77] media: pvrusb2: fix memory leak in pvr_probe Date: Fri, 2 Sep 2022 14:19:05 +0200 Message-Id: <20220902121405.543478779@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dongliang Mu commit 945a9a8e448b65bec055d37eba58f711b39f66f0 upstream. The error handling code in pvr2_hdw_create forgets to unregister the v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create, it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL, which leads to that pvr2_hdw_destroy directly returns. Fix this by adding v4l2_device_unregister to decrease the refcount of usb interface. Reported-by: syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c @@ -2611,6 +2611,7 @@ struct pvr2_hdw *pvr2_hdw_create(struct del_timer_sync(&hdw->encoder_run_timer); del_timer_sync(&hdw->encoder_wait_timer); flush_work(&hdw->workpoll); + v4l2_device_unregister(&hdw->v4l2_dev); usb_free_urb(hdw->ctl_read_urb); usb_free_urb(hdw->ctl_write_urb); kfree(hdw->ctl_read_buffer); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3822AC6FA85 for ; Fri, 2 Sep 2022 12:44:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237380AbiIBMoh (ORCPT ); Fri, 2 Sep 2022 08:44:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237331AbiIBMms (ORCPT ); Fri, 2 Sep 2022 08:42:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BFBFE01C1; Fri, 2 Sep 2022 05:31:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6BC60B82AC8; Fri, 2 Sep 2022 12:30:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1AE8C43470; Fri, 2 Sep 2022 12:30:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121817; bh=r1vX3nIzj0NgU00yTqlhOhNlBWhKxamxJjekSzxyAww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U2Y/uN35G77ppek0E1licM/9RwC21S9XoRPFujdd5mIeobjHyrIliLgNXgQq0ULgK 8tl6kgD04vnTdz58+aK7XiB6iUqzAZSWmTIgQIJ+GY1Q19E4b4I3aj8jq/PrX9mEJG 2YSBXBU9+7dXUo7mjb85ih/5OEIykpFcl36yHni0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com, Karthik Alapati , Jiri Kosina Subject: [PATCH 5.4 57/77] HID: hidraw: fix memory leak in hidraw_release() Date: Fri, 2 Sep 2022 14:19:06 +0200 Message-Id: <20220902121405.572288469@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Karthik Alapati commit a5623a203cffe2d2b84d2f6c989d9017db1856af upstream. Free the buffered reports before deleting the list entry. BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemdup+0x23/0x50 mm/util.c:128 [] kmemdup include/linux/fortify-string.h:440 [inline] [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.= c:521 [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-c= ore.c:1992 [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.= c:2065 [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core= .c:284 [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core= /hcd.c:1670 [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/= hcd.c:1747 [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/du= mmy_hcd.c:1988 [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [] expire_timers kernel/time/timer.c:1519 [inline] [] __run_timers.part.0+0x316/0x430 kernel/time/timer.= c:1790 [] __run_timers kernel/time/timer.c:1768 [inline] [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:18= 03 [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [] invoke_softirq kernel/softirq.c:445 [inline] [] __irq_exit_rcu kernel/softirq.c:650 [inline] [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/ker= nel/apic/apic.c:1106 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86= /include/asm/idtentry.h:649 [] native_safe_halt arch/x86/include/asm/irqflags.h:5= 1 [inline] [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 = [inline] [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [= inline] [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processo= r_idle.c:554 Link: https://syzkaller.appspot.com/bug?id=3D19a04b43c75ed1092021010419b5e5= 60a8172c4f Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com Signed-off-by: Karthik Alapati Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hid/hidraw.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/hid/hidraw.c +++ b/drivers/hid/hidraw.c @@ -346,10 +346,13 @@ static int hidraw_release(struct inode * unsigned int minor =3D iminor(inode); struct hidraw_list *list =3D file->private_data; unsigned long flags; + int i; =20 mutex_lock(&minors_lock); =20 spin_lock_irqsave(&hidraw_table[minor]->list_lock, flags); + for (i =3D list->tail; i < list->head; i++) + kfree(list->buffer[i].value); list_del(&list->node); spin_unlock_irqrestore(&hidraw_table[minor]->list_lock, flags); kfree(list); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B70E6C38145 for ; Fri, 2 Sep 2022 12:59:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238357AbiIBM7p (ORCPT ); Fri, 2 Sep 2022 08:59:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238098AbiIBM63 (ORCPT ); Fri, 2 Sep 2022 08:58:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF24447B80; Fri, 2 Sep 2022 05:39:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3B22F62192; Fri, 2 Sep 2022 12:30:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37965C433D7; Fri, 2 Sep 2022 12:30:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121829; bh=4xJJOHqLzP7spsbVN3XdLsPg6PaX12EVx7PC1XKrqDs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kVxiYBWM8EJJQ2rCJ5GtNIfvE9yMUsEJG/JiwZQsGez8cvdFatFqj6dxs0fbsh+d9 1MXS2ZMqk365EgjcojosOyFnxw0XmqOLSxnjBBpSpqiuj0DP8ncSY609sGzniwDbzL rCgSC+8P+WkPbhnO4AIdSocdG8Qyr8d4MK5QgBcA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zheyu Ma , Letu Ren , Helge Deller Subject: [PATCH 5.4 58/77] fbdev: fb_pm2fb: Avoid potential divide by zero error Date: Fri, 2 Sep 2022 14:19:07 +0200 Message-Id: <20220902121405.610362813@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Letu Ren commit 19f953e7435644b81332dd632ba1b2d80b1e37af upstream. In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through `fb_set_var()` and `info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`. Along the path, `var->pixclock` won't be modified. This function checks whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below. divide error in pm2fb_check_var Call Trace: fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Reported-by: Zheyu Ma Signed-off-by: Letu Ren Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/video/fbdev/pm2fb.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/video/fbdev/pm2fb.c +++ b/drivers/video/fbdev/pm2fb.c @@ -616,6 +616,11 @@ static int pm2fb_check_var(struct fb_var return -EINVAL; } =20 + if (!var->pixclock) { + DPRINTK("pixclock is zero\n"); + return -EINVAL; + } + if (PICOS2KHZ(var->pixclock) > PM2_MAX_PIXCLOCK) { DPRINTK("pixclock too high (%ldKHz)\n", PICOS2KHZ(var->pixclock)); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07743C38145 for ; Fri, 2 Sep 2022 12:43:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237393AbiIBMnT (ORCPT ); Fri, 2 Sep 2022 08:43:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237318AbiIBMmj (ORCPT ); Fri, 2 Sep 2022 08:42:39 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E73D8E0977; Fri, 2 Sep 2022 05:32:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CC221B82A71; Fri, 2 Sep 2022 12:30:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F5C7C433C1; Fri, 2 Sep 2022 12:30:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121832; bh=CYocRxnz1Q2occNBGqNuJHPdbqfC1qOmQ5bjGwLPrzM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EDD4xuVRvPrZ9rZBRRoNumWB+xHk0AzaE8WEDhLVjGK+63MXVKQjoGBx7aUx9e8TP 7HIL81eKaVlORdNtUsHdoliYQeFwC0KO0VF/2di6s49sWtWayVeINmPWcHQ6h+deqt Eo7U6so3zsxbUBvuYD+er7vx98o/1iXJwU/K7vyg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Steven Rostedt , Yang Jihong Subject: [PATCH 5.4 59/77] ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead Date: Fri, 2 Sep 2022 14:19:08 +0200 Message-Id: <20220902121405.639095304@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Yang Jihong commit c3b0f72e805f0801f05fa2aa52011c4bfc694c44 upstream. ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is= set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled =3D 1, unregister_ftrace_function simply returns witho= ut doing anything: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function i= s not executed, // as a result, ops is still in the ftrace_ops= _list __unregister_ftrace_function ... If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference, address: 0000000000000= 10b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W = 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS = rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff = 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48= > 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a3= 31866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000= 0010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df= 18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 00000000004= 78399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 00000000000= 00008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:= 0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003= 706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000= 00400 Therefore, when ftrace_startup_enable fails, we need to rollback registrati= on process and remove ops from ftrace_ops_list. Link: https://lkml.kernel.org/r/20220818032659.56209-1-yangjihong1@huawei.c= om Suggested-by: Steven Rostedt Signed-off-by: Yang Jihong Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/trace/ftrace.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -2732,6 +2732,16 @@ int ftrace_startup(struct ftrace_ops *op =20 ftrace_startup_enable(command); =20 + /* + * If ftrace is in an undefined state, we just remove ops from list + * to prevent the NULL pointer, instead of totally rolling it back and + * free trampoline, because those actions could cause further damage. + */ + if (unlikely(ftrace_disabled)) { + __unregister_ftrace_function(ops); + return -ENODEV; + } + ops->flags &=3D ~FTRACE_OPS_FL_ADDING; =20 return 0; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E93E1C38145 for ; Fri, 2 Sep 2022 12:41:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237330AbiIBMlz (ORCPT ); Fri, 2 Sep 2022 08:41:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237397AbiIBMjc (ORCPT ); Fri, 2 Sep 2022 08:39:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5CDB7C76C; Fri, 2 Sep 2022 05:30:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 30E336212E; Fri, 2 Sep 2022 12:30:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 272C9C433D6; Fri, 2 Sep 2022 12:30:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121835; bh=PJ4n2Ynoe2lpOEHUzv4oHIsdzC957qPGEF5GuR+O/gA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kEVWENrG8KWev6UTBjEGUa5F1AGgBREDm/pXdfTPl9sTEyuCYGweE4kAFfnWdyQrn 8OO9HhLMDQ5asOL/sgZn0yzWRAPvgnsN4O+GDNSu+hw1nP/sFSE01BooHsFv5K2Jbc RXgzCN6K6DBkRrs4t4/ki/OcU1p4pcXLpRq78NAo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com, Zhengchao Shao , Stanislav Fomichev , Alexei Starovoitov Subject: [PATCH 5.4 60/77] bpf: Dont redirect packets with invalid pkt_len Date: Fri, 2 Sep 2022 14:19:09 +0200 Message-Id: <20220902121405.667104333@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhengchao Shao commit fd1894224407c484f652ad456e1ce423e89bb3eb upstream. Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. LINK: [1] https://syzkaller.appspot.com/bug?id=3D0b84da80c2917757915afa89f7= 738a9d16ec96c5 LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com Signed-off-by: Zhengchao Shao Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20220715115559.139691-1-shaozhengchao@huawe= i.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/skbuff.h | 8 ++++++++ net/bpf/test_run.c | 3 +++ net/core/dev.c | 1 + 3 files changed, 12 insertions(+) --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -2201,6 +2201,14 @@ static inline void skb_set_tail_pointer( =20 #endif /* NET_SKBUFF_DATA_USES_OFFSET */ =20 +static inline void skb_assert_len(struct sk_buff *skb) +{ +#ifdef CONFIG_DEBUG_NET + if (WARN_ONCE(!skb->len, "%s\n", __func__)) + DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false); +#endif /* CONFIG_DEBUG_NET */ +} + /* * Add data to an sk_buff */ --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -200,6 +200,9 @@ static int convert___skb_to_skb(struct s { struct qdisc_skb_cb *cb =3D (struct qdisc_skb_cb *)skb->cb; =20 + if (!skb->len) + return -EINVAL; + if (!__skb) return 0; =20 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3712,6 +3712,7 @@ static int __dev_queue_xmit(struct sk_bu bool again =3D false; =20 skb_reset_mac_header(skb); + skb_assert_len(skb); =20 if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_SCHED_TSTAMP)) __skb_tstamp_tx(skb, NULL, skb->sk, SCM_TSTAMP_SCHED); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0FE3ECAAD5 for ; Fri, 2 Sep 2022 12:42:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237241AbiIBMmC (ORCPT ); Fri, 2 Sep 2022 08:42:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237464AbiIBMjn (ORCPT ); Fri, 2 Sep 2022 08:39:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2655C6CD9; Fri, 2 Sep 2022 05:30:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C9947B82AA5; Fri, 2 Sep 2022 12:30:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34CB3C433D6; Fri, 2 Sep 2022 12:30:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121838; bh=rD9g72oViAjhyfdIc51l3u7E5wJQ9WDnZPSEBTo7VUY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KNBk2t/IO7KFuJtVaeehQfvV5CaXdyxOSK7EEY9hm5cLI77Kx26sntG5rYjvRVlfY sZOjg8Mtm8thve66hX/0b2j/X+FSxwupPWYLz0Ne6me97FiZngQBWcUWMSWG857XMT bPPu9yoDiQ+MXcXlJ1T8Z3enho6AFzYlLMC0uXgE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Michal Hocko , Vlastimil Babka , Jann Horn , Linus Torvalds Subject: [PATCH 5.4 61/77] mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse Date: Fri, 2 Sep 2022 14:19:10 +0200 Message-Id: <20220902121405.695459492@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jann Horn commit 2555283eb40df89945557273121e9393ef9b542b upstream. anon_vma->degree tracks the combined number of child anon_vmas and VMAs that use the anon_vma as their ->anon_vma. anon_vma_clone() then assumes that for any anon_vma attached to src->anon_vma_chain other than src->anon_vma, it is impossible for it to be a leaf node of the VMA tree, meaning that for such VMAs ->degree is elevated by 1 because of a child anon_vma, meaning that if ->degree equals 1 there are no VMAs that use the anon_vma as their ->anon_vma. This assumption is wrong because the ->degree optimization leads to leaf nodes being abandoned on anon_vma_clone() - an existing anon_vma is reused and no new parent-child relationship is created. So it is possible to reuse an anon_vma for one VMA while it is still tied to another VMA. This is an issue because is_mergeable_anon_vma() and its callers assume that if two VMAs have the same ->anon_vma, the list of anon_vmas attached to the VMAs is guaranteed to be the same. When this assumption is violated, vma_merge() can merge pages into a VMA that is not attached to the corresponding anon_vma, leading to dangling page->mapping pointers that will be dereferenced during rmap walks. Fix it by separately tracking the number of child anon_vmas and the number of VMAs using the anon_vma as their ->anon_vma. Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") Cc: stable@kernel.org Acked-by: Michal Hocko Acked-by: Vlastimil Babka Signed-off-by: Jann Horn Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/rmap.h | 7 +++++-- mm/rmap.c | 31 +++++++++++++++++-------------- 2 files changed, 22 insertions(+), 16 deletions(-) --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -39,12 +39,15 @@ struct anon_vma { atomic_t refcount; =20 /* - * Count of child anon_vmas and VMAs which points to this anon_vma. + * Count of child anon_vmas. Equals to the count of all anon_vmas that + * have ->parent pointing to this one, including itself. * * This counter is used for making decision about reusing anon_vma * instead of forking new one. See comments in function anon_vma_clone. */ - unsigned degree; + unsigned long num_children; + /* Count of VMAs whose ->anon_vma pointer points to this object. */ + unsigned long num_active_vmas; =20 struct anon_vma *parent; /* Parent of this anon_vma */ =20 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -83,7 +83,8 @@ static inline struct anon_vma *anon_vma_ anon_vma =3D kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL); if (anon_vma) { atomic_set(&anon_vma->refcount, 1); - anon_vma->degree =3D 1; /* Reference for first vma */ + anon_vma->num_children =3D 0; + anon_vma->num_active_vmas =3D 0; anon_vma->parent =3D anon_vma; /* * Initialise the anon_vma root to point to itself. If called @@ -191,6 +192,7 @@ int __anon_vma_prepare(struct vm_area_st anon_vma =3D anon_vma_alloc(); if (unlikely(!anon_vma)) goto out_enomem_free_avc; + anon_vma->num_children++; /* self-parent link for new root */ allocated =3D anon_vma; } =20 @@ -200,8 +202,7 @@ int __anon_vma_prepare(struct vm_area_st if (likely(!vma->anon_vma)) { vma->anon_vma =3D anon_vma; anon_vma_chain_link(vma, avc, anon_vma); - /* vma reference or self-parent link for new root */ - anon_vma->degree++; + anon_vma->num_active_vmas++; allocated =3D NULL; avc =3D NULL; } @@ -280,19 +281,19 @@ int anon_vma_clone(struct vm_area_struct anon_vma_chain_link(dst, avc, anon_vma); =20 /* - * Reuse existing anon_vma if its degree lower than two, - * that means it has no vma and only one anon_vma child. + * Reuse existing anon_vma if it has no vma and only one + * anon_vma child. * - * Do not chose parent anon_vma, otherwise first child - * will always reuse it. Root anon_vma is never reused: + * Root anon_vma is never reused: * it has self-parent reference and at least one child. */ - if (!dst->anon_vma && anon_vma !=3D src->anon_vma && - anon_vma->degree < 2) + if (!dst->anon_vma && + anon_vma->num_children < 2 && + anon_vma->num_active_vmas =3D=3D 0) dst->anon_vma =3D anon_vma; } if (dst->anon_vma) - dst->anon_vma->degree++; + dst->anon_vma->num_active_vmas++; unlock_anon_vma_root(root); return 0; =20 @@ -342,6 +343,7 @@ int anon_vma_fork(struct vm_area_struct anon_vma =3D anon_vma_alloc(); if (!anon_vma) goto out_error; + anon_vma->num_active_vmas++; avc =3D anon_vma_chain_alloc(GFP_KERNEL); if (!avc) goto out_error_free_anon_vma; @@ -362,7 +364,7 @@ int anon_vma_fork(struct vm_area_struct vma->anon_vma =3D anon_vma; anon_vma_lock_write(anon_vma); anon_vma_chain_link(vma, avc, anon_vma); - anon_vma->parent->degree++; + anon_vma->parent->num_children++; anon_vma_unlock_write(anon_vma); =20 return 0; @@ -394,7 +396,7 @@ void unlink_anon_vmas(struct vm_area_str * to free them outside the lock. */ if (RB_EMPTY_ROOT(&anon_vma->rb_root.rb_root)) { - anon_vma->parent->degree--; + anon_vma->parent->num_children--; continue; } =20 @@ -402,7 +404,7 @@ void unlink_anon_vmas(struct vm_area_str anon_vma_chain_free(avc); } if (vma->anon_vma) - vma->anon_vma->degree--; + vma->anon_vma->num_active_vmas--; unlock_anon_vma_root(root); =20 /* @@ -413,7 +415,8 @@ void unlink_anon_vmas(struct vm_area_str list_for_each_entry_safe(avc, next, &vma->anon_vma_chain, same_vma) { struct anon_vma *anon_vma =3D avc->anon_vma; =20 - VM_WARN_ON(anon_vma->degree); + VM_WARN_ON(anon_vma->num_children); + VM_WARN_ON(anon_vma->num_active_vmas); put_anon_vma(anon_vma); =20 list_del(&avc->same_vma); From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 992ADECAAD5 for ; Fri, 2 Sep 2022 12:45:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237491AbiIBMpH (ORCPT ); Fri, 2 Sep 2022 08:45:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237359AbiIBMnT (ORCPT ); Fri, 2 Sep 2022 08:43:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B41AE115C; Fri, 2 Sep 2022 05:32:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6DCAC6217A; Fri, 2 Sep 2022 12:30:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63484C433C1; Fri, 2 Sep 2022 12:30:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121841; bh=/pLes/ZYaRkDgTtjtjwyJmOWv8M+asLRXrofEb6ZSho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A5rXAc+t1QBZ990Rm0ysxHFCYO3/xoIikMRhAtPjTLpA669fa0IexP+GP7xplRsYg e9vIAmwimEtcNEvvFq1H5vlC77Ce0kt/4Ajwv6Zh6VQOvCoBzpKBQ0LruJ33k+uD5v 0o9389YP5LC5oUMV1oscUGZOJOYfz/cwa3Cd3oys= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marcos Paulo de Souza , David Sterba , Sasha Levin Subject: [PATCH 5.4 62/77] btrfs: introduce btrfs_lookup_match_dir Date: Fri, 2 Sep 2022 14:19:11 +0200 Message-Id: <20220902121405.741653606@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Marcos Paulo de Souza [ Upstream commit a7d1c5dc8632e9b370ad26478c468d4e4e29f263 ] btrfs_search_slot is called in multiple places in dir-item.c to search for a dir entry, and then calling btrfs_match_dir_name to return a btrfs_dir_item. In order to reduce the number of callers of btrfs_search_slot, create a common function that looks for the dir key, and if found call btrfs_match_dir_item_name. Signed-off-by: Marcos Paulo de Souza Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/dir-item.c | 76 +++++++++++++++++++++++---------------------- 1 file changed, 39 insertions(+), 37 deletions(-) diff --git a/fs/btrfs/dir-item.c b/fs/btrfs/dir-item.c index 863367c2c6205..1c0a7cd6b9b0a 100644 --- a/fs/btrfs/dir-item.c +++ b/fs/btrfs/dir-item.c @@ -171,6 +171,25 @@ int btrfs_insert_dir_item(struct btrfs_trans_handle *t= rans, const char *name, return 0; } =20 +static struct btrfs_dir_item *btrfs_lookup_match_dir( + struct btrfs_trans_handle *trans, + struct btrfs_root *root, struct btrfs_path *path, + struct btrfs_key *key, const char *name, + int name_len, int mod) +{ + const int ins_len =3D (mod < 0 ? -1 : 0); + const int cow =3D (mod !=3D 0); + int ret; + + ret =3D btrfs_search_slot(trans, root, key, path, ins_len, cow); + if (ret < 0) + return ERR_PTR(ret); + if (ret > 0) + return ERR_PTR(-ENOENT); + + return btrfs_match_dir_item_name(root->fs_info, path, name, name_len); +} + /* * lookup a directory item based on name. 'dir' is the objectid * we're searching in, and 'mod' tells us if you plan on deleting the @@ -182,23 +201,18 @@ struct btrfs_dir_item *btrfs_lookup_dir_item(struct b= trfs_trans_handle *trans, const char *name, int name_len, int mod) { - int ret; struct btrfs_key key; - int ins_len =3D mod < 0 ? -1 : 0; - int cow =3D mod !=3D 0; + struct btrfs_dir_item *di; =20 key.objectid =3D dir; key.type =3D BTRFS_DIR_ITEM_KEY; - key.offset =3D btrfs_name_hash(name, name_len); =20 - ret =3D btrfs_search_slot(trans, root, &key, path, ins_len, cow); - if (ret < 0) - return ERR_PTR(ret); - if (ret > 0) + di =3D btrfs_lookup_match_dir(trans, root, path, &key, name, name_len, mo= d); + if (IS_ERR(di) && PTR_ERR(di) =3D=3D -ENOENT) return NULL; =20 - return btrfs_match_dir_item_name(root->fs_info, path, name, name_len); + return di; } =20 int btrfs_check_dir_item_collision(struct btrfs_root *root, u64 dir, @@ -212,7 +226,6 @@ int btrfs_check_dir_item_collision(struct btrfs_root *r= oot, u64 dir, int slot; struct btrfs_path *path; =20 - path =3D btrfs_alloc_path(); if (!path) return -ENOMEM; @@ -221,20 +234,20 @@ int btrfs_check_dir_item_collision(struct btrfs_root = *root, u64 dir, key.type =3D BTRFS_DIR_ITEM_KEY; key.offset =3D btrfs_name_hash(name, name_len); =20 - ret =3D btrfs_search_slot(NULL, root, &key, path, 0, 0); - - /* return back any errors */ - if (ret < 0) - goto out; + di =3D btrfs_lookup_match_dir(NULL, root, path, &key, name, name_len, 0); + if (IS_ERR(di)) { + ret =3D PTR_ERR(di); + /* Nothing found, we're safe */ + if (ret =3D=3D -ENOENT) { + ret =3D 0; + goto out; + } =20 - /* nothing found, we're safe */ - if (ret > 0) { - ret =3D 0; - goto out; + if (ret < 0) + goto out; } =20 /* we found an item, look for our name in the item */ - di =3D btrfs_match_dir_item_name(root->fs_info, path, name, name_len); if (di) { /* our exact name was found */ ret =3D -EEXIST; @@ -275,21 +288,13 @@ btrfs_lookup_dir_index_item(struct btrfs_trans_handle= *trans, u64 objectid, const char *name, int name_len, int mod) { - int ret; struct btrfs_key key; - int ins_len =3D mod < 0 ? -1 : 0; - int cow =3D mod !=3D 0; =20 key.objectid =3D dir; key.type =3D BTRFS_DIR_INDEX_KEY; key.offset =3D objectid; =20 - ret =3D btrfs_search_slot(trans, root, &key, path, ins_len, cow); - if (ret < 0) - return ERR_PTR(ret); - if (ret > 0) - return ERR_PTR(-ENOENT); - return btrfs_match_dir_item_name(root->fs_info, path, name, name_len); + return btrfs_lookup_match_dir(trans, root, path, &key, name, name_len, mo= d); } =20 struct btrfs_dir_item * @@ -346,21 +351,18 @@ struct btrfs_dir_item *btrfs_lookup_xattr(struct btrf= s_trans_handle *trans, const char *name, u16 name_len, int mod) { - int ret; struct btrfs_key key; - int ins_len =3D mod < 0 ? -1 : 0; - int cow =3D mod !=3D 0; + struct btrfs_dir_item *di; =20 key.objectid =3D dir; key.type =3D BTRFS_XATTR_ITEM_KEY; key.offset =3D btrfs_name_hash(name, name_len); - ret =3D btrfs_search_slot(trans, root, &key, path, ins_len, cow); - if (ret < 0) - return ERR_PTR(ret); - if (ret > 0) + + di =3D btrfs_lookup_match_dir(trans, root, path, &key, name, name_len, mo= d); + if (IS_ERR(di) && PTR_ERR(di) =3D=3D -ENOENT) return NULL; =20 - return btrfs_match_dir_item_name(root->fs_info, path, name, name_len); + return di; } =20 /* --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3044DECAAD5 for ; Fri, 2 Sep 2022 12:46:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237498AbiIBMq1 (ORCPT ); Fri, 2 Sep 2022 08:46:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237518AbiIBMnx (ORCPT ); Fri, 2 Sep 2022 08:43:53 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 931A1EC4EF; Fri, 2 Sep 2022 05:32:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 84DB6B82AA0; Fri, 2 Sep 2022 12:30:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D895C433D6; Fri, 2 Sep 2022 12:30:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121845; bh=3zvCWS6sOwZGE2ccYnr97ZJIx0tpowQ+AOrzJspelSE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Rytm21RkNFQeK4pyCkFaHhrtyzGQNrQkVoDqNcI2cqV+rzAMbuwxXIr8gcVj/EZjq ftGg56r3t+9PtT5nfTU5L2H78opto5rgo/QXpdQLn15xI0+mqGijtBOyn1AKj4SwWL DrgQCxLCjPIC0YIdrjwW59DIlib45bIX2LqvZrzg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba , Sasha Levin Subject: [PATCH 5.4 63/77] btrfs: do not pin logs too early during renames Date: Fri, 2 Sep 2022 14:19:12 +0200 Message-Id: <20220902121405.775494630@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Filipe Manana [ Upstream commit bd54f381a12ac695593271a663d36d14220215b2 ] During renames we pin the logs of the roots a bit too early, before the calls to btrfs_insert_inode_ref(). We can pin the logs after those calls, since those will not change anything in a log tree. In a scenario where we have multiple and diverse filesystem operations running in parallel, those calls can take a significant amount of time, due to lock contention on extent buffers, and delay log commits from other tasks for longer than necessary. So just pin logs after calls to btrfs_insert_inode_ref() and right before the first operation that can update a log tree. The following script that uses dbench was used for testing: $ cat dbench-test.sh #!/bin/bash DEV=3D/dev/nvme0n1 MNT=3D/mnt/nvme0n1 MOUNT_OPTIONS=3D"-o ssd" MKFS_OPTIONS=3D"-m single -d single" echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_gov= ernor umount $DEV &> /dev/null mkfs.btrfs -f $MKFS_OPTIONS $DEV mount $MOUNT_OPTIONS $DEV $MNT dbench -D $MNT -t 120 16 umount $MNT The tests were run on a machine with 12 cores, 64G of RAN, a NVMe device and using a non-debug kernel config (Debian's default config). The results compare a branch without this patch and without the previous patch in the series, that has the subject: "btrfs: eliminate some false positives when checking if inode was logged" Versus the same branch with these two patches applied. dbench with 8 clients, results before: Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 4391359 0.009 249.745 Close 3225882 0.001 3.243 Rename 185953 0.065 240.643 Unlink 886669 0.049 249.906 Deltree 112 2.455 217.433 Mkdir 56 0.002 0.004 Qpathinfo 3980281 0.004 3.109 Qfileinfo 697579 0.001 0.187 Qfsinfo 729780 0.002 2.424 Sfileinfo 357764 0.004 1.415 Find 1538861 0.016 4.863 WriteX 2189666 0.010 3.327 ReadX 6883443 0.002 0.729 LockX 14298 0.002 0.073 UnlockX 14298 0.001 0.042 Flush 307777 2.447 303.663 Throughput 1149.6 MB/sec 8 clients 8 procs max_latency=3D303.666 ms dbench with 8 clients, results after: Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 4269920 0.009 213.532 Close 3136653 0.001 0.690 Rename 180805 0.082 213.858 Unlink 862189 0.050 172.893 Deltree 112 2.998 218.328 Mkdir 56 0.002 0.003 Qpathinfo 3870158 0.004 5.072 Qfileinfo 678375 0.001 0.194 Qfsinfo 709604 0.002 0.485 Sfileinfo 347850 0.004 1.304 Find 1496310 0.017 5.504 WriteX 2129613 0.010 2.882 ReadX 6693066 0.002 1.517 LockX 13902 0.002 0.075 UnlockX 13902 0.001 0.055 Flush 299276 2.511 220.189 Throughput 1187.33 MB/sec 8 clients 8 procs max_latency=3D220.194 ms +3.2% throughput, -31.8% max latency dbench with 16 clients, results before: Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 5978334 0.028 156.507 Close 4391598 0.001 1.345 Rename 253136 0.241 155.057 Unlink 1207220 0.182 257.344 Deltree 160 6.123 36.277 Mkdir 80 0.003 0.005 Qpathinfo 5418817 0.012 6.867 Qfileinfo 949929 0.001 0.941 Qfsinfo 993560 0.002 1.386 Sfileinfo 486904 0.004 2.829 Find 2095088 0.059 8.164 WriteX 2982319 0.017 9.029 ReadX 9371484 0.002 4.052 LockX 19470 0.002 0.461 UnlockX 19470 0.001 0.990 Flush 418936 2.740 347.902 Throughput 1495.31 MB/sec 16 clients 16 procs max_latency=3D347.909 ms dbench with 16 clients, results after: Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 5711833 0.029 131.240 Close 4195897 0.001 1.732 Rename 241849 0.204 147.831 Unlink 1153341 0.184 231.322 Deltree 160 6.086 30.198 Mkdir 80 0.003 0.021 Qpathinfo 5177011 0.012 7.150 Qfileinfo 907768 0.001 0.793 Qfsinfo 949205 0.002 1.431 Sfileinfo 465317 0.004 2.454 Find 2001541 0.058 7.819 WriteX 2850661 0.017 9.110 ReadX 8952289 0.002 3.991 LockX 18596 0.002 0.655 UnlockX 18596 0.001 0.179 Flush 400342 2.879 293.607 Throughput 1565.73 MB/sec 16 clients 16 procs max_latency=3D293.611 ms +4.6% throughput, -16.9% max latency Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/inode.c | 48 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 42 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 7755a0362a3ad..20c5db8ef8427 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9751,8 +9751,6 @@ static int btrfs_rename_exchange(struct inode *old_di= r, /* force full log commit if subvolume involved. */ btrfs_set_log_full_commit(trans); } else { - btrfs_pin_log_trans(root); - root_log_pinned =3D true; ret =3D btrfs_insert_inode_ref(trans, dest, new_dentry->d_name.name, new_dentry->d_name.len, @@ -9768,8 +9766,6 @@ static int btrfs_rename_exchange(struct inode *old_di= r, /* force full log commit if subvolume involved. */ btrfs_set_log_full_commit(trans); } else { - btrfs_pin_log_trans(dest); - dest_log_pinned =3D true; ret =3D btrfs_insert_inode_ref(trans, root, old_dentry->d_name.name, old_dentry->d_name.len, @@ -9797,6 +9793,29 @@ static int btrfs_rename_exchange(struct inode *old_d= ir, BTRFS_I(new_inode), 1); } =20 + /* + * Now pin the logs of the roots. We do it to ensure that no other task + * can sync the logs while we are in progress with the rename, because + * that could result in an inconsistency in case any of the inodes that + * are part of this rename operation were logged before. + * + * We pin the logs even if at this precise moment none of the inodes was + * logged before. This is because right after we checked for that, some + * other task fsyncing some other inode not involved with this rename + * operation could log that one of our inodes exists. + * + * We don't need to pin the logs before the above calls to + * btrfs_insert_inode_ref(), since those don't ever need to change a log. + */ + if (old_ino !=3D BTRFS_FIRST_FREE_OBJECTID) { + btrfs_pin_log_trans(root); + root_log_pinned =3D true; + } + if (new_ino !=3D BTRFS_FIRST_FREE_OBJECTID) { + btrfs_pin_log_trans(dest); + dest_log_pinned =3D true; + } + /* src is a subvolume */ if (old_ino =3D=3D BTRFS_FIRST_FREE_OBJECTID) { ret =3D btrfs_unlink_subvol(trans, old_dir, old_dentry); @@ -10046,8 +10065,6 @@ static int btrfs_rename(struct inode *old_dir, stru= ct dentry *old_dentry, /* force full log commit if subvolume involved. */ btrfs_set_log_full_commit(trans); } else { - btrfs_pin_log_trans(root); - log_pinned =3D true; ret =3D btrfs_insert_inode_ref(trans, dest, new_dentry->d_name.name, new_dentry->d_name.len, @@ -10071,6 +10088,25 @@ static int btrfs_rename(struct inode *old_dir, str= uct dentry *old_dentry, if (unlikely(old_ino =3D=3D BTRFS_FIRST_FREE_OBJECTID)) { ret =3D btrfs_unlink_subvol(trans, old_dir, old_dentry); } else { + /* + * Now pin the log. We do it to ensure that no other task can + * sync the log while we are in progress with the rename, as + * that could result in an inconsistency in case any of the + * inodes that are part of this rename operation were logged + * before. + * + * We pin the log even if at this precise moment none of the + * inodes was logged before. This is because right after we + * checked for that, some other task fsyncing some other inode + * not involved with this rename operation could log that one of + * our inodes exists. + * + * We don't need to pin the logs before the above call to + * btrfs_insert_inode_ref(), since that does not need to change + * a log. + */ + btrfs_pin_log_trans(root); + log_pinned =3D true; ret =3D __btrfs_unlink_inode(trans, root, BTRFS_I(old_dir), BTRFS_I(d_inode(old_dentry)), old_dentry->d_name.name, --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 438E9ECAAD5 for ; Fri, 2 Sep 2022 12:41:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237008AbiIBMll (ORCPT ); Fri, 2 Sep 2022 08:41:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237378AbiIBMj2 (ORCPT ); Fri, 2 Sep 2022 08:39:28 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D94D7C46; Fri, 2 Sep 2022 05:30:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4D387B82AA7; Fri, 2 Sep 2022 12:30:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7A7BC433D7; Fri, 2 Sep 2022 12:30:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121848; bh=dxxxXMPTlbcdYf3HhBHrcAH67i6aFZ1wVpRrYhiAmF0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r48RLpYulOqwmDb+h5b1DGMG20vaUGHRZD/9lhs6hV4qlE0QbKmxNFK4UjsEdxYnG X/aAZ152Argl7UGts0HaoJdGrY5B4VQmTkl6ITa52BxCcSv7OviQ434Dv29Mozzexv 3VeKnuleBE/4RCRisfElUcLNyG2mUoxE4ug+8iTw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba , Sasha Levin Subject: [PATCH 5.4 64/77] btrfs: unify lookup return value when dir entry is missing Date: Fri, 2 Sep 2022 14:19:13 +0200 Message-Id: <20220902121405.804936802@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Filipe Manana [ Upstream commit 8dcbc26194eb872cc3430550fb70bb461424d267 ] btrfs_lookup_dir_index_item() and btrfs_lookup_dir_item() lookup for dir entries and both are used during log replay or when updating a log tree during an unlink. However when the dir item does not exists, btrfs_lookup_dir_item() returns NULL while btrfs_lookup_dir_index_item() returns PTR_ERR(-ENOENT), and if the dir item exists but there is no matching entry for a given name or index, both return NULL. This makes the call sites during log replay to be more verbose than necessary and it makes it easy to miss this slight difference. Since we don't need to distinguish between those two cases, make btrfs_lookup_dir_index_item() always return NULL when there is no matching directory entry - either because there isn't any dir entry or because there is one but it does not match the given name and index. Also rename the argument 'objectid' of btrfs_lookup_dir_index_item() to 'index' since it is supposed to match an index number, and the name 'objectid' is not very good because it can easily be confused with an inode number (like the inode number a dir entry points to). CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/ctree.h | 2 +- fs/btrfs/dir-item.c | 48 ++++++++++++++++++++++++++++++++++----------- fs/btrfs/tree-log.c | 14 ++++--------- 3 files changed, 42 insertions(+), 22 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index cd77c0621a555..c2e5fe972f566 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -2727,7 +2727,7 @@ struct btrfs_dir_item * btrfs_lookup_dir_index_item(struct btrfs_trans_handle *trans, struct btrfs_root *root, struct btrfs_path *path, u64 dir, - u64 objectid, const char *name, int name_len, + u64 index, const char *name, int name_len, int mod); struct btrfs_dir_item * btrfs_search_dir_index_item(struct btrfs_root *root, diff --git a/fs/btrfs/dir-item.c b/fs/btrfs/dir-item.c index 1c0a7cd6b9b0a..98c6faa8ce15b 100644 --- a/fs/btrfs/dir-item.c +++ b/fs/btrfs/dir-item.c @@ -191,9 +191,20 @@ static struct btrfs_dir_item *btrfs_lookup_match_dir( } =20 /* - * lookup a directory item based on name. 'dir' is the objectid - * we're searching in, and 'mod' tells us if you plan on deleting the - * item (use mod < 0) or changing the options (use mod > 0) + * Lookup for a directory item by name. + * + * @trans: The transaction handle to use. Can be NULL if @mod is 0. + * @root: The root of the target tree. + * @path: Path to use for the search. + * @dir: The inode number (objectid) of the directory. + * @name: The name associated to the directory entry we are looking for. + * @name_len: The length of the name. + * @mod: Used to indicate if the tree search is meant for a read only + * lookup, for a modification lookup or for a deletion lookup, so + * its value should be 0, 1 or -1, respectively. + * + * Returns: NULL if the dir item does not exists, an error pointer if an e= rror + * happened, or a pointer to a dir item if a dir item exists for the given= name. */ struct btrfs_dir_item *btrfs_lookup_dir_item(struct btrfs_trans_handle *tr= ans, struct btrfs_root *root, @@ -274,27 +285,42 @@ int btrfs_check_dir_item_collision(struct btrfs_root = *root, u64 dir, } =20 /* - * lookup a directory item based on index. 'dir' is the objectid - * we're searching in, and 'mod' tells us if you plan on deleting the - * item (use mod < 0) or changing the options (use mod > 0) + * Lookup for a directory index item by name and index number. * - * The name is used to make sure the index really points to the name you w= ere - * looking for. + * @trans: The transaction handle to use. Can be NULL if @mod is 0. + * @root: The root of the target tree. + * @path: Path to use for the search. + * @dir: The inode number (objectid) of the directory. + * @index: The index number. + * @name: The name associated to the directory entry we are looking for. + * @name_len: The length of the name. + * @mod: Used to indicate if the tree search is meant for a read only + * lookup, for a modification lookup or for a deletion lookup, so + * its value should be 0, 1 or -1, respectively. + * + * Returns: NULL if the dir index item does not exists, an error pointer i= f an + * error happened, or a pointer to a dir item if the dir index item exists= and + * matches the criteria (name and index number). */ struct btrfs_dir_item * btrfs_lookup_dir_index_item(struct btrfs_trans_handle *trans, struct btrfs_root *root, struct btrfs_path *path, u64 dir, - u64 objectid, const char *name, int name_len, + u64 index, const char *name, int name_len, int mod) { + struct btrfs_dir_item *di; struct btrfs_key key; =20 key.objectid =3D dir; key.type =3D BTRFS_DIR_INDEX_KEY; - key.offset =3D objectid; + key.offset =3D index; =20 - return btrfs_lookup_match_dir(trans, root, path, &key, name, name_len, mo= d); + di =3D btrfs_lookup_match_dir(trans, root, path, &key, name, name_len, mo= d); + if (di =3D=3D ERR_PTR(-ENOENT)) + return NULL; + + return di; } =20 struct btrfs_dir_item * diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index bebd74267bed6..926b1d34e55cc 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -918,8 +918,7 @@ static noinline int inode_in_dir(struct btrfs_root *roo= t, di =3D btrfs_lookup_dir_index_item(NULL, root, path, dirid, index, name, name_len, 0); if (IS_ERR(di)) { - if (PTR_ERR(di) !=3D -ENOENT) - ret =3D PTR_ERR(di); + ret =3D PTR_ERR(di); goto out; } else if (di) { btrfs_dir_item_key_to_cpu(path->nodes[0], di, &location); @@ -1171,8 +1170,7 @@ static inline int __add_inode_ref(struct btrfs_trans_= handle *trans, di =3D btrfs_lookup_dir_index_item(trans, root, path, btrfs_ino(dir), ref_index, name, namelen, 0); if (IS_ERR(di)) { - if (PTR_ERR(di) !=3D -ENOENT) - return PTR_ERR(di); + return PTR_ERR(di); } else if (di) { ret =3D drop_one_dir_item(trans, root, path, dir, di); if (ret) @@ -2022,9 +2020,6 @@ static noinline int replay_one_name(struct btrfs_tran= s_handle *trans, goto out; } =20 - if (dst_di =3D=3D ERR_PTR(-ENOENT)) - dst_di =3D NULL; - if (IS_ERR(dst_di)) { ret =3D PTR_ERR(dst_di); goto out; @@ -2309,7 +2304,7 @@ static noinline int check_item_in_log(struct btrfs_tr= ans_handle *trans, dir_key->offset, name, name_len, 0); } - if (!log_di || log_di =3D=3D ERR_PTR(-ENOENT)) { + if (!log_di) { btrfs_dir_item_key_to_cpu(eb, di, &location); btrfs_release_path(path); btrfs_release_path(log_path); @@ -3522,8 +3517,7 @@ int btrfs_del_dir_entries_in_log(struct btrfs_trans_h= andle *trans, if (err =3D=3D -ENOSPC) { btrfs_set_log_full_commit(trans); err =3D 0; - } else if (err < 0 && err !=3D -ENOENT) { - /* ENOENT can be returned if the entry hasn't been fsynced yet */ + } else if (err < 0) { btrfs_abort_transaction(trans, err); } =20 --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA066C54EE9 for ; Fri, 2 Sep 2022 12:51:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237864AbiIBMvp (ORCPT ); Fri, 2 Sep 2022 08:51:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237793AbiIBMup (ORCPT ); Fri, 2 Sep 2022 08:50:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5179F7B34; Fri, 2 Sep 2022 05:36:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 48906B82AC5; Fri, 2 Sep 2022 12:29:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89EC0C433D7; Fri, 2 Sep 2022 12:29:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121786; bh=hyX6Zt3IU6MpFRjst+F6f9W4NLmMoAVAbz38sQFz9OE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KW/LoE49bIJliGodYzvVANdym1m/RqpyWs7rrtE9dcUcoTciXKnDRfFBN6Ru9OwJJ AkqWJ5ZswRMVSPDLEcGX+LrTe0OqEaS2iJxWXvNrHNOTN96ZrQaz2/Yzl7azR6m7Ua UsbLfLwpt7yrLSVSnyCLdSP/Y7GPOG0ki9SpC/34= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josip Pavic , Jun Lei , Alex Hung , Aric Cyr , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.4 65/77] drm/amd/display: Avoid MPC infinite loop Date: Fri, 2 Sep 2022 14:19:14 +0200 Message-Id: <20220902121405.847824457@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josip Pavic [ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ] [why] In some cases MPC tree bottom pipe ends up point to itself. This causes iterating from top to bottom to hang the system in an infinite loop. [how] When looping to next MPC bottom pipe, check that the pointer is not same as current to avoid infinite loop. Reviewed-by: Josip Pavic Reviewed-by: Jun Lei Acked-by: Alex Hung Signed-off-by: Aric Cyr Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 6 ++++++ drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c b/drivers/gpu= /drm/amd/display/dc/dcn10/dcn10_mpc.c index 8b2f29f6dabd2..068e79fa3490d 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c @@ -118,6 +118,12 @@ struct mpcc *mpc1_get_mpcc_for_dpp(struct mpc_tree *tr= ee, int dpp_id) while (tmp_mpcc !=3D NULL) { if (tmp_mpcc->dpp_id =3D=3D dpp_id) return tmp_mpcc; + + /* avoid circular linked list */ + ASSERT(tmp_mpcc !=3D tmp_mpcc->mpcc_bot); + if (tmp_mpcc =3D=3D tmp_mpcc->mpcc_bot) + break; + tmp_mpcc =3D tmp_mpcc->mpcc_bot; } return NULL; diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c b/drivers/gpu= /drm/amd/display/dc/dcn20/dcn20_mpc.c index 5a188b2bc033c..0a00bd8e00abc 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c @@ -488,6 +488,12 @@ struct mpcc *mpc2_get_mpcc_for_dpp(struct mpc_tree *tr= ee, int dpp_id) while (tmp_mpcc !=3D NULL) { if (tmp_mpcc->dpp_id =3D=3D 0xf || tmp_mpcc->dpp_id =3D=3D dpp_id) return tmp_mpcc; + + /* avoid circular linked list */ + ASSERT(tmp_mpcc !=3D tmp_mpcc->mpcc_bot); + if (tmp_mpcc =3D=3D tmp_mpcc->mpcc_bot) + break; + tmp_mpcc =3D tmp_mpcc->mpcc_bot; } return NULL; --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 638F1C54EE9 for ; Fri, 2 Sep 2022 12:40:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236435AbiIBMke (ORCPT ); Fri, 2 Sep 2022 08:40:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237159AbiIBMik (ORCPT ); Fri, 2 Sep 2022 08:38:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD3543C158; Fri, 2 Sep 2022 05:30:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6AEC462199; Fri, 2 Sep 2022 12:29:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DD7BC433C1; Fri, 2 Sep 2022 12:29:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121788; bh=1Af/KZluRD62q3Ql9fAk8hIRWupKOXszYwrxm9YQVXg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=av0rmupL6z5cRMN478TMd92qCdmD2Ky9xpKnrYnpez7HVSUpAUyLhVfuuAD2gSZxK LzemsM6owWamHN9bwFqy15ZrdDT0pnlATum+HJtzOwDEGffLkcArVUt2C86BtjY2A8 j1xZkUjubis7A/tAmenltdbCb7KOI+bwnQ01ijpY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alvin Lee , Tom Chung , Fudong Wang , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.4 66/77] drm/amd/display: clear optc underflow before turn off odm clock Date: Fri, 2 Sep 2022 14:19:15 +0200 Message-Id: <20220902121405.875909156@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Fudong Wang [ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ] [Why] After ODM clock off, optc underflow bit will be kept there always and clear= not work. We need to clear that before clock off. [How] Clear that if have when clock off. Reviewed-by: Alvin Lee Acked-by: Tom Chung Signed-off-by: Fudong Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c b/drivers/gp= u/drm/amd/display/dc/dcn10/dcn10_optc.c index e74a07d03fde9..4b0200e96eb77 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c @@ -425,6 +425,11 @@ void optc1_enable_optc_clock(struct timing_generator *= optc, bool enable) OTG_CLOCK_ON, 1, 1, 1000); } else { + + //last chance to clear underflow, otherwise, it will always there due to= clock is off. + if (optc->funcs->is_optc_underflow_occurred(optc) =3D=3D true) + optc->funcs->clear_optc_underflow(optc); + REG_UPDATE_2(OTG_CLOCK_CONTROL, OTG_CLOCK_GATE_DIS, 0, OTG_CLOCK_EN, 0); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FE9AECAAD5 for ; Fri, 2 Sep 2022 12:41:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237291AbiIBMlK (ORCPT ); Fri, 2 Sep 2022 08:41:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237232AbiIBMiv (ORCPT ); Fri, 2 Sep 2022 08:38:51 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5ABEF474D6; Fri, 2 Sep 2022 05:30:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 73F4762196; Fri, 2 Sep 2022 12:29:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 497C4C433C1; Fri, 2 Sep 2022 12:29:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121791; bh=0qF/oYmMy+Nd9dHjixWzVS8ZidgujaNkK2EyJt3lh8c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x4xPb0+eomvKU9feZyFtAPKvAF9YVm5+atKcNT1bcfFLm8wY+qTRLm33gn5wsrwi8 LVz8EjjgV4C8D5udQ3FxIZAgKJ+Kd8GC5UB2jm+H41RvZ+W/PMhdEZ9moMS6TkB2NY 3h1Wtglv716SPabVE6a4oqEKp18AMqH5ZT/2XOdU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Daniel Borkmann , David Ahern , Yajun Deng , Roopa Prabhu , Christian Brauner , netdev@vger.kernel.org, Alexey Kuznetsov , Alexander Mikhalitsyn , Konstantin Khorenko , kernel@openvz.org, devel@openvz.org, "Denis V. Lunev" , Sasha Levin Subject: [PATCH 5.4 67/77] neigh: fix possible DoS due to net iface start/stop loop Date: Fri, 2 Sep 2022 14:19:16 +0200 Message-Id: <20220902121405.911113172@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Denis V. Lunev [ Upstream commit 66ba215cb51323e4e55e38fd5f250e0fae0cbc94 ] Normal processing of ARP request (usually this is Ethernet broadcast packet) coming to the host is looking like the following: * the packet comes to arp_process() call and is passed through routing procedure * the request is put into the queue using pneigh_enqueue() if corresponding ARP record is not local (common case for container records on the host) * the request is processed by timer (within 80 jiffies by default) and ARP reply is sent from the same arp_process() using NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED condition (flag is set inside pneigh_enqueue()) And here the problem comes. Linux kernel calls pneigh_queue_purge() which destroys the whole queue of ARP requests on ANY network interface start/stop event through __neigh_ifdown(). This is actually not a problem within the original world as network interface start/stop was accessible to the host 'root' only, which could do more destructive things. But the world is changed and there are Linux containers available. Here container 'root' has an access to this API and could be considered as untrusted user in the hosting (container's) world. Thus there is an attack vector to other containers on node when container's root will endlessly start/stop interfaces. We have observed similar situation on a real production node when docker container was doing such activity and thus other containers on the node become not accessible. The patch proposed doing very simple thing. It drops only packets from the same namespace in the pneigh_queue_purge() where network interface state change is detected. This is enough to prevent the problem for the whole node preserving original semantics of the code. v2: - do del_timer_sync() if queue is empty after pneigh_queue_purge() v3: - rebase to net tree Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Daniel Borkmann Cc: David Ahern Cc: Yajun Deng Cc: Roopa Prabhu Cc: Christian Brauner Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Alexey Kuznetsov Cc: Alexander Mikhalitsyn Cc: Konstantin Khorenko Cc: kernel@openvz.org Cc: devel@openvz.org Investigated-by: Alexander Mikhalitsyn Signed-off-by: Denis V. Lunev Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/neighbour.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 8b6140e67e7f8..6056b8e545658 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -280,14 +280,23 @@ static int neigh_del_timer(struct neighbour *n) return 0; } =20 -static void pneigh_queue_purge(struct sk_buff_head *list) +static void pneigh_queue_purge(struct sk_buff_head *list, struct net *net) { + unsigned long flags; struct sk_buff *skb; =20 - while ((skb =3D skb_dequeue(list)) !=3D NULL) { - dev_put(skb->dev); - kfree_skb(skb); + spin_lock_irqsave(&list->lock, flags); + skb =3D skb_peek(list); + while (skb !=3D NULL) { + struct sk_buff *skb_next =3D skb_peek_next(skb, list); + if (net =3D=3D NULL || net_eq(dev_net(skb->dev), net)) { + __skb_unlink(skb, list); + dev_put(skb->dev); + kfree_skb(skb); + } + skb =3D skb_next; } + spin_unlock_irqrestore(&list->lock, flags); } =20 static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *de= v, @@ -358,9 +367,9 @@ static int __neigh_ifdown(struct neigh_table *tbl, stru= ct net_device *dev, write_lock_bh(&tbl->lock); neigh_flush_dev(tbl, dev, skip_perm); pneigh_ifdown_and_unlock(tbl, dev); - - del_timer_sync(&tbl->proxy_timer); - pneigh_queue_purge(&tbl->proxy_queue); + pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev)); + if (skb_queue_empty_lockless(&tbl->proxy_queue)) + del_timer_sync(&tbl->proxy_timer); return 0; } =20 @@ -1741,7 +1750,7 @@ int neigh_table_clear(int index, struct neigh_table *= tbl) /* It is not clean... Fix it to unload IPv6 module safely */ cancel_delayed_work_sync(&tbl->gc_work); del_timer_sync(&tbl->proxy_timer); - pneigh_queue_purge(&tbl->proxy_queue); + pneigh_queue_purge(&tbl->proxy_queue, NULL); neigh_ifdown(tbl, NULL); if (atomic_read(&tbl->entries)) pr_crit("neighbour leakage\n"); --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3FDCECAAD5 for ; Fri, 2 Sep 2022 12:42:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237273AbiIBMmU (ORCPT ); Fri, 2 Sep 2022 08:42:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35000 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237261AbiIBMlC (ORCPT ); Fri, 2 Sep 2022 08:41:02 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1A77E725E; Fri, 2 Sep 2022 05:31:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 309A6B82A8E; Fri, 2 Sep 2022 12:29:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 834A5C433C1; Fri, 2 Sep 2022 12:29:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121795; bh=88JnIP67Dou7CqPdf10PNQ7CLyF2nEZpaadM9YCR9bs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rQB7AoxmATXv0dkdMp9Yp07eNRc6C9p31dRIwWvn1qKLj0jkTyBErMbmnvBHo565D rOQgdbiuZv/ocQbl2Vivh2O2StqAoh8AQ+1TWVdSKtxHzYEgXhmpNiENUu0zzEMpz8 Bw2AUQHB4LNdgtTHHx0kr7/n7Eobm3glocv4VTX0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Juergen Gross , Heiko Carstens , Christian Borntraeger , Alexander Gordeev , Sasha Levin Subject: [PATCH 5.4 68/77] s390/hypfs: avoid error message under KVM Date: Fri, 2 Sep 2022 14:19:17 +0200 Message-Id: <20220902121405.946095239@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juergen Gross [ Upstream commit 7b6670b03641ac308aaa6fa2e6f964ac993b5ea3 ] When booting under KVM the following error messages are issued: hypfs.7f5705: The hardware system does not support hypfs hypfs.7a79f0: Initialization of hypfs failed with rc=3D-61 Demote the severity of first message from "error" to "info" and issue the second message only in other error cases. Signed-off-by: Juergen Gross Acked-by: Heiko Carstens Acked-by: Christian Borntraeger Link: https://lore.kernel.org/r/20220620094534.18967-1-jgross@suse.com [arch/s390/hypfs/hypfs_diag.c changed description] Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/hypfs/hypfs_diag.c | 2 +- arch/s390/hypfs/inode.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/hypfs/hypfs_diag.c b/arch/s390/hypfs/hypfs_diag.c index f0bc4dc3e9bf0..6511d15ace45e 100644 --- a/arch/s390/hypfs/hypfs_diag.c +++ b/arch/s390/hypfs/hypfs_diag.c @@ -437,7 +437,7 @@ __init int hypfs_diag_init(void) int rc; =20 if (diag204_probe()) { - pr_err("The hardware system does not support hypfs\n"); + pr_info("The hardware system does not support hypfs\n"); return -ENODATA; } =20 diff --git a/arch/s390/hypfs/inode.c b/arch/s390/hypfs/inode.c index 70139d0791b61..ca4fc66a361fb 100644 --- a/arch/s390/hypfs/inode.c +++ b/arch/s390/hypfs/inode.c @@ -501,9 +501,9 @@ static int __init hypfs_init(void) hypfs_vm_exit(); fail_hypfs_diag_exit: hypfs_diag_exit(); + pr_err("Initialization of hypfs failed with rc=3D%i\n", rc); fail_dbfs_exit: hypfs_dbfs_exit(); - pr_err("Initialization of hypfs failed with rc=3D%i\n", rc); return rc; } device_initcall(hypfs_init) --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5BF1AC6FA85 for ; Fri, 2 Sep 2022 14:52:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237074AbiIBOwP (ORCPT ); Fri, 2 Sep 2022 10:52:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235679AbiIBOvq (ORCPT ); Fri, 2 Sep 2022 10:51:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65D161573D; Fri, 2 Sep 2022 07:15:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 56A7FB82A9E; Fri, 2 Sep 2022 12:29:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5D00C433D6; Fri, 2 Sep 2022 12:29:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121798; bh=8xf/FDes9qS9fA0g1u4sARgqkHAIv93ZjIbPTVdCEKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FxNI6nnapS9wZpll6iCKKopefztnGQrHVD0AkXPVMON5cPdJ2WlucSb+mKem8YUvb V/Z/TTKey+tiM16f8w1BtEim4M4uXl15oticwKlAEFxU/bo8pEs3UMiwGgdgSiPgDG Q1cuHWr3DSuymKXBR6aUijaHW4EGMYvVu38KuEfw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Aric Cyr , Brian Chang , Ilya Bakoulin , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.4 69/77] drm/amd/display: Fix pixel clock programming Date: Fri, 2 Sep 2022 14:19:18 +0200 Message-Id: <20220902121405.975130520@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ilya Bakoulin [ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ] [Why] Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned between different HDMI lanes when using YCbCr420 10-bit pixel format. BIOS functions for transmitter/encoder control take pixel clock in kHz increments, whereas the function for setting the pixel clock is in 100Hz increments. Setting pixel clock to a value that is not on a kHz boundary will cause the issue. [How] Round pixel clock down to nearest kHz in 10/12-bpc cases. Reviewed-by: Aric Cyr Acked-by: Brian Chang Signed-off-by: Ilya Bakoulin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c b/driver= s/gpu/drm/amd/display/dc/dce/dce_clock_source.c index eca67d5d5b10d..721be82ccebec 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c @@ -546,9 +546,11 @@ static void dce112_get_pix_clk_dividers_helper ( switch (pix_clk_params->color_depth) { case COLOR_DEPTH_101010: actual_pixel_clock_100hz =3D (actual_pixel_clock_100hz * 5) >> 2; + actual_pixel_clock_100hz -=3D actual_pixel_clock_100hz % 10; break; case COLOR_DEPTH_121212: actual_pixel_clock_100hz =3D (actual_pixel_clock_100hz * 6) >> 2; + actual_pixel_clock_100hz -=3D actual_pixel_clock_100hz % 10; break; case COLOR_DEPTH_161616: actual_pixel_clock_100hz =3D actual_pixel_clock_100hz * 2; --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AA98ECAAD5 for ; Fri, 2 Sep 2022 12:46:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237465AbiIBMqT (ORCPT ); Fri, 2 Sep 2022 08:46:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237498AbiIBMnr (ORCPT ); Fri, 2 Sep 2022 08:43:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94461E86BA; Fri, 2 Sep 2022 05:32:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4CE56620E1; Fri, 2 Sep 2022 12:30:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53B60C433C1; Fri, 2 Sep 2022 12:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121801; bh=h9Omd5d/MFc2Q3U8UrgU16es4Zq80YP3MfGWfzDOvkk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dRaEsTj+msdUe/LW381pD0uNMUdvTpFAfMqpmu7LNKzVLAhU4Q+Ada95zveWF6hHA rDFDDyQfdiwyFYPuoZ4BCNnddtYTjppyVo04TC1HsNVta1Hz3+JKZwqN31+QgOqbae Duj378V70XSog+/EW+ajESF61x0Spsff9HzUZmHc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Geert Uytterhoeven , Florian Westphal , Sasha Levin Subject: [PATCH 5.4 70/77] netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y Date: Fri, 2 Sep 2022 14:19:19 +0200 Message-Id: <20220902121406.003382579@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit aa5762c34213aba7a72dc58e70601370805fa794 ] NF_CONNTRACK_PROCFS was marked obsolete in commit 54b07dca68557b09 ("netfilter: provide config option to disable ancient procfs parts") in v3.3. Signed-off-by: Geert Uytterhoeven Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index ef72819d9d315..d569915da003c 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -118,7 +118,6 @@ config NF_CONNTRACK_ZONES =20 config NF_CONNTRACK_PROCFS bool "Supply CT list in procfs (OBSOLETE)" - default y depends on PROC_FS ---help--- This option enables for the list of known conntrack entries --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA5FAC38145 for ; Fri, 2 Sep 2022 12:41:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237297AbiIBMlO (ORCPT ); Fri, 2 Sep 2022 08:41:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237246AbiIBMix (ORCPT ); Fri, 2 Sep 2022 08:38:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7872B52E73; Fri, 2 Sep 2022 05:30:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 759FC620DD; Fri, 2 Sep 2022 12:30:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 838F8C433C1; Fri, 2 Sep 2022 12:30:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121804; bh=WElrGm0ivZCuPHTPNPzioR0z3KnhJG8+yewOgMjfT0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kRZybh5D8+oJSJzXJ7cyg086lyGqiQpSzwnG5Pk+MBZ+MVHOwUqRpcSLB9KPy7pSS +I9959QDDsi8h4z/QM99cBcjGVnSvIIbNGdHG65uR/iRjoYIKN5MuaXhJhcSifJDYU VVd4lb24YsXyXqO5lKBhL+Cgz2SLCENJ2fT0JSP0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qu Wenruo , Josef Bacik , David Sterba , Sasha Levin Subject: [PATCH 5.4 71/77] btrfs: tree-checker: check for overlapping extent items Date: Fri, 2 Sep 2022 14:19:20 +0200 Message-Id: <20220902121406.042078995@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josef Bacik [ Upstream commit 899b7f69f244e539ea5df1b4d756046337de44a5 ] We're seeing a weird problem in production where we have overlapping extent items in the extent tree. It's unclear where these are coming from, and in debugging we realized there's no check in the tree checker for this sort of problem. Add a check to the tree-checker to make sure that the extents do not overlap each other. Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/tree-checker.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c index 368c43c6cbd08..d15de5abb562d 100644 --- a/fs/btrfs/tree-checker.c +++ b/fs/btrfs/tree-checker.c @@ -1019,7 +1019,8 @@ static void extent_err(const struct extent_buffer *eb= , int slot, } =20 static int check_extent_item(struct extent_buffer *leaf, - struct btrfs_key *key, int slot) + struct btrfs_key *key, int slot, + struct btrfs_key *prev_key) { struct btrfs_fs_info *fs_info =3D leaf->fs_info; struct btrfs_extent_item *ei; @@ -1230,6 +1231,26 @@ static int check_extent_item(struct extent_buffer *l= eaf, total_refs, inline_refs); return -EUCLEAN; } + + if ((prev_key->type =3D=3D BTRFS_EXTENT_ITEM_KEY) || + (prev_key->type =3D=3D BTRFS_METADATA_ITEM_KEY)) { + u64 prev_end =3D prev_key->objectid; + + if (prev_key->type =3D=3D BTRFS_METADATA_ITEM_KEY) + prev_end +=3D fs_info->nodesize; + else + prev_end +=3D prev_key->offset; + + if (unlikely(prev_end > key->objectid)) { + extent_err(leaf, slot, + "previous extent [%llu %u %llu] overlaps current extent [%llu %u %llu]", + prev_key->objectid, prev_key->type, + prev_key->offset, key->objectid, key->type, + key->offset); + return -EUCLEAN; + } + } + return 0; } =20 @@ -1343,7 +1364,7 @@ static int check_leaf_item(struct extent_buffer *leaf, break; case BTRFS_EXTENT_ITEM_KEY: case BTRFS_METADATA_ITEM_KEY: - ret =3D check_extent_item(leaf, key, slot); + ret =3D check_extent_item(leaf, key, slot, prev_key); break; case BTRFS_TREE_BLOCK_REF_KEY: case BTRFS_SHARED_DATA_REF_KEY: --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6198C38145 for ; Fri, 2 Sep 2022 12:52:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237862AbiIBMwi (ORCPT ); Fri, 2 Sep 2022 08:52:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237790AbiIBMvn (ORCPT ); Fri, 2 Sep 2022 08:51:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCD245FFA; Fri, 2 Sep 2022 05:37:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 541A8B82AC1; Fri, 2 Sep 2022 12:30:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95C9DC43148; Fri, 2 Sep 2022 12:30:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121808; bh=ZJbxRJ0vFFPJ1uzFC8Exro17QL7g+4rklVQcPUsnADc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sGX6QNimB9EWpHzKf5CsUx9aTG8LWqUzjPyfIm+VT28l4O0eCQVKOmgZWY1cwiDaE 7K8gsLEZYM/g9Hxql0oyguFo3msjumGXt9swBwJh/fuJq1bBdq04jdf59JneXFwO2D zTpjcdKaehbp8P4ldWmvDqzmx7+tSiC0+OZ9Q4s0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christophe Leroy , Thomas Gleixner , Sasha Levin Subject: [PATCH 5.4 72/77] lib/vdso: Let do_coarse() return 0 to simplify the callsite Date: Fri, 2 Sep 2022 14:19:21 +0200 Message-Id: <20220902121406.079699178@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Christophe Leroy [ Upstream commit 8463cf80529d0fd80b84cd5ab8b9b952b01c7eb9 ] do_coarse() is similar to do_hres() except that it never fails. Change its type to int instead of void and let it always return success (0) to simplify the call site. Signed-off-by: Christophe Leroy Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/21e8afa38c02ca8672c2690307383507fe63b454.15= 77111367.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- lib/vdso/gettimeofday.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c index 45f57fd2db649..c549e72758aa0 100644 --- a/lib/vdso/gettimeofday.c +++ b/lib/vdso/gettimeofday.c @@ -68,7 +68,7 @@ static int do_hres(const struct vdso_data *vd, clockid_t = clk, return 0; } =20 -static void do_coarse(const struct vdso_data *vd, clockid_t clk, +static int do_coarse(const struct vdso_data *vd, clockid_t clk, struct __kernel_timespec *ts) { const struct vdso_timestamp *vdso_ts =3D &vd->basetime[clk]; @@ -79,6 +79,8 @@ static void do_coarse(const struct vdso_data *vd, clockid= _t clk, ts->tv_sec =3D vdso_ts->sec; ts->tv_nsec =3D vdso_ts->nsec; } while (unlikely(vdso_read_retry(vd, seq))); + + return 0; } =20 static __maybe_unused int @@ -96,14 +98,13 @@ __cvdso_clock_gettime_common(clockid_t clock, struct __= kernel_timespec *ts) * clocks are handled in the VDSO directly. */ msk =3D 1U << clock; - if (likely(msk & VDSO_HRES)) { + if (likely(msk & VDSO_HRES)) return do_hres(&vd[CS_HRES_COARSE], clock, ts); - } else if (msk & VDSO_COARSE) { - do_coarse(&vd[CS_HRES_COARSE], clock, ts); - return 0; - } else if (msk & VDSO_RAW) { + else if (msk & VDSO_COARSE) + return do_coarse(&vd[CS_HRES_COARSE], clock, ts); + else if (msk & VDSO_RAW) return do_hres(&vd[CS_RAW], clock, ts); - } + return -1; } =20 --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3818C38145 for ; Fri, 2 Sep 2022 14:45:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236857AbiIBOpz (ORCPT ); Fri, 2 Sep 2022 10:45:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237146AbiIBOpZ (ORCPT ); Fri, 2 Sep 2022 10:45:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69E4E6B173; Fri, 2 Sep 2022 07:05:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 48965B82AC6; Fri, 2 Sep 2022 12:30:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94244C433C1; Fri, 2 Sep 2022 12:30:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121810; bh=QjSZCYmT1sbZDjiyqBgLgnsWSWpH1v+Ns5lCvl/ZFLY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hv0cdPCsaGfQE0z8GXknqgtWRmlmomRmntPsOOyBLeVfaSRrOWUx2FE1iizfDQ/Wl pGl+9IuEUJOVx4JX55p2H/eLIq5wN66LpoiMM6P/C/7xGBxTFbxbM+5j21GB89UIqR ACGStFssEdsdEtZvWoc7WdYjgZHPWCLWYwkVxvwo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrei Vagin , Dmitry Safonov , Thomas Gleixner , Sasha Levin Subject: [PATCH 5.4 73/77] lib/vdso: Mark do_hres() and do_coarse() as __always_inline Date: Fri, 2 Sep 2022 14:19:22 +0200 Message-Id: <20220902121406.112426098@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Andrei Vagin [ Upstream commit c966533f8c6c45f93c52599f8460e7695f0b7eaa ] Performance numbers for Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (more clock_gettime() cycles - the better): clock | before | after | diff Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee ---------------------------------------------------------- monotonic | 153222105 | 166775025 | 8.8% monotonic-coarse | 671557054 | 691513017 | 3.0% monotonic-raw | 147116067 | 161057395 | 9.5% boottime | 153446224 | 166962668 | 9.1% The improvement for arm64 for monotonic and boottime is around 3.5%. clock | before | after | diff =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D monotonic 17326692 17951770 3.6% monotonic-coarse 43624027 44215292 1.3% monotonic-raw 17541809 17554932 0.1% boottime 17334982 17954361 3.5% [ tglx: Avoid the goto ] Signed-off-by: Andrei Vagin Signed-off-by: Dmitry Safonov Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20191112012724.250792-3-dima@arista.com Signed-off-by: Sasha Levin --- lib/vdso/gettimeofday.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c index c549e72758aa0..5667fb746a1fe 100644 --- a/lib/vdso/gettimeofday.c +++ b/lib/vdso/gettimeofday.c @@ -38,7 +38,7 @@ u64 vdso_calc_delta(u64 cycles, u64 last, u64 mask, u32 m= ult) } #endif =20 -static int do_hres(const struct vdso_data *vd, clockid_t clk, +static __always_inline int do_hres(const struct vdso_data *vd, clockid_t c= lk, struct __kernel_timespec *ts) { const struct vdso_timestamp *vdso_ts =3D &vd->basetime[clk]; @@ -68,8 +68,8 @@ static int do_hres(const struct vdso_data *vd, clockid_t = clk, return 0; } =20 -static int do_coarse(const struct vdso_data *vd, clockid_t clk, - struct __kernel_timespec *ts) +static __always_inline int do_coarse(const struct vdso_data *vd, clockid_t= clk, + struct __kernel_timespec *ts) { const struct vdso_timestamp *vdso_ts =3D &vd->basetime[clk]; u32 seq; @@ -99,13 +99,15 @@ __cvdso_clock_gettime_common(clockid_t clock, struct __= kernel_timespec *ts) */ msk =3D 1U << clock; if (likely(msk & VDSO_HRES)) - return do_hres(&vd[CS_HRES_COARSE], clock, ts); + vd =3D &vd[CS_HRES_COARSE]; else if (msk & VDSO_COARSE) return do_coarse(&vd[CS_HRES_COARSE], clock, ts); else if (msk & VDSO_RAW) - return do_hres(&vd[CS_RAW], clock, ts); + vd =3D &vd[CS_RAW]; + else + return -1; =20 - return -1; + return do_hres(vd, clock, ts); } =20 static __maybe_unused int --=20 2.35.1 From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9666DC6FA82 for ; Fri, 2 Sep 2022 12:44:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237418AbiIBMoo (ORCPT ); Fri, 2 Sep 2022 08:44:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237189AbiIBMmy (ORCPT ); Fri, 2 Sep 2022 08:42:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07633E115D; Fri, 2 Sep 2022 05:31:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 923FC6211C; Fri, 2 Sep 2022 12:30:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 629DFC433C1; Fri, 2 Sep 2022 12:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121814; bh=Ziv99L2b3du1h1a7R65LPMxQyVqzOc73xKy+IBtXdbI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lFLvrazuXd7kVLH1Y1pFA4Lcj/IfyEoeiL2XHmDWhGbpbDrqMSsExaT62D9h0AOKs nXI/LCNBe1d3tWMZseiyjMNwNGxtosVpobGOYpjuhF2F0tNLdg/0cJjf+gFzFzJQDn 1VWNtbzC4piM+ZKQIG5+nrS6kVeq+pbHABD6ppqA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , Ayushman Dutta , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Wang Nan , Kuniyuki Iwashima , Andrew Morton Subject: [PATCH 5.4 74/77] kprobes: dont call disarm_kprobe() for disabled kprobes Date: Fri, 2 Sep 2022 14:19:23 +0200 Message-Id: <20220902121406.140700798@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima commit 9c80e79906b4ca440d09e7f116609262bb747909 upstream. The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this. aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.i= sra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 = 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 8= 9 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trac= e/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/sched.h:2056 (discriminator 1) kernel/task_= work.c:179 (discriminator 1)) exit_to_user_mode_prepare (./include/linux/resume_user_mode.h:49 kernel/en= try/common.c:169 kernel/entry/common.c:201) syscall_exit_to_user_mode (./arch/x86/include/asm/jump_label.h:55 ./arch/x= 86/include/asm/nospec-branch.h:384 ./arch/x86/include/asm/entry-common.h:94= kernel/entry/common.c:133 kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:87) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP: 0033:0x7fe7ff210654 Code: 15 79 89 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb be 0f 1f 00 8b = 05 9a cd 20 00 48 63 ff 85 c0 75 11 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff f= f 77 3a f3 c3 48 83 ec 18 48 89 7c 24 08 e8 34 fc RSP: 002b:00007ffdbd1d3538 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000008 RCX: 00007fe7ff210654 RDX: 0000000000000000 RSI: 0000000000002401 RDI: 0000000000000008 RBP: 0000000000000000 R08: 94ae31d6fda838a4 R0900007fe8001c9d30 R10: 00007ffdbd1d34b0 R11: 0000000000000246 R12: 00007ffdbd1d3600 R13: 0000000000000000 R14: fffffffffffffffc R15: 00007ffdbd1d3560 Link: https://lkml.kernel.org/r/20220813020509.90805-1-kuniyu@amazon.com Fixes: 69d54b916d83 ("kprobes: makes kprobes/enabled works correctly for op= timized kprobes.") Signed-off-by: Kuniyuki Iwashima Reported-by: Ayushman Dutta Cc: "Naveen N. Rao" Cc: Anil S Keshavamurthy Cc: "David S. Miller" Cc: Masami Hiramatsu Cc: Wang Nan Cc: Kuniyuki Iwashima Cc: Kuniyuki Iwashima Cc: Ayushman Dutta Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/kprobes.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1737,11 +1737,12 @@ static struct kprobe *__disable_kprobe(s /* Try to disarm and disable this/parent probe */ if (p =3D=3D orig_p || aggr_kprobe_disabled(orig_p)) { /* - * If kprobes_all_disarmed is set, orig_p - * should have already been disarmed, so - * skip unneed disarming process. + * Don't be lazy here. Even if 'kprobes_all_disarmed' + * is false, 'orig_p' might not have been armed yet. + * Note arm_all_kprobes() __tries__ to arm all kprobes + * on the best effort basis. */ - if (!kprobes_all_disarmed) { + if (!kprobes_all_disarmed && !kprobe_disabled(orig_p)) { ret =3D disarm_kprobe(orig_p, true); if (ret) { p->flags &=3D ~KPROBE_FLAG_DISABLED; From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 104F9C38145 for ; Fri, 2 Sep 2022 12:41:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237303AbiIBMlT (ORCPT ); Fri, 2 Sep 2022 08:41:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237254AbiIBMiz (ORCPT ); Fri, 2 Sep 2022 08:38:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0DD444566; Fri, 2 Sep 2022 05:30:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E41326215A; Fri, 2 Sep 2022 12:30:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB809C433D6; Fri, 2 Sep 2022 12:30:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121820; bh=jg21/zAcWtXDnw6C4rfwOyVUqIjJj4LhRlaz0D8/GT0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f/w6eqSiR1xA9GRJ2pYbx0/Ukp0CYoOEvDXUKtBjoBI13knHP5B+l1l/6CZHWcr/I QBNel3q/nIDlZVhUBZueyyQnEglhaM8cDbAXAP1EeFVOwPbtn90WOoWH6XtUycPp7M lUQZnhEtyLJfoaw8d3zeywTK/9L6qBeSyOGzeQ+k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Pavel Begunkov Subject: [PATCH 5.4 75/77] io_uring: disable polling pollfree files Date: Fri, 2 Sep 2022 14:19:24 +0200 Message-Id: <20220902121406.177903979@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pavel Begunkov Older kernels lack io_uring POLLFREE handling. As only affected files are signalfd and android binder the safest option would be to disable polling those files via io_uring and hope there are no users. Fixes: 221c5eb233823 ("io_uring: add support for IORING_OP_POLL") Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/android/binder.c | 1 + fs/io_uring.c | 3 +++ fs/signalfd.c | 1 + include/linux/fs.h | 1 + 4 files changed, 6 insertions(+) --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -6083,6 +6083,7 @@ const struct file_operations binder_fops .open =3D binder_open, .flush =3D binder_flush, .release =3D binder_release, + .may_pollfree =3D true, }; =20 static int __init init_binder_device(const char *name) --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -1908,6 +1908,9 @@ static int io_poll_add(struct io_kiocb * __poll_t mask; u16 events; =20 + if (req->file->f_op->may_pollfree) + return -EOPNOTSUPP; + if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL)) return -EINVAL; if (sqe->addr || sqe->ioprio || sqe->off || sqe->len || sqe->buf_index) --- a/fs/signalfd.c +++ b/fs/signalfd.c @@ -248,6 +248,7 @@ static const struct file_operations sign .poll =3D signalfd_poll, .read =3D signalfd_read, .llseek =3D noop_llseek, + .may_pollfree =3D true, }; =20 static int do_signalfd4(int ufd, sigset_t *mask, int flags) --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1859,6 +1859,7 @@ struct file_operations { struct file *file_out, loff_t pos_out, loff_t len, unsigned int remap_flags); int (*fadvise)(struct file *, loff_t, loff_t, int); + bool may_pollfree; } __randomize_layout; =20 struct inode_operations { From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E02F2C38145 for ; Fri, 2 Sep 2022 14:45:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236701AbiIBOpw (ORCPT ); Fri, 2 Sep 2022 10:45:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236785AbiIBOpZ (ORCPT ); Fri, 2 Sep 2022 10:45:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9BC1F2405; Fri, 2 Sep 2022 07:05:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D1E2AB82A90; Fri, 2 Sep 2022 12:30:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12ACAC433D6; Fri, 2 Sep 2022 12:30:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121823; bh=uV//fd3/pCklVx3bACI/j43ll78KoIWsCtxberp1jf4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gR/B+x2LSq506PaefKrhfyD71MPBC26/L7p3A/XQ3wB1m2IWZ/9o6tR5OYyGfSSw4 WTRUhOy4849E4s1aMzwOcBbvR6KKYnuvvZk+9iWuqp3OcJckqkF5UuHGWkOw3TAJnf 9OhlE2neRpNkROWMwyCb6MKDbjmAAi8kXJGQT3Uw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+5ea725c25d06fb9114c4@syzkaller.appspotmail.com, Zhengchao Shao , "David S. Miller" Subject: [PATCH 5.4 76/77] net/af_packet: check len when min_header_len equals to 0 Date: Fri, 2 Sep 2022 14:19:25 +0200 Message-Id: <20220902121406.217342438@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhengchao Shao commit dc633700f00f726e027846a318c5ffeb8deaaeda upstream. User can use AF_PACKET socket to send packets with the length of 0. When min_header_len equals to 0, packet_snd will call __dev_queue_xmit to send packets, and sock->type can be any type. Reported-by: syzbot+5ea725c25d06fb9114c4@syzkaller.appspotmail.com Fixes: fd1894224407 ("bpf: Don't redirect packets with invalid pkt_len") Signed-off-by: Zhengchao Shao Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/packet/af_packet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -2960,8 +2960,8 @@ static int packet_snd(struct socket *soc if (err) goto out_free; =20 - if (sock->type =3D=3D SOCK_RAW && - !dev_validate_header(dev, skb->data, len)) { + if ((sock->type =3D=3D SOCK_RAW && + !dev_validate_header(dev, skb->data, len)) || !skb->len) { err =3D -EINVAL; goto out_free; } From nobody Sun Sep 7 12:19:02 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B84C9C38145 for ; Fri, 2 Sep 2022 12:41:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237308AbiIBMlY (ORCPT ); Fri, 2 Sep 2022 08:41:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237268AbiIBMi5 (ORCPT ); Fri, 2 Sep 2022 08:38:57 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBDAE6B8D1; Fri, 2 Sep 2022 05:30:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 04097B82AA1; Fri, 2 Sep 2022 12:30:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E261C433C1; Fri, 2 Sep 2022 12:30:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662121826; bh=qJtlZbyOTsV51PIP1uTB7gctPH/B6Gl+DB+pExHFlyw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZiO9ex39oc/ykwU/40wU9xIchlcVqZJ5hq2rap+/VPWjNkwzdTbb4jh02PHv3FX8/ 4KUeUvdRoOYmBCgX4WqZpJqO41rQuQsW4p5ypAP1gfmov3wkrMy6ntD/kPFYziUjpY 1OfA/5JWAlSgbJRhIxH7IlA3scl4qLthJccsCQhY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Denis V. Lunev" , Yang Yingliang , Nikolay Aleksandrov , "David S. Miller" Subject: [PATCH 5.4 77/77] net: neigh: dont call kfree_skb() under spin_lock_irqsave() Date: Fri, 2 Sep 2022 14:19:26 +0200 Message-Id: <20220902121406.246311198@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121403.569927325@linuxfoundation.org> References: <20220902121403.569927325@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Yang Yingliang commit d5485d9dd24e1d04e5509916515260186eb1455c upstream. It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So add all skb to a tmp list, then free them after spin_unlock_irqrestore() at once. Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop l= oop") Suggested-by: Denis V. Lunev Signed-off-by: Yang Yingliang Reviewed-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/neighbour.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -282,21 +282,27 @@ static int neigh_del_timer(struct neighb =20 static void pneigh_queue_purge(struct sk_buff_head *list, struct net *net) { + struct sk_buff_head tmp; unsigned long flags; struct sk_buff *skb; =20 + skb_queue_head_init(&tmp); spin_lock_irqsave(&list->lock, flags); skb =3D skb_peek(list); while (skb !=3D NULL) { struct sk_buff *skb_next =3D skb_peek_next(skb, list); if (net =3D=3D NULL || net_eq(dev_net(skb->dev), net)) { __skb_unlink(skb, list); - dev_put(skb->dev); - kfree_skb(skb); + __skb_queue_tail(&tmp, skb); } skb =3D skb_next; } spin_unlock_irqrestore(&list->lock, flags); + + while ((skb =3D __skb_dequeue(&tmp))) { + dev_put(skb->dev); + kfree_skb(skb); + } } =20 static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *de= v,