From nobody Tue Apr 28 06:30:15 2026 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 CC983CCA473 for ; Fri, 3 Jun 2022 17:53:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345611AbiFCRxh (ORCPT ); Fri, 3 Jun 2022 13:53:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345621AbiFCRuD (ORCPT ); Fri, 3 Jun 2022 13:50:03 -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 DB9D4583A8; Fri, 3 Jun 2022 10:46: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 63AC4B82430; Fri, 3 Jun 2022 17:46:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3222C385A9; Fri, 3 Jun 2022 17:46:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278365; bh=+8/rSL0dktqyZfvWABToCYxgk0Wct5z+yxpZFfy6gak=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zJ/NNyNU/7l2cmiYZuIfTHFcVsKspw4e+c7V2mcpT18KBr14Sh9JVt3w2EJUerTnh 559KHU80WwuzuQghDUQLMxwylpY0eBG7KCQhPibiwzjy20i5WOPe1uAWR6HU9oowfE ee3gK5nHXJB81eiHYZsLe41PTR4BfGMPjd5ou37g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, IotaHydrae , Andre Przywara , Linus Walleij , Sasha Levin Subject: [PATCH 5.10 01/53] pinctrl: sunxi: fix f1c100s uart2 function Date: Fri, 3 Jun 2022 19:42:46 +0200 Message-Id: <20220603173818.760924525@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: IotaHydrae [ Upstream commit fa8785e5931367e2b43f2c507f26bcf3e281c0ca ] Change suniv f1c100s pinctrl,PD14 multiplexing function lvds1 to uart2 When the pin PD13 and PD14 is setting up to uart2 function in dts, there's an error occurred: 1c20800.pinctrl: unsupported function uart2 on pin PD14 Because 'uart2' is not any one multiplexing option of PD14, and pinctrl don't know how to configure it. So change the pin PD14 lvds1 function to uart2. Signed-off-by: IotaHydrae Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/tencent_70C1308DDA794C81CAEF389049055BACEC0= 9@qq.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c b/drivers/pinctr= l/sunxi/pinctrl-suniv-f1c100s.c index 2801ca706273..68a5b627fb9b 100644 --- a/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c +++ b/drivers/pinctrl/sunxi/pinctrl-suniv-f1c100s.c @@ -204,7 +204,7 @@ static const struct sunxi_desc_pin suniv_f1c100s_pins[]= =3D { SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "lcd"), /* D20 */ - SUNXI_FUNCTION(0x3, "lvds1"), /* RX */ + SUNXI_FUNCTION(0x3, "uart2"), /* RX */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)), SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15), SUNXI_FUNCTION(0x0, "gpio_in"), --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 BAAB0C433EF for ; Fri, 3 Jun 2022 17:54:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345689AbiFCRyP (ORCPT ); Fri, 3 Jun 2022 13:54:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345890AbiFCRuc (ORCPT ); Fri, 3 Jun 2022 13:50: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 40F15562E4; Fri, 3 Jun 2022 10:46:33 -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 6A0B660A24; Fri, 3 Jun 2022 17:46:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F4BAC385A9; Fri, 3 Jun 2022 17:46:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278391; bh=dpH0iACmdZliwu7JPRo+bUchXXFIwcB3x+lHvB7xBxI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k3bwi/X9thv2YiLcr7xsmaw7QhIi27EvjXsSBwHXA+iqDom1MfTqHZsa0zKDyyTur Sg3hDS7PlfdB/ZhXrLnIx+wxcHlr77fK22Kz+CmJaYTlJ0lkjGVw1n99qwMIfTohsS w52K+GZRntVL2L4PhIh+0DEFDNCdxi0NqBB78BlA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+5b1e53987f858500ec00@syzkaller.appspotmail.com, Al Viro , Sasha Levin Subject: [PATCH 5.10 02/53] percpu_ref_init(): clean ->percpu_count_ref on failure Date: Fri, 3 Jun 2022 19:42:47 +0200 Message-Id: <20220603173818.789968820@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Al Viro [ Upstream commit a91714312eb16f9ecd1f7f8b3efe1380075f28d4 ] That way percpu_ref_exit() is safe after failing percpu_ref_init(). At least one user (cgroup_create()) had a double-free that way; there might be other similar bugs. Easier to fix in percpu_ref_init(), rather than playing whack-a-mole in sloppy users... Usual symptoms look like a messed refcounting in one of subsystems that use percpu allocations (might be percpu-refcount, might be something else). Having refcounts for two different objects share memory is Not Nice(tm)... Reported-by: syzbot+5b1e53987f858500ec00@syzkaller.appspotmail.com Signed-off-by: Al Viro Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- lib/percpu-refcount.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c index e59eda07305e..493093b97093 100644 --- a/lib/percpu-refcount.c +++ b/lib/percpu-refcount.c @@ -75,6 +75,7 @@ int percpu_ref_init(struct percpu_ref *ref, percpu_ref_fu= nc_t *release, data =3D kzalloc(sizeof(*ref->data), gfp); if (!data) { free_percpu((void __percpu *)ref->percpu_count_ptr); + ref->percpu_count_ptr =3D 0; return -ENOMEM; } =20 --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 BC599C433EF for ; Fri, 3 Jun 2022 17:54:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345565AbiFCRyT (ORCPT ); Fri, 3 Jun 2022 13:54:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345910AbiFCRud (ORCPT ); Fri, 3 Jun 2022 13:50:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18CD15623A; Fri, 3 Jun 2022 10:46: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 5E06760A54; Fri, 3 Jun 2022 17:46:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D771C385A9; Fri, 3 Jun 2022 17:46:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278394; bh=IekshAmuA1QsGwfqDVxtu1QYqOMo0gLUA/qG1zyrgHc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J3qfseseDLtFeLClQimBJP5sacODXGtyU746c7lsdsTFsto9tXiharjxVxK7idFCN xPfO6FHHjjLxAByr6eWYybIruNWa3yIN1aF0zip49oYNHhOS1TKpEw3TGHu9vL2Yys st0TrCm5Zs34+HIQCrDAoh1smfvn/amvUK0U80lE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thomas Bartschies , Steffen Klassert , Sasha Levin Subject: [PATCH 5.10 03/53] net: af_key: check encryption module availability consistency Date: Fri, 3 Jun 2022 19:42:48 +0200 Message-Id: <20220603173818.818533060@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Thomas Bartschies [ Upstream commit 015c44d7bff3f44d569716117becd570c179ca32 ] Since the recent introduction supporting the SM3 and SM4 hash algos for IPs= ec, the kernel produces invalid pfkey acquire messages, when these encryption modules are = disabled. This happens because the availability of the algos wasn't checked in all necessa= ry functions. This patch adds these checks. Signed-off-by: Thomas Bartschies Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- net/key/af_key.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/key/af_key.c b/net/key/af_key.c index 61505b0df57d..6b7ed5568c09 100644 --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -2904,7 +2904,7 @@ static int count_ah_combs(const struct xfrm_tmpl *t) break; if (!aalg->pfkey_supported) continue; - if (aalg_tmpl_set(t, aalg)) + if (aalg_tmpl_set(t, aalg) && aalg->available) sz +=3D sizeof(struct sadb_comb); } return sz + sizeof(struct sadb_prop); @@ -2922,7 +2922,7 @@ static int count_esp_combs(const struct xfrm_tmpl *t) if (!ealg->pfkey_supported) continue; =20 - if (!(ealg_tmpl_set(t, ealg))) + if (!(ealg_tmpl_set(t, ealg) && ealg->available)) continue; =20 for (k =3D 1; ; k++) { @@ -2933,7 +2933,7 @@ static int count_esp_combs(const struct xfrm_tmpl *t) if (!aalg->pfkey_supported) continue; =20 - if (aalg_tmpl_set(t, aalg)) + if (aalg_tmpl_set(t, aalg) && aalg->available) sz +=3D sizeof(struct sadb_comb); } } --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 D75F9C43334 for ; Fri, 3 Jun 2022 17:54:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345586AbiFCRyY (ORCPT ); Fri, 3 Jun 2022 13:54:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345925AbiFCRue (ORCPT ); Fri, 3 Jun 2022 13:50:34 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D404B56420; Fri, 3 Jun 2022 10:46: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 4E141B82189; Fri, 3 Jun 2022 17:46:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8485C3411C; Fri, 3 Jun 2022 17:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278398; bh=pQoT+kDWEMU+OriFqW5qRi/QG2woaSt+7HNGfacypW4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dctu414WVo0Ogch0d3yz3lZ1I1dsfFEXWGKmlwF/1dsBWAQP8empRGHQ4SlsgzF2a B5bwNxuZXSGY6HXmuUwyxr8oFXI00pFo5dNFUiIkddJxCgTQ3AcTn/hPb8HKpXdnh9 /frDkHk6sS+KyoMJJrQ7JC4llhU8/5orswmjWqoc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lin Ma , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 04/53] nfc: pn533: Fix buggy cleanup order Date: Fri, 3 Jun 2022 19:42:49 +0200 Message-Id: <20220603173818.847165589@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Lin Ma [ Upstream commit b8cedb7093b2d1394cae9b86494cba4b62d3a30a ] When removing the pn533 device (i2c or USB), there is a logic error. The original code first cancels the worker (flush_delayed_work) and then destroys the workqueue (destroy_workqueue), leaving the timer the last one to be deleted (del_timer). This result in a possible race condition in a multi-core preempt-able kernel. That is, if the cleanup (pn53x_common_clean) is concurrently run with the timer handler (pn533_listen_mode_timer), the timer can queue the poll_work to the already destroyed workqueue, causing use-after-free. This patch reorder the cleanup: it uses the del_timer_sync to make sure the handler is finished before the routine will destroy the workqueue. Note that the timer cannot be activated by the worker again. static void pn533_wq_poll(struct work_struct *work) ... rc =3D pn533_send_poll_frame(dev); if (rc) return; if (cur_mod->len =3D=3D 0 && dev->poll_mod_count > 1) mod_timer(&dev->listen_timer, ...); That is, the mod_timer can be called only when pn533_send_poll_frame() returns no error, which is impossible because the device is detaching and the lower driver should return ENODEV code. Signed-off-by: Lin Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/nfc/pn533/pn533.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c index d2c011615775..8d7e29d953b7 100644 --- a/drivers/nfc/pn533/pn533.c +++ b/drivers/nfc/pn533/pn533.c @@ -2844,13 +2844,14 @@ void pn53x_common_clean(struct pn533 *priv) { struct pn533_cmd *cmd, *n; =20 + /* delete the timer before cleanup the worker */ + del_timer_sync(&priv->listen_timer); + flush_delayed_work(&priv->poll_work); destroy_workqueue(priv->wq); =20 skb_queue_purge(&priv->resp_q); =20 - del_timer(&priv->listen_timer); - list_for_each_entry_safe(cmd, n, &priv->cmd_queue, queue) { list_del(&cmd->queue); kfree(cmd); --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 D2C72C43334 for ; Fri, 3 Jun 2022 17:54:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345692AbiFCRyk (ORCPT ); Fri, 3 Jun 2022 13:54:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345936AbiFCRue (ORCPT ); Fri, 3 Jun 2022 13:50:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A2B95643D; Fri, 3 Jun 2022 10:46: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 dfw.source.kernel.org (Postfix) with ESMTPS id 84EF960C3D; Fri, 3 Jun 2022 17:46:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97A3FC385B8; Fri, 3 Jun 2022 17:46:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278401; bh=zzK0D5fYTBTycaZxn6iEpDan7mnQBFt5zYd/KNuOLdE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yXRH6WWzonvqhOthkE8lpFbHEJ0Im6NEbZZnz8mNoIUDrdzunNxDkSaShC0Bp62zs cmull4fF3UsTPO6CvvbU3CeG9I5g4XWVPDpJvN2Hcrw7fWgnEO3dJklRJnonfhLhQC byO6r5zT9Vz5Ny4DjF8sx0MGVavpT7N7Ntj9PJfs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Wilder , Dylan Hung , Joel Stanley , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 05/53] net: ftgmac100: Disable hardware checksum on AST2600 Date: Fri, 3 Jun 2022 19:42:50 +0200 Message-Id: <20220603173818.875263971@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Joel Stanley [ Upstream commit 6fd45e79e8b93b8d22fb8fe22c32fbad7e9190bd ] The AST2600 when using the i210 NIC over NC-SI has been observed to produce incorrect checksum results with specific MTU values. This was first observed when sending data across a long distance set of networks. On a local network, the following test was performed using a 1MB file of random data. On the receiver run this script: #!/bin/bash while [ 1 ]; do # Zero the stats nstat -r > /dev/null nc -l 9899 > test-file # Check for checksum errors TcpInCsumErrors=3D$(nstat | grep TcpInCsumErrors) if [ -z "$TcpInCsumErrors" ]; then echo No TcpInCsumErrors else echo TcpInCsumErrors =3D $TcpInCsumErrors fi done On an AST2600 system: # nc 9899 < test-file The test was repeated with various MTU values: # ip link set mtu 1410 dev eth0 The observed results: 1500 - good 1434 - bad 1400 - good 1410 - bad 1420 - good The test was repeated after disabling tx checksumming: # ethtool -K eth0 tx-checksumming off And all MTU values tested resulted in transfers without error. An issue with the driver cannot be ruled out, however there has been no bug discovered so far. David has done the work to take the original bug report of slow data transfer between long distance connections and triaged it down to this test case. The vendor suspects this this is a hardware issue when using NC-SI. The fixes line refers to the patch that introduced AST2600 support. Reported-by: David Wilder Reviewed-by: Dylan Hung Signed-off-by: Joel Stanley Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/etherne= t/faraday/ftgmac100.c index 5bc11d1bb9df..eea4bd3116e8 100644 --- a/drivers/net/ethernet/faraday/ftgmac100.c +++ b/drivers/net/ethernet/faraday/ftgmac100.c @@ -1893,6 +1893,11 @@ static int ftgmac100_probe(struct platform_device *p= dev) /* AST2400 doesn't have working HW checksum generation */ if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac"))) netdev->hw_features &=3D ~NETIF_F_HW_CSUM; + + /* AST2600 tx checksum with NCSI is broken */ + if (priv->use_ncsi && of_device_is_compatible(np, "aspeed,ast2600-mac")) + netdev->hw_features &=3D ~NETIF_F_HW_CSUM; + if (np && of_get_property(np, "no-hw-checksum", NULL)) netdev->hw_features &=3D ~(NETIF_F_HW_CSUM | NETIF_F_RXCSUM); netdev->features |=3D netdev->hw_features; --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 4E90DCCA47E for ; Fri, 3 Jun 2022 17:54:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344370AbiFCRyf (ORCPT ); Fri, 3 Jun 2022 13:54:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345942AbiFCRuf (ORCPT ); Fri, 3 Jun 2022 13:50:35 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B83A62ED; Fri, 3 Jun 2022 10:46: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 dfw.source.kernel.org (Postfix) with ESMTPS id 74481604EF; Fri, 3 Jun 2022 17:46:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81611C385B8; Fri, 3 Jun 2022 17:46:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278403; bh=bT4CTgHpvXVv/uW9tgfQDMcOFCpQ1VTbuOkkQWTBUAc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pGKquLfJlmdeSBS5sV+DYh51owVItTlh+z1DeQPxn3TBbnn/woCIXRYzVQuN00gBq RVfwEVFmSxKHDX7T5wufvmVWYsokY07v4p7sBMZHqkzfoJ8/a0NeCEeqS7eo++p78/ pSct5+fe8YRmF0o+bNoaJENi3VV8Dlxbau+/rCaE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mika Westerberg , "From: Andy Shevchenko" , Wolfram Sang , Sasha Levin Subject: [PATCH 5.10 06/53] i2c: ismt: Provide a DMA buffer for Interrupt Cause Logging Date: Fri, 3 Jun 2022 19:42:51 +0200 Message-Id: <20220603173818.905015262@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Mika Westerberg [ Upstream commit 17a0f3acdc6ec8b89ad40f6e22165a4beee25663 ] Before sending a MSI the hardware writes information pertinent to the interrupt cause to a memory location pointed by SMTICL register. This memory holds three double words where the least significant bit tells whether the interrupt cause of master/target/error is valid. The driver does not use this but we need to set it up because otherwise it will perform DMA write to the default address (0) and this will cause an IOMMU fault such as below: DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write] Request device [00:12.0] PASID ffffffff fault addr 0 [fault reason 05] PTE Write access is not set To prevent this from happening, provide a proper DMA buffer for this that then gets mapped by the IOMMU accordingly. Signed-off-by: Mika Westerberg Reviewed-by: From: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/i2c/busses/i2c-ismt.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c index a35a27c320e7..3d2d92640651 100644 --- a/drivers/i2c/busses/i2c-ismt.c +++ b/drivers/i2c/busses/i2c-ismt.c @@ -82,6 +82,7 @@ =20 #define ISMT_DESC_ENTRIES 2 /* number of descriptor entries */ #define ISMT_MAX_RETRIES 3 /* number of SMBus retries to attempt */ +#define ISMT_LOG_ENTRIES 3 /* number of interrupt cause log entries */ =20 /* Hardware Descriptor Constants - Control Field */ #define ISMT_DESC_CWRL 0x01 /* Command/Write Length */ @@ -175,6 +176,8 @@ struct ismt_priv { u8 head; /* ring buffer head pointer */ struct completion cmp; /* interrupt completion */ u8 buffer[I2C_SMBUS_BLOCK_MAX + 16]; /* temp R/W data buffer */ + dma_addr_t log_dma; + u32 *log; }; =20 static const struct pci_device_id ismt_ids[] =3D { @@ -409,6 +412,9 @@ static int ismt_access(struct i2c_adapter *adap, u16 ad= dr, memset(desc, 0, sizeof(struct ismt_desc)); desc->tgtaddr_rw =3D ISMT_DESC_ADDR_RW(addr, read_write); =20 + /* Always clear the log entries */ + memset(priv->log, 0, ISMT_LOG_ENTRIES * sizeof(u32)); + /* Initialize common control bits */ if (likely(pci_dev_msi_enabled(priv->pci_dev))) desc->control =3D ISMT_DESC_INT | ISMT_DESC_FAIR; @@ -693,6 +699,8 @@ static void ismt_hw_init(struct ismt_priv *priv) /* initialize the Master Descriptor Base Address (MDBA) */ writeq(priv->io_rng_dma, priv->smba + ISMT_MSTR_MDBA); =20 + writeq(priv->log_dma, priv->smba + ISMT_GR_SMTICL); + /* initialize the Master Control Register (MCTRL) */ writel(ISMT_MCTRL_MEIE, priv->smba + ISMT_MSTR_MCTRL); =20 @@ -780,6 +788,12 @@ static int ismt_dev_init(struct ismt_priv *priv) priv->head =3D 0; init_completion(&priv->cmp); =20 + priv->log =3D dmam_alloc_coherent(&priv->pci_dev->dev, + ISMT_LOG_ENTRIES * sizeof(u32), + &priv->log_dma, GFP_KERNEL); + if (!priv->log) + return -ENOMEM; + return 0; } =20 --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 36047C43334 for ; Fri, 3 Jun 2022 17:54:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345756AbiFCRya (ORCPT ); Fri, 3 Jun 2022 13:54:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345951AbiFCRug (ORCPT ); Fri, 3 Jun 2022 13:50:36 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7EF8A2BDE; Fri, 3 Jun 2022 10:46: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 2E7C0B82419; Fri, 3 Jun 2022 17:46:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78333C385A9; Fri, 3 Jun 2022 17:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278406; bh=UIvOGU9ezNqd/V+eh1/mLYA2MyU4xUyFduSUC7Zg0Ms=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vLI8RaFASW9XB3nLQy8Tu3j0bvjPAYnjEylGfzcMNvQdknB8UaqqdHGASEsypCK2V 5Iix/qpoYi5e/gUJfSnDXpi5svq1mjsJgLRVoowkEg7YP33KF8d+fmXAKX05Rgavlq cQhEY4azix6D79qHrPcyRhJOUP0zdKca+kp1lN0g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Szymon Balcerak , Piyush Malgujar , Wolfram Sang , Sasha Levin Subject: [PATCH 5.10 07/53] drivers: i2c: thunderx: Allow driver to work with ACPI defined TWSI controllers Date: Fri, 3 Jun 2022 19:42:52 +0200 Message-Id: <20220603173818.934482633@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Piyush Malgujar [ Upstream commit 03a35bc856ddc09f2cc1f4701adecfbf3b464cb3 ] Due to i2c->adap.dev.fwnode not being set, ACPI_COMPANION() wasn't properly found for TWSI controllers. Signed-off-by: Szymon Balcerak Signed-off-by: Piyush Malgujar Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/i2c/busses/i2c-thunderx-pcidrv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-thunderx-pcidrv.c b/drivers/i2c/busses/= i2c-thunderx-pcidrv.c index 12c90aa0900e..a77cd86fe75e 100644 --- a/drivers/i2c/busses/i2c-thunderx-pcidrv.c +++ b/drivers/i2c/busses/i2c-thunderx-pcidrv.c @@ -213,6 +213,7 @@ static int thunder_i2c_probe_pci(struct pci_dev *pdev, i2c->adap.bus_recovery_info =3D &octeon_i2c_recovery_info; i2c->adap.dev.parent =3D dev; i2c->adap.dev.of_node =3D pdev->dev.of_node; + i2c->adap.dev.fwnode =3D dev->fwnode; snprintf(i2c->adap.name, sizeof(i2c->adap.name), "Cavium ThunderX i2c adapter at %s", dev_name(dev)); i2c_set_adapdata(&i2c->adap, i2c); --=20 2.35.1 From nobody Tue Apr 28 06:30:15 2026 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 3287CC433EF for ; Fri, 3 Jun 2022 17:54:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242858AbiFCRyt (ORCPT ); Fri, 3 Jun 2022 13:54:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345974AbiFCRui (ORCPT ); Fri, 3 Jun 2022 13:50:38 -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 1A8B3B48E; Fri, 3 Jun 2022 10:46: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 619CCB82189; Fri, 3 Jun 2022 17:46:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC5A1C385A9; Fri, 3 Jun 2022 17:46:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278410; bh=oCsNTIo7XIHOw1ACzIhZHujD4nUnDMytpJVQ7UrnWnA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1aLc58uG5zZk0mAt9sAZkTKLoliHoBhPukHCbgE6MQFz+13Kw99K/YqtxL3DDK9mG pIri2neqls+LEeoWmzRlGilR7Lx5BOuSNtP888aGxwnwAcviG+MFFKgvIEfGJ2WZiL bVvk9xpMzjt4aXpLpHAkMDgIHBGeQEmQIjfBLb9E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Aaron Adams Subject: [PATCH 5.10 08/53] netfilter: nf_tables: disallow non-stateful expression in sets earlier Date: Fri, 3 Jun 2022 19:42:53 +0200 Message-Id: <20220603173818.961780902@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 commit 520778042ccca019f3ffa136dd0ca565c486cedd upstream. Since 3e135cd499bf ("netfilter: nft_dynset: dynamic stateful expression instantiation"), it is possible to attach stateful expressions to set elements. cd5125d8f518 ("netfilter: nf_tables: split set destruction in deactivate and destroy phase") introduces conditional destruction on the object to accomodate transaction semantics. nft_expr_init() calls expr->ops->init() first, then check for NFT_STATEFUL_EXPR, this stills allows to initialize a non-stateful lookup expressions which points to a set, which might lead to UAF since the set is not properly detached from the set->binding for this case. Anyway, this combination is non-sense from nf_tables perspective. This patch fixes this problem by checking for NFT_STATEFUL_EXPR before expr->ops->init() is called. The reporter provides a KASAN splat and a poc reproducer (similar to those autogenerated by syzbot to report use-after-free errors). It is unknown to me if they are using syzbot or if they use similar automated tool to locate the bug that they are reporting. For the record, this is the KASAN splat. [ 85.431824] =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ 85.432901] BUG: KASAN: use-after-free in nf_tables_bind_set+0x81b/0xa20 [ 85.433825] Write of size 8 at addr ffff8880286f0e98 by task poc/776 [ 85.434756] [ 85.434999] CPU: 1 PID: 776 Comm: poc Tainted: G W 5.18.0= + #2 [ 85.436023] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS = 1.14.0-2 04/01/2014 Fixes: 0b2d8a7b638b ("netfilter: nf_tables: add helper functions for expres= sion handling") Reported-and-tested-by: Aaron Adams Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- net/netfilter/nf_tables_api.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -2679,27 +2679,31 @@ static struct nft_expr *nft_expr_init(co =20 err =3D nf_tables_expr_parse(ctx, nla, &info); if (err < 0) - goto err1; + goto err_expr_parse; + + err =3D -EOPNOTSUPP; + if (!(info.ops->type->flags & NFT_EXPR_STATEFUL)) + goto err_expr_stateful; =20 err =3D -ENOMEM; expr =3D kzalloc(info.ops->size, GFP_KERNEL); if (expr =3D=3D NULL) - goto err2; + goto err_expr_stateful; =20 err =3D nf_tables_newexpr(ctx, &info, expr); if (err < 0) - goto err3; + goto err_expr_new; =20 return expr; -err3: +err_expr_new: kfree(expr); -err2: +err_expr_stateful: owner =3D info.ops->type->owner; if (info.ops->type->release_ops) info.ops->type->release_ops(info.ops); =20 module_put(owner); -err1: +err_expr_parse: return ERR_PTR(err); } =20 @@ -5055,9 +5059,6 @@ struct nft_expr *nft_set_elem_expr_alloc return expr; =20 err =3D -EOPNOTSUPP; - if (!(expr->ops->type->flags & NFT_EXPR_STATEFUL)) - goto err_set_elem_expr; - if (expr->ops->type->flags & NFT_EXPR_GC) { if (set->flags & NFT_SET_TIMEOUT) goto err_set_elem_expr; From nobody Tue Apr 28 06:30:15 2026 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 16A2CCCA480 for ; Fri, 3 Jun 2022 17:55:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345780AbiFCRy4 (ORCPT ); Fri, 3 Jun 2022 13:54:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345975AbiFCRui (ORCPT ); Fri, 3 Jun 2022 13:50:38 -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 8B510DECE; Fri, 3 Jun 2022 10:46: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 AF730604EF; Fri, 3 Jun 2022 17:46:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6CEDC385A9; Fri, 3 Jun 2022 17:46:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278413; bh=Lsl4MGIj+lFgH3ZgJ+tEmOVp6Tpf+jsCIrpUeJnyOnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mahsqZlrfDNO74CTk91BrnrQoRUD4i/BKqkmB4FXNPo2PPFYHk8WSf+AkMzf2u2LS jkE6cu7nUXpYt4xaW8DBWgAFtN97qh4q6ERFlOx4vKB8WMWZgbXIxEQWyXGpXZjp4h RThMTPBy9aPE4e2BmXM73N71HVDYf03jRA64bh2M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , Alexander Duyck , Al Viro , Davidlohr Bueso , Kuniyuki Iwashima , "Soheil Hassas Yeganeh" , "Sridhar Samudrala" , Andrew Morton Subject: [PATCH 5.10 09/53] pipe: make poll_usage boolean and annotate its access Date: Fri, 3 Jun 2022 19:42:54 +0200 Message-Id: <20220603173818.990315783@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 f485922d8fe4e44f6d52a5bb95a603b7c65554bb upstream. Patch series "Fix data-races around epoll reported by KCSAN." This series suppresses a false positive KCSAN's message and fixes a real data-race. This patch (of 2): pipe_poll() runs locklessly and assigns 1 to poll_usage. Once poll_usage is set to 1, it never changes in other places. However, concurrent writes of a value trigger KCSAN, so let's make KCSAN happy. BUG: KCSAN: data-race in pipe_poll / pipe_poll write to 0xffff8880042f6678 of 4 bytes by task 174 on cpu 3: pipe_poll (fs/pipe.c:656) ep_item_poll.isra.0 (./include/linux/poll.h:88 fs/eventpoll.c:853) do_epoll_wait (fs/eventpoll.c:1692 fs/eventpoll.c:1806 fs/eventpoll.c:2234) __x64_sys_epoll_wait (fs/eventpoll.c:2246 fs/eventpoll.c:2241 fs/eventpoll= .c:2241) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) write to 0xffff8880042f6678 of 4 bytes by task 177 on cpu 1: pipe_poll (fs/pipe.c:656) ep_item_poll.isra.0 (./include/linux/poll.h:88 fs/eventpoll.c:853) do_epoll_wait (fs/eventpoll.c:1692 fs/eventpoll.c:1806 fs/eventpoll.c:2234) __x64_sys_epoll_wait (fs/eventpoll.c:2246 fs/eventpoll.c:2241 fs/eventpoll= .c:2241) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 177 Comm: epoll_race Not tainted 5.17.0-58927-gf443e374ae13 #6 Hardware name: Red Hat KVM, BIOS 1.11.0-2.amzn2 04/01/2014 Link: https://lkml.kernel.org/r/20220322002653.33865-1-kuniyu@amazon.co.jp Link: https://lkml.kernel.org/r/20220322002653.33865-2-kuniyu@amazon.co.jp Fixes: 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal = loads") Signed-off-by: Kuniyuki Iwashima Cc: Alexander Duyck Cc: Al Viro Cc: Davidlohr Bueso Cc: Kuniyuki Iwashima Cc: "Soheil Hassas Yeganeh" Cc: "Sridhar Samudrala" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/pipe.c | 2 +- include/linux/pipe_fs_i.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -652,7 +652,7 @@ pipe_poll(struct file *filp, poll_table unsigned int head, tail; =20 /* Epoll has some historical nasty semantics, this enables them */ - pipe->poll_usage =3D 1; + WRITE_ONCE(pipe->poll_usage, true); =20 /* * Reading pipe state only -- no need for acquiring the semaphore. --- a/include/linux/pipe_fs_i.h +++ b/include/linux/pipe_fs_i.h @@ -71,7 +71,7 @@ struct pipe_inode_info { unsigned int files; unsigned int r_counter; unsigned int w_counter; - unsigned int poll_usage; + bool poll_usage; struct page *tmp_page; struct fasync_struct *fasync_readers; struct fasync_struct *fasync_writers; From nobody Tue Apr 28 06:30:15 2026 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 086E3C433EF for ; Fri, 3 Jun 2022 17:59:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346045AbiFCR7N (ORCPT ); Fri, 3 Jun 2022 13:59:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345637AbiFCRuE (ORCPT ); Fri, 3 Jun 2022 13:50:04 -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 C9596583B3; Fri, 3 Jun 2022 10:46: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 5F145B8241E; Fri, 3 Jun 2022 17:46:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1A95C385A9; Fri, 3 Jun 2022 17:46:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278368; bh=QdzVgy+7LC1eSGiAnX9qGElIAQugWzv77O5yVZ37v+c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xjxDRedMc5sdIo2SsxXLkKVdbt2/d0aKJ2lyD2vE4VcngsbNYXQmAROxcKYStH1yJ 1N+bBL1tgofsrVQe0Wa1nZr8ifrang2Iuj+dkwIRlxjG6T95I1YtMPLK4MBxf09s/W 1jRgo0RQWr+FZUc9xT8dUQaFBQqAtytvIFm7lcCc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Howells , Linus Torvalds , zdi-disclosures@trendmicro.com Subject: [PATCH 5.10 10/53] pipe: Fix missing lock in pipe_resize_ring() Date: Fri, 3 Jun 2022 19:42:55 +0200 Message-Id: <20220603173819.020461179@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 Howells commit 189b0ddc245139af81198d1a3637cac74f96e13a upstream. pipe_resize_ring() needs to take the pipe->rd_wait.lock spinlock to prevent post_one_notification() from trying to insert into the ring whilst the ring is being replaced. The occupancy check must be done after the lock is taken, and the lock must be taken after the new ring is allocated. The bug can lead to an oops looking something like: BUG: KASAN: use-after-free in post_one_notification.isra.0+0x62e/0x840 Read of size 4 at addr ffff88801cc72a70 by task poc/27196 ... Call Trace: post_one_notification.isra.0+0x62e/0x840 __post_watch_notification+0x3b7/0x650 key_create_or_update+0xb8b/0xd20 __do_sys_add_key+0x175/0x340 __x64_sys_add_key+0xbe/0x140 do_syscall_64+0x5c/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported by Selim Enes Karaduman @Enesdex working with Trend Micro Zero Day Initiative. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17291 Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/pipe.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) --- a/fs/pipe.c +++ b/fs/pipe.c @@ -1244,30 +1244,33 @@ unsigned int round_pipe_size(unsigned lo =20 /* * Resize the pipe ring to a number of slots. + * + * Note the pipe can be reduced in capacity, but only if the current + * occupancy doesn't exceed nr_slots; if it does, EBUSY will be + * returned instead. */ int pipe_resize_ring(struct pipe_inode_info *pipe, unsigned int nr_slots) { struct pipe_buffer *bufs; unsigned int head, tail, mask, n; =20 - /* - * We can shrink the pipe, if arg is greater than the ring occupancy. - * Since we don't expect a lot of shrink+grow operations, just free and - * allocate again like we would do for growing. If the pipe currently - * contains more buffers than arg, then return busy. - */ - mask =3D pipe->ring_size - 1; - head =3D pipe->head; - tail =3D pipe->tail; - n =3D pipe_occupancy(pipe->head, pipe->tail); - if (nr_slots < n) - return -EBUSY; - bufs =3D kcalloc(nr_slots, sizeof(*bufs), GFP_KERNEL_ACCOUNT | __GFP_NOWARN); if (unlikely(!bufs)) return -ENOMEM; =20 + spin_lock_irq(&pipe->rd_wait.lock); + mask =3D pipe->ring_size - 1; + head =3D pipe->head; + tail =3D pipe->tail; + + n =3D pipe_occupancy(head, tail); + if (nr_slots < n) { + spin_unlock_irq(&pipe->rd_wait.lock); + kfree(bufs); + return -EBUSY; + } + /* * The pipe array wraps around, so just start the new one at zero * and adjust the indices. @@ -1299,6 +1302,8 @@ int pipe_resize_ring(struct pipe_inode_i pipe->tail =3D tail; pipe->head =3D head; =20 + spin_unlock_irq(&pipe->rd_wait.lock); + /* This might have made more room for writers */ wake_up_interruptible(&pipe->wr_wait); return 0; From nobody Tue Apr 28 06:30:15 2026 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 28327C433EF for ; Fri, 3 Jun 2022 17:53:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343605AbiFCRxm (ORCPT ); Fri, 3 Jun 2022 13:53:42 -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 S1345680AbiFCRuF (ORCPT ); Fri, 3 Jun 2022 13:50:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 349CA580FF; Fri, 3 Jun 2022 10:46:14 -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 6805AB82419; Fri, 3 Jun 2022 17:46:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2E0DC385A9; Fri, 3 Jun 2022 17:46:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278371; bh=6Ppkon/hC2eAj/T1dzUhBA7Eve7f37CkXZaPIG8Z9Sc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ppz38QBJVFyVu4Wy/z/+k8prCoKerIqCiUJ9alXQVYNAEOLWl3mIq23kEAIEuW7PY N2d0gYBI+PNkG7EQLz43im5OzQfrnOA/2Gwh59RxcH18TAJRbFTXB9xSLYKzdIvdoD PjYM1qPU8mu4FB7tzerQYSnSmmKExA2WWMmjR1BA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miri Korenblit , Luca Coelho , Johannes Berg Subject: [PATCH 5.10 11/53] cfg80211: set custom regdomain after wiphy registration Date: Fri, 3 Jun 2022 19:42:56 +0200 Message-Id: <20220603173819.050098450@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Miri Korenblit commit 1b7b3ac8ff3317cdcf07a1c413de9bdb68019c2b upstream. We used to set regulatory info before the registration of the device and then the regulatory info didn't get set, because the device isn't registered so there isn't a device to set the regulatory info for. So set the regulatory info after the device registration. Call reg_process_self_managed_hints() once again after the device registration because it does nothing before it. Signed-off-by: Miri Korenblit Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210618133832.c96eadcffe80.I86799c= 2c866b5610b4cf91115c21d8ceb525c5aa@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- net/wireless/core.c | 8 ++++---- net/wireless/reg.c | 1 + 2 files changed, 5 insertions(+), 4 deletions(-) --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -5,7 +5,7 @@ * Copyright 2006-2010 Johannes Berg * Copyright 2013-2014 Intel Mobile Communications GmbH * Copyright 2015-2017 Intel Deutschland GmbH - * Copyright (C) 2018-2020 Intel Corporation + * Copyright (C) 2018-2021 Intel Corporation */ =20 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt @@ -918,9 +918,6 @@ int wiphy_register(struct wiphy *wiphy) return res; } =20 - /* set up regulatory info */ - wiphy_regulatory_register(wiphy); - list_add_rcu(&rdev->list, &cfg80211_rdev_list); cfg80211_rdev_list_generation++; =20 @@ -931,6 +928,9 @@ int wiphy_register(struct wiphy *wiphy) cfg80211_debugfs_rdev_add(rdev); nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY); =20 + /* set up regulatory info */ + wiphy_regulatory_register(wiphy); + if (wiphy->regulatory_flags & REGULATORY_CUSTOM_REG) { struct regulatory_request request; =20 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -4001,6 +4001,7 @@ void wiphy_regulatory_register(struct wi =20 wiphy_update_regulatory(wiphy, lr->initiator); wiphy_all_share_dfs_chan_state(wiphy); + reg_process_self_managed_hints(); } =20 void wiphy_regulatory_deregister(struct wiphy *wiphy) From nobody Tue Apr 28 06:30:15 2026 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 C8894C43334 for ; Fri, 3 Jun 2022 18:07:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347788AbiFCSGR (ORCPT ); Fri, 3 Jun 2022 14:06:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345728AbiFCRuW (ORCPT ); Fri, 3 Jun 2022 13:50:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11AEF58E78; Fri, 3 Jun 2022 10:46: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 ams.source.kernel.org (Postfix) with ESMTPS id 679A7B82433; Fri, 3 Jun 2022 17:46:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA768C385B8; Fri, 3 Jun 2022 17:46:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278374; bh=ZCDvb/lEcXJjYOpYuWAGBXcbz47R0k27Spe8HvZyXr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I1CyQyPpD0Guxj2HYmrKJPGb8btQJV/pgg+ZOjg0iDOeL9fjWQwFkBg4gAY8WpWxp y+g+sJycy7THEjUx1vD9cMQTCrq8HEQV39ATzWDbpt34c+XXRtVmJh0HLUW5UC8uPo Fyjnm/XLarHFZ97JuAnRewIQxjWdY6aB8ydxnh5k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Brennan , David Howells , Andrew Morton , keyrings@vger.kernel.org, Jarkko Sakkinen , Linus Torvalds Subject: [PATCH 5.10 12/53] assoc_array: Fix BUG_ON during garbage collect Date: Fri, 3 Jun 2022 19:42:57 +0200 Message-Id: <20220603173819.078577350@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Stephen Brennan commit d1dc87763f406d4e67caf16dbe438a5647692395 upstream. A rare BUG_ON triggered in assoc_array_gc: [3430308.818153] kernel BUG at lib/assoc_array.c:1609! Which corresponded to the statement currently at line 1593 upstream: BUG_ON(assoc_array_ptr_is_meta(p)); Using the data from the core dump, I was able to generate a userspace reproducer[1] and determine the cause of the bug. [1]: https://github.com/brenns10/kernel_stuff/tree/master/assoc_array_gc After running the iterator on the entire branch, an internal tree node looked like the following: NODE (nr_leaves_on_branch: 3) SLOT [0] NODE (2 leaves) SLOT [1] NODE (1 leaf) SLOT [2..f] NODE (empty) In the userspace reproducer, the pr_devel output when compressing this node was: -- compress node 0x5607cc089380 -- free=3D0, leaves=3D0 [0] retain node 2/1 [nx 0] [1] fold node 1/1 [nx 0] [2] fold node 0/1 [nx 2] [3] fold node 0/2 [nx 2] [4] fold node 0/3 [nx 2] [5] fold node 0/4 [nx 2] [6] fold node 0/5 [nx 2] [7] fold node 0/6 [nx 2] [8] fold node 0/7 [nx 2] [9] fold node 0/8 [nx 2] [10] fold node 0/9 [nx 2] [11] fold node 0/10 [nx 2] [12] fold node 0/11 [nx 2] [13] fold node 0/12 [nx 2] [14] fold node 0/13 [nx 2] [15] fold node 0/14 [nx 2] after: 3 At slot 0, an internal node with 2 leaves could not be folded into the node, because there was only one available slot (slot 0). Thus, the internal node was retained. At slot 1, the node had one leaf, and was able to be folded in successfully. The remaining nodes had no leaves, and so were removed. By the end of the compression stage, there were 14 free slots, and only 3 leaf nodes. The tree was ascended and then its parent node was compressed. When this node was seen, it could not be folded, due to the internal node it contained. The invariant for compression in this function is: whenever nr_leaves_on_branch < ASSOC_ARRAY_FAN_OUT, the node should contain all leaf nodes. The compression step currently cannot guarantee this, given the corner case shown above. To fix this issue, retry compression whenever we have retained a node, and yet nr_leaves_on_branch < ASSOC_ARRAY_FAN_OUT. This second compression will then allow the node in slot 1 to be folded in, satisfying the invariant. Below is the output of the reproducer once the fix is applied: -- compress node 0x560e9c562380 -- free=3D0, leaves=3D0 [0] retain node 2/1 [nx 0] [1] fold node 1/1 [nx 0] [2] fold node 0/1 [nx 2] [3] fold node 0/2 [nx 2] [4] fold node 0/3 [nx 2] [5] fold node 0/4 [nx 2] [6] fold node 0/5 [nx 2] [7] fold node 0/6 [nx 2] [8] fold node 0/7 [nx 2] [9] fold node 0/8 [nx 2] [10] fold node 0/9 [nx 2] [11] fold node 0/10 [nx 2] [12] fold node 0/11 [nx 2] [13] fold node 0/12 [nx 2] [14] fold node 0/13 [nx 2] [15] fold node 0/14 [nx 2] internal nodes remain despite enough space, retrying -- compress node 0x560e9c562380 -- free=3D14, leaves=3D1 [0] fold node 2/15 [nx 0] after: 3 Changes =3D=3D=3D=3D=3D=3D=3D DH: - Use false instead of 0. - Reorder the inserted lines in a couple of places to put retained before next_slot. ver #2) - Fix typo in pr_devel, correct comparison to "<=3D" Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Cc: Signed-off-by: Stephen Brennan Signed-off-by: David Howells cc: Andrew Morton cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20220511225517.407935-1-stephen.s.brennan@o= racle.com/ # v1 Link: https://lore.kernel.org/r/20220512215045.489140-1-stephen.s.brennan@o= racle.com/ # v2 Reviewed-by: Jarkko Sakkinen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- lib/assoc_array.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/lib/assoc_array.c +++ b/lib/assoc_array.c @@ -1462,6 +1462,7 @@ int assoc_array_gc(struct assoc_array *a struct assoc_array_ptr *cursor, *ptr; struct assoc_array_ptr *new_root, *new_parent, **new_ptr_pp; unsigned long nr_leaves_on_tree; + bool retained; int keylen, slot, nr_free, next_slot, i; =20 pr_devel("-->%s()\n", __func__); @@ -1538,6 +1539,7 @@ continue_node: goto descend; } =20 +retry_compress: pr_devel("-- compress node %p --\n", new_n); =20 /* Count up the number of empty slots in this node and work out the @@ -1555,6 +1557,7 @@ continue_node: pr_devel("free=3D%d, leaves=3D%lu\n", nr_free, new_n->nr_leaves_on_branch= ); =20 /* See what we can fold in */ + retained =3D false; next_slot =3D 0; for (slot =3D 0; slot < ASSOC_ARRAY_FAN_OUT; slot++) { struct assoc_array_shortcut *s; @@ -1604,9 +1607,14 @@ continue_node: pr_devel("[%d] retain node %lu/%d [nx %d]\n", slot, child->nr_leaves_on_branch, nr_free + 1, next_slot); + retained =3D true; } } =20 + if (retained && new_n->nr_leaves_on_branch <=3D ASSOC_ARRAY_FAN_OUT) { + pr_devel("internal nodes remain despite enough space, retrying\n"); + goto retry_compress; + } pr_devel("after: %lu\n", new_n->nr_leaves_on_branch); =20 nr_leaves_on_tree =3D new_n->nr_leaves_on_branch; From nobody Tue Apr 28 06:30:15 2026 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 1816DCCA473 for ; Fri, 3 Jun 2022 17:53:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345634AbiFCRxq (ORCPT ); Fri, 3 Jun 2022 13:53:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345775AbiFCRuZ (ORCPT ); Fri, 3 Jun 2022 13:50:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93D005908A; Fri, 3 Jun 2022 10:46: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 A9CE960A54; Fri, 3 Jun 2022 17:46:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6A18C385A9; Fri, 3 Jun 2022 17:46:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278377; bh=7oYHfS1M/s+Jkhydgv6K62l+sh0VCTWVcZ0tPKS1+5w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GUnY8gLc6+hT4+/czs/NubQ+kgjDinwwYcX01aYkKmk0997nEZTaglQslY/ODWS/i lrpd+aYQL/IZ/rKG9SIAQCiA7OQ6/K2KPj4UgJQUPgElKbFx8ldu4nDtGNOgSZegw6 YoRyK0ReVaA/dwSS/UdodUrt5I2llqSpaR5RZz9c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Pavel Begunkov Subject: [PATCH 5.10 13/53] io_uring: dont re-import iovecs from callbacks Date: Fri, 3 Jun 2022 19:42:58 +0200 Message-Id: <20220603173819.107725914@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 We can't re-import or modify iterators from iocb callbacks, it's not safe as it might be reverted and/or reexpanded while unwinding stack. It's also not safe to resubmit as io-wq thread will race with stack undwinding for the iterator and other data. Disallow resubmission from callbacks, it can fail some cases that were handled before, but the possibility of such a failure was a part of the API from the beginning and so it should be fine. Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/io_uring.c | 39 --------------------------------------- 1 file changed, 39 deletions(-) --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -2579,45 +2579,6 @@ static void io_complete_rw_common(struct #ifdef CONFIG_BLOCK static bool io_resubmit_prep(struct io_kiocb *req, int error) { - struct iovec inline_vecs[UIO_FASTIOV], *iovec =3D inline_vecs; - ssize_t ret =3D -ECANCELED; - struct iov_iter iter; - int rw; - - if (error) { - ret =3D error; - goto end_req; - } - - switch (req->opcode) { - case IORING_OP_READV: - case IORING_OP_READ_FIXED: - case IORING_OP_READ: - rw =3D READ; - break; - case IORING_OP_WRITEV: - case IORING_OP_WRITE_FIXED: - case IORING_OP_WRITE: - rw =3D WRITE; - break; - default: - printk_once(KERN_WARNING "io_uring: bad opcode in resubmit %d\n", - req->opcode); - goto end_req; - } - - if (!req->async_data) { - ret =3D io_import_iovec(rw, req, &iovec, &iter, false); - if (ret < 0) - goto end_req; - ret =3D io_setup_async_rw(req, iovec, inline_vecs, &iter, false); - if (!ret) - return true; - kfree(iovec); - } else { - return true; - } -end_req: req_set_fail_links(req); return false; } From nobody Tue Apr 28 06:30:15 2026 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 42C04C433EF for ; Fri, 3 Jun 2022 17:56:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343788AbiFCR4I (ORCPT ); Fri, 3 Jun 2022 13:56:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345815AbiFCRu1 (ORCPT ); Fri, 3 Jun 2022 13:50: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 E8E4F590BE; Fri, 3 Jun 2022 10:46: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 ams.source.kernel.org (Postfix) with ESMTPS id 60FE7B82430; Fri, 3 Jun 2022 17:46:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C92DC385A9; Fri, 3 Jun 2022 17:46:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278380; bh=EZhGGfDHtywe2gnNldpG1wtwGHl1pTHgN+kbhnSDUkA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eFQvZLegxb7+4d4sPSHdw2Ve3AGz9Wbhq7rVH6EEcN1YkM25dqNWyhyvsjKJ6w8H8 Kcjy1YUErzGzjm1A9sIaiX2ZfmKxv1WG1GVjFdbQBKe3Hl+j1DcpQKVomn8otE+JaU WrsF774pm6FQ7u1lTlcOhXEprP1dQ4NO4j0DFd0Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Pavel Begunkov Subject: [PATCH 5.10 14/53] io_uring: fix using under-expanded iters Date: Fri, 3 Jun 2022 19:42:59 +0200 Message-Id: <20220603173819.137177057@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 [ upstream commit cd65869512ab5668a5d16f789bc4da1319c435c4 ] The issue was first described and addressed in 89c2b3b7491820 ("io_uring: reexpand under-reexpanded iters"), but shortly after reimplemented as. cd65869512ab56 ("io_uring: use iov_iter state save/restore helpers"). Here we follow the approach from the second patch but without in-callback resubmissions, fixups for not yet supported in 5.10 short read retries and replacing iov_iter_state with iter copies to not pull even more dependencies, and because it's just much simpler. Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/io_uring.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -3389,6 +3389,7 @@ static int io_read(struct io_kiocb *req, struct iovec inline_vecs[UIO_FASTIOV], *iovec =3D inline_vecs; struct kiocb *kiocb =3D &req->rw.kiocb; struct iov_iter __iter, *iter =3D &__iter; + struct iov_iter iter_cp; struct io_async_rw *rw =3D req->async_data; ssize_t io_size, ret, ret2; bool no_async; @@ -3399,6 +3400,7 @@ static int io_read(struct io_kiocb *req, ret =3D io_import_iovec(READ, req, &iovec, iter, !force_nonblock); if (ret < 0) return ret; + iter_cp =3D *iter; io_size =3D iov_iter_count(iter); req->result =3D io_size; ret =3D 0; @@ -3434,7 +3436,7 @@ static int io_read(struct io_kiocb *req, if (req->file->f_flags & O_NONBLOCK) goto done; /* some cases will consume bytes even on error returns */ - iov_iter_revert(iter, io_size - iov_iter_count(iter)); + *iter =3D iter_cp; ret =3D 0; goto copy_iov; } else if (ret < 0) { @@ -3517,6 +3519,7 @@ static int io_write(struct io_kiocb *req struct iovec inline_vecs[UIO_FASTIOV], *iovec =3D inline_vecs; struct kiocb *kiocb =3D &req->rw.kiocb; struct iov_iter __iter, *iter =3D &__iter; + struct iov_iter iter_cp; struct io_async_rw *rw =3D req->async_data; ssize_t ret, ret2, io_size; =20 @@ -3526,6 +3529,7 @@ static int io_write(struct io_kiocb *req ret =3D io_import_iovec(WRITE, req, &iovec, iter, !force_nonblock); if (ret < 0) return ret; + iter_cp =3D *iter; io_size =3D iov_iter_count(iter); req->result =3D io_size; =20 @@ -3587,7 +3591,7 @@ done: } else { copy_iov: /* some cases will consume bytes even on error returns */ - iov_iter_revert(iter, io_size - iov_iter_count(iter)); + *iter =3D iter_cp; ret =3D io_setup_async_rw(req, iovec, inline_vecs, iter, false); if (!ret) return -EAGAIN; From nobody Tue Apr 28 06:30:15 2026 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 49DECC43334 for ; Fri, 3 Jun 2022 17:53:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229791AbiFCRxx (ORCPT ); Fri, 3 Jun 2022 13:53:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345843AbiFCRu3 (ORCPT ); Fri, 3 Jun 2022 13:50: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 1CAA759098; Fri, 3 Jun 2022 10:46: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 ams.source.kernel.org (Postfix) with ESMTPS id 37550B82419; Fri, 3 Jun 2022 17:46:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A558AC385A9; Fri, 3 Jun 2022 17:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278383; bh=6QoHrvU2xYQ1erhdoXN7xFpKRR4cBbfChEisOA3+u3Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oEyl2562yXzhy97oE46KROJFxm4YpmfJ7X8D7y9Xa5R2nWI0poiecxMEtpNCpVY9L UMvYf5SmKOf6qrb1aM14cYA4HmG0Qn2eZqsuLwKx7I+nSt2t+rmUW5GbD+v2wRFJxJ A86qNAWVXB7iATwXa1T29aEIh4vv+MNIUxcekK4Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alex Elder , "David S. Miller" Subject: [PATCH 5.10 15/53] net: ipa: compute proper aggregation limit Date: Fri, 3 Jun 2022 19:43:00 +0200 Message-Id: <20220603173819.166285071@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Alex Elder commit c5794097b269f15961ed78f7f27b50e51766dec9 upstream. The aggregation byte limit for an endpoint is currently computed based on the endpoint's receive buffer size. However, some bytes at the front of each receive buffer are reserved on the assumption that--as with SKBs--it might be useful to insert data (such as headers) before what lands in the buffer. The aggregation byte limit currently doesn't take into account that reserved space, and as a result, aggregation could require space past that which is available in the buffer. Fix this by reducing the size used to compute the aggregation byte limit by the NET_SKB_PAD offset reserved for each receive buffer. Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/net/ipa/ipa_endpoint.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/net/ipa/ipa_endpoint.c +++ b/drivers/net/ipa/ipa_endpoint.c @@ -610,12 +610,14 @@ static void ipa_endpoint_init_aggr(struc =20 if (endpoint->data->aggregation) { if (!endpoint->toward_ipa) { + u32 buffer_size; u32 limit; =20 val |=3D u32_encode_bits(IPA_ENABLE_AGGR, AGGR_EN_FMASK); val |=3D u32_encode_bits(IPA_GENERIC, AGGR_TYPE_FMASK); =20 - limit =3D ipa_aggr_size_kb(IPA_RX_BUFFER_SIZE); + buffer_size =3D IPA_RX_BUFFER_SIZE - NET_SKB_PAD; + limit =3D ipa_aggr_size_kb(buffer_size); val |=3D u32_encode_bits(limit, AGGR_BYTE_LIMIT_FMASK); =20 limit =3D IPA_AGGR_TIME_LIMIT_DEFAULT; From nobody Tue Apr 28 06:30:15 2026 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 9EDE3C433EF for ; Fri, 3 Jun 2022 17:54:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238386AbiFCRyD (ORCPT ); Fri, 3 Jun 2022 13:54:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345844AbiFCRu3 (ORCPT ); Fri, 3 Jun 2022 13:50:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5345B59320; Fri, 3 Jun 2022 10:46:27 -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 9E6AD60A24; Fri, 3 Jun 2022 17:46:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83E8DC385B8; Fri, 3 Jun 2022 17:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278386; bh=ckAXMjdtX0ur87WUhgGjR/BsA7WVjQYxbNCalliwZs8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UAtTWNbyZBv//mlVQJbgoqVRxRNv4/0SdOP29eHkssr4j0rfw8Qi7s2dMDWqaKuAA Z0ickdhdI+syb9Bi839L1BKTv0HqmTZ3Pstj39o/mSL4VCsC1nMJyZBf0r87xN4jdF 0d9y1uiOMvoFA5WObEapsrDk/259EmrLKrRp37pM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Christoph Hellwig , Amir Goldstein Subject: [PATCH 5.10 16/53] xfs: detect overflows in bmbt records Date: Fri, 3 Jun 2022 19:43:01 +0200 Message-Id: <20220603173819.194392585@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: "Darrick J. Wong" commit acf104c2331c1ba2a667e65dd36139d1555b1432 upstream. Detect file block mappings with a blockcount that's either so large that integer overflows occur or are zero, because neither are valid in the filesystem. Worse yet, attempting directory modifications causes the iext code to trip over the bmbt key handling and takes the filesystem down. We can fix most of this by preventing the bad metadata from entering the incore structures in the first place. Found by setting blockcount=3D0 in a directory data fork mapping and watching the fireworks. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/xfs/libxfs/xfs_bmap.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -6229,6 +6229,11 @@ xfs_bmap_validate_extent( xfs_fsblock_t endfsb; bool isrt; =20 + if (irec->br_startblock + irec->br_blockcount <=3D irec->br_startblock) + return __this_address; + if (irec->br_startoff + irec->br_blockcount <=3D irec->br_startoff) + return __this_address; + isrt =3D XFS_IS_REALTIME_INODE(ip); endfsb =3D irec->br_startblock + irec->br_blockcount - 1; if (isrt && whichfork =3D=3D XFS_DATA_FORK) { From nobody Tue Apr 28 06:30:15 2026 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 840C1CCA47E for ; Fri, 3 Jun 2022 17:54:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345671AbiFCRyK (ORCPT ); Fri, 3 Jun 2022 13:54:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345872AbiFCRua (ORCPT ); Fri, 3 Jun 2022 13:50:30 -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 201F65933F; Fri, 3 Jun 2022 10:46:30 -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 70EFC60A57; Fri, 3 Jun 2022 17:46:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E796C385A9; Fri, 3 Jun 2022 17:46:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278388; bh=zaNu4u8ZaPQGvMyvHFFFYGlt7YAl54KciriYinCwh/Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZqVVgDKRRraO8zsEVzG0d+ctJW6Z9gqqo9vlmU2UYNSKItrgHap7/Nr/J3VnGNNBv LayCk0rQlVksZ2jiCfxZBpfqgPBh8Lg40eseOGjOTvkQzqHPNXfD1dxD+ST8W9DNJi Ho701F1SUeC5ynvsNC6u4kUU5lc5GTt8lOXrxsXY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kaixu Xia , "Darrick J. Wong" , Amir Goldstein Subject: [PATCH 5.10 17/53] xfs: show the proper user quota options Date: Fri, 3 Jun 2022 19:43:02 +0200 Message-Id: <20220603173819.223798717@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Kaixu Xia commit 237d7887ae723af7d978e8b9a385fdff416f357b upstream. The quota option 'usrquota' should be shown if both the XFS_UQUOTA_ACCT and XFS_UQUOTA_ENFD flags are set. The option 'uqnoenforce' should be shown when only the XFS_UQUOTA_ACCT flag is set. The current code logic seems wrong, Fix it and show proper options. Signed-off-by: Kaixu Xia Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/xfs/xfs_super.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -199,10 +199,12 @@ xfs_fs_show_options( seq_printf(m, ",swidth=3D%d", (int)XFS_FSB_TO_BB(mp, mp->m_swidth)); =20 - if (mp->m_qflags & (XFS_UQUOTA_ACCT|XFS_UQUOTA_ENFD)) - seq_puts(m, ",usrquota"); - else if (mp->m_qflags & XFS_UQUOTA_ACCT) - seq_puts(m, ",uqnoenforce"); + if (mp->m_qflags & XFS_UQUOTA_ACCT) { + if (mp->m_qflags & XFS_UQUOTA_ENFD) + seq_puts(m, ",usrquota"); + else + seq_puts(m, ",uqnoenforce"); + } =20 if (mp->m_qflags & XFS_PQUOTA_ACCT) { if (mp->m_qflags & XFS_PQUOTA_ENFD) From nobody Tue Apr 28 06:30:15 2026 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 D12C5C433EF for ; Fri, 3 Jun 2022 18:07:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346772AbiFCSFJ (ORCPT ); Fri, 3 Jun 2022 14:05:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346589AbiFCRvS (ORCPT ); Fri, 3 Jun 2022 13:51:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26B1A5713A; Fri, 3 Jun 2022 10:48: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 A90B960F4E; Fri, 3 Jun 2022 17:48:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B257FC385A9; Fri, 3 Jun 2022 17:48:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278526; bh=Lht8QSy6hA4TSjRiwmuGl45bCsuNlAPJMnkNYDOgl4Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SwYyg7s9S9Kfs5oLQvNc+RPngBKYkNXqdz4iOBRi51f5b/dV8rIsrXcM66j5Hlqk2 eGf5ZYBHXyDVhRmPvJLzXM5v7UTftVxZN4q2tz3fjxeJ1kHvJUUvyk35Y8wibw0Ilk dbHKq1gxqDG+bZ/qpWNSyiKM3/G+oQ/66W0I6Dps= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, zlang@redhat.com, "Darrick J. Wong" , Dave Chinner , Amir Goldstein Subject: [PATCH 5.10 18/53] xfs: fix the forward progress assertion in xfs_iwalk_run_callbacks Date: Fri, 3 Jun 2022 19:43:03 +0200 Message-Id: <20220603173819.252657254@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: "Darrick J. Wong" commit a5336d6bb2d02d0e9d4d3c8be04b80b8b68d56c8 upstream. In commit 27c14b5daa82 we started tracking the last inode seen during an inode walk to avoid infinite loops if a corrupt inobt record happens to have a lower ir_startino than the record preceeding it. Unfortunately, the assertion trips over the case where there are completely empty inobt records (which can happen quite easily on 64k page filesystems) because we advance the tracking cursor without actually putting the empty record into the processing buffer. Fix the assert to allow for this case. Reported-by: zlang@redhat.com Fixes: 27c14b5daa82 ("xfs: ensure inobt record walks always make forward pr= ogress") Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/xfs/xfs_iwalk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/xfs/xfs_iwalk.c +++ b/fs/xfs/xfs_iwalk.c @@ -363,7 +363,7 @@ xfs_iwalk_run_callbacks( /* Delete cursor but remember the last record we cached... */ xfs_iwalk_del_inobt(tp, curpp, agi_bpp, 0); irec =3D &iwag->recs[iwag->nr_recs - 1]; - ASSERT(next_agino =3D=3D irec->ir_startino + XFS_INODES_PER_CHUNK); + ASSERT(next_agino >=3D irec->ir_startino + XFS_INODES_PER_CHUNK); =20 error =3D xfs_iwalk_ag_recs(iwag); if (error) From nobody Tue Apr 28 06:30:15 2026 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 7A46ECCA485 for ; Fri, 3 Jun 2022 17:55:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345800AbiFCRzE (ORCPT ); Fri, 3 Jun 2022 13:55:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346054AbiFCRun (ORCPT ); Fri, 3 Jun 2022 13:50:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5642759957; Fri, 3 Jun 2022 10:47: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 9FF19B82189; Fri, 3 Jun 2022 17:47:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1B43C385B8; Fri, 3 Jun 2022 17:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278419; bh=UOFBYAakdIJ+1sH6HasaLcTD8QNltxa0AK81YZwjH1k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mr9cHeCAucvQdvof/ykmbvcPlN76/OCkQVAcu4viy6NKZ7RXOPZ3EoVdrXEvqkjEY I7h00aBMudMEJHmX4NOSu+tDcEzlkcQnN5uqP7cZB5zL6bDd+1J1NsyLTr0gxwFwpt nFx+G6Umg6cGSyPrNRtpLppDXxoRSn0KodIJmwOE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, wenli xie , "Darrick J. Wong" , Brian Foster , Amir Goldstein Subject: [PATCH 5.10 19/53] xfs: fix an ABBA deadlock in xfs_rename Date: Fri, 3 Jun 2022 19:43:04 +0200 Message-Id: <20220603173819.282169316@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: "Darrick J. Wong" commit 6da1b4b1ab36d80a3994fd4811c8381de10af604 upstream. When overlayfs is running on top of xfs and the user unlinks a file in the overlay, overlayfs will create a whiteout inode and ask xfs to "rename" the whiteout file atop the one being unlinked. If the file being unlinked loses its one nlink, we then have to put the inode on the unlinked list. This requires us to grab the AGI buffer of the whiteout inode to take it off the unlinked list (which is where whiteouts are created) and to grab the AGI buffer of the file being deleted. If the whiteout was created in a higher numbered AG than the file being deleted, we'll lock the AGIs in the wrong order and deadlock. Therefore, grab all the AGI locks we think we'll need ahead of time, and in order of increasing AG number per the locking rules. Reported-by: wenli xie Fixes: 93597ae8dac0 ("xfs: Fix deadlock between AGI and AGF when target_ip = exists in xfs_rename()") Signed-off-by: Darrick J. Wong Reviewed-by: Brian Foster Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/xfs/libxfs/xfs_dir2.h | 2 -- fs/xfs/libxfs/xfs_dir2_sf.c | 2 +- fs/xfs/xfs_inode.c | 42 +++++++++++++++++++++++++--------------= --- 3 files changed, 26 insertions(+), 20 deletions(-) --- a/fs/xfs/libxfs/xfs_dir2.h +++ b/fs/xfs/libxfs/xfs_dir2.h @@ -47,8 +47,6 @@ extern int xfs_dir_lookup(struct xfs_tra extern int xfs_dir_removename(struct xfs_trans *tp, struct xfs_inode *dp, struct xfs_name *name, xfs_ino_t ino, xfs_extlen_t tot); -extern bool xfs_dir2_sf_replace_needblock(struct xfs_inode *dp, - xfs_ino_t inum); extern int xfs_dir_replace(struct xfs_trans *tp, struct xfs_inode *dp, struct xfs_name *name, xfs_ino_t inum, xfs_extlen_t tot); --- a/fs/xfs/libxfs/xfs_dir2_sf.c +++ b/fs/xfs/libxfs/xfs_dir2_sf.c @@ -1018,7 +1018,7 @@ xfs_dir2_sf_removename( /* * Check whether the sf dir replace operation need more blocks. */ -bool +static bool xfs_dir2_sf_replace_needblock( struct xfs_inode *dp, xfs_ino_t inum) --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -3152,7 +3152,7 @@ xfs_rename( struct xfs_trans *tp; struct xfs_inode *wip =3D NULL; /* whiteout inode */ struct xfs_inode *inodes[__XFS_SORT_INODES]; - struct xfs_buf *agibp; + int i; int num_inodes =3D __XFS_SORT_INODES; bool new_parent =3D (src_dp !=3D target_dp); bool src_is_directory =3D S_ISDIR(VFS_I(src_ip)->i_mode); @@ -3266,6 +3266,30 @@ xfs_rename( } =20 /* + * Lock the AGI buffers we need to handle bumping the nlink of the + * whiteout inode off the unlinked list and to handle dropping the + * nlink of the target inode. Per locking order rules, do this in + * increasing AG order and before directory block allocation tries to + * grab AGFs because we grab AGIs before AGFs. + * + * The (vfs) caller must ensure that if src is a directory then + * target_ip is either null or an empty directory. + */ + for (i =3D 0; i < num_inodes && inodes[i] !=3D NULL; i++) { + if (inodes[i] =3D=3D wip || + (inodes[i] =3D=3D target_ip && + (VFS_I(target_ip)->i_nlink =3D=3D 1 || src_is_directory))) { + struct xfs_buf *bp; + xfs_agnumber_t agno; + + agno =3D XFS_INO_TO_AGNO(mp, inodes[i]->i_ino); + error =3D xfs_read_agi(mp, tp, agno, &bp); + if (error) + goto out_trans_cancel; + } + } + + /* * Directory entry creation below may acquire the AGF. Remove * the whiteout from the unlinked list first to preserve correct * AGI/AGF locking order. This dirties the transaction so failures @@ -3317,22 +3341,6 @@ xfs_rename( * In case there is already an entry with the same * name at the destination directory, remove it first. */ - - /* - * Check whether the replace operation will need to allocate - * blocks. This happens when the shortform directory lacks - * space and we have to convert it to a block format directory. - * When more blocks are necessary, we must lock the AGI first - * to preserve locking order (AGI -> AGF). - */ - if (xfs_dir2_sf_replace_needblock(target_dp, src_ip->i_ino)) { - error =3D xfs_read_agi(mp, tp, - XFS_INO_TO_AGNO(mp, target_ip->i_ino), - &agibp); - if (error) - goto out_trans_cancel; - } - error =3D xfs_dir_replace(tp, target_dp, target_name, src_ip->i_ino, spaceres); if (error) From nobody Tue Apr 28 06:30:15 2026 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 6D675C43334 for ; Fri, 3 Jun 2022 17:59:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234941AbiFCR7t (ORCPT ); Fri, 3 Jun 2022 13:59:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346326AbiFCRvE (ORCPT ); Fri, 3 Jun 2022 13:51:04 -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 E6AEA54019; Fri, 3 Jun 2022 10:47:35 -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 83445B82419; Fri, 3 Jun 2022 17:47:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D48E5C385A9; Fri, 3 Jun 2022 17:47:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278453; bh=xKYIY3b+6DACVG9OJ+6g0WzZhtJPvFTJ0v8snVh1XI8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k+Y1O9J9xxi0HESonAXfwB5J3fbzSwEs+NEKdFZhq+pzoKFvwbhptQWZXdxOELm2G BD2xzANDdHmOGoe/wOOo6DfB82MinPjsWUIkUfkqc2xVH9sVmceH0XBdraR6WcNIrp m57SWJgmptP2rPm/V5wrVeDzPw3LQtElxuKpq4Fw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Chinner , Brian Foster , Chandan Babu R , "Darrick J. Wong" , Allison Henderson , Christoph Hellwig , Donald Buczek Subject: [PATCH 5.10 20/53] xfs: Fix CIL throttle hang when CIL space used going backwards Date: Fri, 3 Jun 2022 19:43:05 +0200 Message-Id: <20220603173819.311191622@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Dave Chinner commit 19f4e7cc819771812a7f527d7897c2deffbf7a00 upstream. A hang with tasks stuck on the CIL hard throttle was reported and largely diagnosed by Donald Buczek, who discovered that it was a result of the CIL context space usage decrementing in committed transactions once the hard throttle limit had been hit and processes were already blocked. This resulted in the CIL push not waking up those waiters because the CIL context was no longer over the hard throttle limit. The surprising aspect of this was the CIL space usage going backwards regularly enough to trigger this situation. Assumptions had been made in design that the relogging process would only increase the size of the objects in the CIL, and so that space would only increase. This change and commit message fixes the issue and documents the result of an audit of the triggers that can cause the CIL space to go backwards, how large the backwards steps tend to be, the frequency in which they occur, and what the impact on the CIL accounting code is. Even though the CIL ctx->space_used can go backwards, it will only do so if the log item is already logged to the CIL and contains a space reservation for it's entire logged state. This is tracked by the shadow buffer state on the log item. If the item is not previously logged in the CIL it has no shadow buffer nor log vector, and hence the entire size of the logged item copied to the log vector is accounted to the CIL space usage. i.e. it will always go up in this case. If the item has a log vector (i.e. already in the CIL) and the size decreases, then the existing log vector will be overwritten and the space usage will go down. This is the only condition where the space usage reduces, and it can only occur when an item is already tracked in the CIL. Hence we are safe from CIL space usage underruns as a result of log items decreasing in size when they are relogged. Typically this reduction in CIL usage occurs from metadata blocks being free, such as when a btree block merge occurs or a directory enter/xattr entry is removed and the da-tree is reduced in size. This generally results in a reduction in size of around a single block in the CIL, but also tends to increase the number of log vectors because the parent and sibling nodes in the tree needs to be updated when a btree block is removed. If a multi-level merge occurs, then we see reduction in size of 2+ blocks, but again the log vector count goes up. The other vector is inode fork size changes, which only log the current size of the fork and ignore the previously logged size when the fork is relogged. Hence if we are removing items from the inode fork (dir/xattr removal in shortform, extent record removal in extent form, etc) the relogged size of the inode for can decrease. No other log items can decrease in size either because they are a fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging an intent actually creates a new intent log item and doesn't relog the old item at all.) Hence the only two vectors for CIL context size reduction are relogging inode forks and marking buffers active in the CIL as stale. Long story short: the majority of the code does the right thing and handles the reduction in log item size correctly, and only the CIL hard throttle implementation is problematic and needs fixing. This patch makes that fix, as well as adds comments in the log item code that result in items shrinking in size when they are relogged as a clear reminder that this can and does happen frequently. The throttle fix is based upon the change Donald proposed, though it goes further to ensure that once the throttle is activated, it captures all tasks until the CIL push issues a wakeup, regardless of whether the CIL space used has gone back under the throttle threshold. This ensures that we prevent tasks reducing the CIL slightly under the throttle threshold and then making more changes that push it well over the throttle limit. This is acheived by checking if the throttle wait queue is already active as a condition of throttling. Hence once we start throttling, we continue to apply the throttle until the CIL context push wakes everything on the wait queue. We can use waitqueue_active() for the waitqueue manipulations and checks as they are all done under the ctx->xc_push_lock. Hence the waitqueue has external serialisation and we can safely peek inside the wait queue without holding the internal waitqueue locks. Many thanks to Donald for his diagnostic and analysis work to isolate the cause of this hang. Reported-and-tested-by: Donald Buczek Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Chandan Babu R Reviewed-by: Darrick J. Wong Reviewed-by: Allison Henderson Signed-off-by: Darrick J. Wong Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/xfs/xfs_buf_item.c | 37 ++++++++++++++++++------------------- fs/xfs/xfs_inode_item.c | 14 ++++++++++++++ fs/xfs/xfs_log_cil.c | 22 +++++++++++++++++----- 3 files changed, 49 insertions(+), 24 deletions(-) --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -56,14 +56,12 @@ xfs_buf_log_format_size( } =20 /* - * This returns the number of log iovecs needed to log the - * given buf log item. + * Return the number of log iovecs and space needed to log the given buf l= og + * item segment. * - * It calculates this as 1 iovec for the buf log format structure - * and 1 for each stretch of non-contiguous chunks to be logged. - * Contiguous chunks are logged in a single iovec. - * - * If the XFS_BLI_STALE flag has been set, then log nothing. + * It calculates this as 1 iovec for the buf log format structure and 1 fo= r each + * stretch of non-contiguous chunks to be logged. Contiguous chunks are l= ogged + * in a single iovec. */ STATIC void xfs_buf_item_size_segment( @@ -119,11 +117,8 @@ xfs_buf_item_size_segment( } =20 /* - * This returns the number of log iovecs needed to log the given buf log i= tem. - * - * It calculates this as 1 iovec for the buf log format structure and 1 fo= r each - * stretch of non-contiguous chunks to be logged. Contiguous chunks are l= ogged - * in a single iovec. + * Return the number of log iovecs and space needed to log the given buf l= og + * item. * * Discontiguous buffers need a format structure per region that is being * logged. This makes the changes in the buffer appear to log recovery as = though @@ -133,7 +128,11 @@ xfs_buf_item_size_segment( * what ends up on disk. * * If the XFS_BLI_STALE flag has been set, then log nothing but the buf log - * format structures. + * format structures. If the item has previously been logged and has dirty + * regions, we do not relog them in stale buffers. This has the effect of + * reducing the size of the relogged item by the amount of dirty data trac= ked + * by the log item. This can result in the committing transaction reducing= the + * amount of space being consumed by the CIL. */ STATIC void xfs_buf_item_size( @@ -147,9 +146,9 @@ xfs_buf_item_size( ASSERT(atomic_read(&bip->bli_refcount) > 0); if (bip->bli_flags & XFS_BLI_STALE) { /* - * The buffer is stale, so all we need to log - * is the buf log format structure with the - * cancel flag in it. + * The buffer is stale, so all we need to log is the buf log + * format structure with the cancel flag in it as we are never + * going to replay the changes tracked in the log item. */ trace_xfs_buf_item_size_stale(bip); ASSERT(bip->__bli_format.blf_flags & XFS_BLF_CANCEL); @@ -164,9 +163,9 @@ xfs_buf_item_size( =20 if (bip->bli_flags & XFS_BLI_ORDERED) { /* - * The buffer has been logged just to order it. - * It is not being included in the transaction - * commit, so no vectors are used at all. + * The buffer has been logged just to order it. It is not being + * included in the transaction commit, so no vectors are used at + * all. */ trace_xfs_buf_item_size_ordered(bip); *nvecs =3D XFS_LOG_VEC_ORDERED; --- a/fs/xfs/xfs_inode_item.c +++ b/fs/xfs/xfs_inode_item.c @@ -28,6 +28,20 @@ static inline struct xfs_inode_log_item return container_of(lip, struct xfs_inode_log_item, ili_item); } =20 +/* + * The logged size of an inode fork is always the current size of the inode + * fork. This means that when an inode fork is relogged, the size of the l= ogged + * region is determined by the current state, not the combination of the + * previously logged state + the current state. This is different relogging + * behaviour to most other log items which will retain the size of the + * previously logged changes when smaller regions are relogged. + * + * Hence operations that remove data from the inode fork (e.g. shortform + * dir/attr remove, extent form extent removal, etc), the size of the relo= gged + * inode gets -smaller- rather than stays the same size as the previously = logged + * size and this can result in the committing transaction reducing the amo= unt of + * space being consumed by the CIL. + */ STATIC void xfs_inode_item_data_fork_size( struct xfs_inode_log_item *iip, --- a/fs/xfs/xfs_log_cil.c +++ b/fs/xfs/xfs_log_cil.c @@ -668,9 +668,14 @@ xlog_cil_push_work( ASSERT(push_seq <=3D ctx->sequence); =20 /* - * Wake up any background push waiters now this context is being pushed. + * As we are about to switch to a new, empty CIL context, we no longer + * need to throttle tasks on CIL space overruns. Wake any waiters that + * the hard push throttle may have caught so they can start committing + * to the new context. The ctx->xc_push_lock provides the serialisation + * necessary for safely using the lockless waitqueue_active() check in + * this context. */ - if (ctx->space_used >=3D XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) + if (waitqueue_active(&cil->xc_push_wait)) wake_up_all(&cil->xc_push_wait); =20 /* @@ -907,7 +912,7 @@ xlog_cil_push_background( ASSERT(!list_empty(&cil->xc_cil)); =20 /* - * don't do a background push if we haven't used up all the + * Don't do a background push if we haven't used up all the * space available yet. */ if (cil->xc_ctx->space_used < XLOG_CIL_SPACE_LIMIT(log)) { @@ -931,9 +936,16 @@ xlog_cil_push_background( =20 /* * If we are well over the space limit, throttle the work that is being - * done until the push work on this context has begun. + * done until the push work on this context has begun. Enforce the hard + * throttle on all transaction commits once it has been activated, even + * if the committing transactions have resulted in the space usage + * dipping back down under the hard limit. + * + * The ctx->xc_push_lock provides the serialisation necessary for safely + * using the lockless waitqueue_active() check in this context. */ - if (cil->xc_ctx->space_used >=3D XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) { + if (cil->xc_ctx->space_used >=3D XLOG_CIL_BLOCKING_SPACE_LIMIT(log) || + waitqueue_active(&cil->xc_push_wait)) { trace_xfs_log_cil_wait(log, cil->xc_ctx->ticket); ASSERT(cil->xc_ctx->space_used < log->l_logsize); xlog_wait(&cil->xc_push_wait, &cil->xc_push_lock); From nobody Tue Apr 28 06:30:15 2026 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 745ECCCA47C for ; Fri, 3 Jun 2022 17:56:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345886AbiFCR4p (ORCPT ); Fri, 3 Jun 2022 13:56:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346422AbiFCRvJ (ORCPT ); Fri, 3 Jun 2022 13:51:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7550F53726; Fri, 3 Jun 2022 10:48: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 dfw.source.kernel.org (Postfix) with ESMTPS id 112DF60F3B; Fri, 3 Jun 2022 17:48:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F35C2C385A9; Fri, 3 Jun 2022 17:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278486; bh=gdpuj4BS15+mxIcnIpId4JL7JAXR0GkknTGFgebL6Zc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KLlSZ04NARNLGJRHnV+EvnjiBUTD3nLo4s+22NtuHB+G7bTjTk/0UbPYK4UHJcLGJ ExAXib+B17y5CHMw0FmfCMAh7p8x4gXmFfRlGHYEZCP9hKoS6+E21Xmo3F94HdnC+o fQn0PBaWnP/ybcx4voE6iBFXlSrcEP6l1WbC9ZlM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Gustavo A. R. Silva" Subject: [PATCH 5.10 21/53] drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() Date: Fri, 3 Jun 2022 19:43:06 +0200 Message-Id: <20220603173819.341399118@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Gustavo A. R. Silva commit 336feb502a715909a8136eb6a62a83d7268a353b upstream. Fix the following -Wstringop-overflow warnings when building with GCC-11: drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: =E2=80=98intel_read_wm_lat= ency=E2=80=99 accessing 16 bytes in a region of size 10 [-Wstringop-overflo= w=3D] 3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of typ= e =E2=80=98u16 *=E2=80=99 {aka =E2=80=98short unsigned int *=E2=80=99} drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function =E2=80= =98intel_read_wm_latency=E2=80=99 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, | ^~~~~~~~~~~~~~~~~~~~~ by removing the over-specified array size from the argument declarations. It seems that this code is actually safe because the size of the array depends on the hardware generation, and the function checks for that. Notice that wm can be an array of 5 elements: drivers/gpu/drm/i915/intel_pm.c:3109: intel_read_wm_latency(dev_priv, dev= _priv->wm.pri_latency); or an array of 8 elements: drivers/gpu/drm/i915/intel_pm.c:3131: intel_read_wm_latency(dev_priv, dev= _priv->wm.skl_latency); and the compiler legitimately complains about that. This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2846,7 +2846,7 @@ static void ilk_compute_wm_level(const s } =20 static void intel_read_wm_latency(struct drm_i915_private *dev_priv, - u16 wm[8]) + u16 wm[]) { struct intel_uncore *uncore =3D &dev_priv->uncore; =20 From nobody Tue Apr 28 06:30:15 2026 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 864E3C433EF for ; Fri, 3 Jun 2022 17:57:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345871AbiFCR5Y (ORCPT ); Fri, 3 Jun 2022 13:57:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346545AbiFCRvQ (ORCPT ); Fri, 3 Jun 2022 13:51:16 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC58C56F90; Fri, 3 Jun 2022 10:48:30 -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 98070B8241D; Fri, 3 Jun 2022 17:48:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4342C385B8; Fri, 3 Jun 2022 17:48:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278508; bh=0AmZgFQDiQC+4i1zT87EYUcy6yVZrjKk6HpDT42EJ8A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a91DguOprLUkEI6BYiaWGRebNEmK/Yup3ENG5RtWi2i0iTx7sCo6di4QW6Iq8Xyo5 AoXyoDmPQNjl4er9JujF/5tW17UnfkWkPwi9OYrPiwN7ZC8FIEXlXcI2yCkXUFk0GI JQoxZHIBLiqJ2E0K/8k2jmrGNvq3c6HmDBVPSCT4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+a4087e40b9c13aad7892@syzkaller.appspotmail.com, Tadeusz Struk , Sungjong Seo , Namjae Jeon Subject: [PATCH 5.10 22/53] exfat: check if cluster num is valid Date: Fri, 3 Jun 2022 19:43:07 +0200 Message-Id: <20220603173819.370000347@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Tadeusz Struk commit 64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d upstream. Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap. This was triggered by reproducer calling truncute with size 0, which causes the following trace: BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/b= alloc.c:174 Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65 Move the is_valid_cluster() helper from fatent.c to a common header to make it reusable in other *.c files. And add is_valid_cluster() to validate if cluster number is within valid range in exfat_clear_bitmap() and exfat_set_bitmap(). Link: https://syzkaller.appspot.com/bug?id=3D50381fc73821ecae743b8cf24b4c9a= 04776f767c Reported-by: syzbot+a4087e40b9c13aad7892@syzkaller.appspotmail.com Fixes: 1e49a94cf707 ("exfat: add bitmap operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Tadeusz Struk Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/exfat/balloc.c | 8 ++++++-- fs/exfat/exfat_fs.h | 8 ++++++++ fs/exfat/fatent.c | 8 -------- 3 files changed, 14 insertions(+), 10 deletions(-) --- a/fs/exfat/balloc.c +++ b/fs/exfat/balloc.c @@ -148,7 +148,9 @@ int exfat_set_bitmap(struct inode *inode struct super_block *sb =3D inode->i_sb; struct exfat_sb_info *sbi =3D EXFAT_SB(sb); =20 - WARN_ON(clu < EXFAT_FIRST_CLUSTER); + if (!is_valid_cluster(sbi, clu)) + return -EINVAL; + ent_idx =3D CLUSTER_TO_BITMAP_ENT(clu); i =3D BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx); b =3D BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx); @@ -166,7 +168,9 @@ void exfat_clear_bitmap(struct inode *in struct exfat_sb_info *sbi =3D EXFAT_SB(sb); struct exfat_mount_options *opts =3D &sbi->options; =20 - WARN_ON(clu < EXFAT_FIRST_CLUSTER); + if (!is_valid_cluster(sbi, clu)) + return; + ent_idx =3D CLUSTER_TO_BITMAP_ENT(clu); i =3D BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx); b =3D BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx); --- a/fs/exfat/exfat_fs.h +++ b/fs/exfat/exfat_fs.h @@ -380,6 +380,14 @@ static inline int exfat_sector_to_cluste EXFAT_RESERVED_CLUSTERS; } =20 +static inline bool is_valid_cluster(struct exfat_sb_info *sbi, + unsigned int clus) +{ + if (clus < EXFAT_FIRST_CLUSTER || sbi->num_clusters <=3D clus) + return false; + return true; +} + /* super.c */ int exfat_set_volume_dirty(struct super_block *sb); int exfat_clear_volume_dirty(struct super_block *sb); --- a/fs/exfat/fatent.c +++ b/fs/exfat/fatent.c @@ -81,14 +81,6 @@ int exfat_ent_set(struct super_block *sb return 0; } =20 -static inline bool is_valid_cluster(struct exfat_sb_info *sbi, - unsigned int clus) -{ - if (clus < EXFAT_FIRST_CLUSTER || sbi->num_clusters <=3D clus) - return false; - return true; -} - int exfat_ent_get(struct super_block *sb, unsigned int loc, unsigned int *content) { From nobody Tue Apr 28 06:30:15 2026 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 2BA72CCA482 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346907AbiFCSFa (ORCPT ); Fri, 3 Jun 2022 14:05:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346546AbiFCRvQ (ORCPT ); Fri, 3 Jun 2022 13:51: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 7061856FBC; Fri, 3 Jun 2022 10:48: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 A2B4760F64; Fri, 3 Jun 2022 17:48:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7A7AC385A9; Fri, 3 Jun 2022 17:48:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278511; bh=ZAUIQepYV9D04+q2+gCaXqFUGhgcHYupHHkLMcHane4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lDDUjJ6+w/Kua2nanUoUAfuGDZtGYbjNVtMgPionSuHYelzZuUQWoga5uojuSVCTf nJ6UaN3SXDUPgVr0QUAdmkQS6rxug8C9hxVeCVHPObM8J3l2xk2/hbwFFVOJLoi+8f 1By6oMAupzfzli98q5w9nmCHQ1Dz4vKxvinEnyAI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yuezhang Mo , Andy Wu , Aoyama Wataru , Daniel Palmer , Sungjong Seo , Namjae Jeon Subject: [PATCH 5.10 23/53] exfat: fix referencing wrong parent directory information after renaming Date: Fri, 3 Jun 2022 19:43:08 +0200 Message-Id: <20220603173819.398981832@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Yuezhang Mo commit d8dad2588addd1d861ce19e7df3b702330f0c7e3 upstream. During renaming, the parent directory information maybe updated. But the file/directory still references to the old parent directory information. This bug will cause 2 problems. (1) The renamed file can not be written. [10768.175172] exFAT-fs (sda1): error, failed to bmap (inode : 7afd50e4= iblock : 0, err : -5) [10768.184285] exFAT-fs (sda1): Filesystem has been set read-only ash: write error: Input/output error (2) Some dentries of the renamed file/directory are not set to deleted after removing the file/directory. exfat_update_parent_info() is a workaround for the wrong parent directory information being used after renaming. Now that bug is fixed, this is no longer needed, so remove it. Fixes: 5f2aa075070c ("exfat: add inode operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Yuezhang Mo Reviewed-by: Andy Wu Reviewed-by: Aoyama Wataru Reviewed-by: Daniel Palmer Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/exfat/namei.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) --- a/fs/exfat/namei.c +++ b/fs/exfat/namei.c @@ -1061,6 +1061,7 @@ static int exfat_rename_file(struct inod =20 exfat_remove_entries(inode, p_dir, oldentry, 0, num_old_entries); + ei->dir =3D *p_dir; ei->entry =3D newentry; } else { if (exfat_get_entry_type(epold) =3D=3D TYPE_FILE) { @@ -1151,28 +1152,6 @@ static int exfat_move_file(struct inode return 0; } =20 -static void exfat_update_parent_info(struct exfat_inode_info *ei, - struct inode *parent_inode) -{ - struct exfat_sb_info *sbi =3D EXFAT_SB(parent_inode->i_sb); - struct exfat_inode_info *parent_ei =3D EXFAT_I(parent_inode); - loff_t parent_isize =3D i_size_read(parent_inode); - - /* - * the problem that struct exfat_inode_info caches wrong parent info. - * - * because of flag-mismatch of ei->dir, - * there is abnormal traversing cluster chain. - */ - if (unlikely(parent_ei->flags !=3D ei->dir.flags || - parent_isize !=3D EXFAT_CLU_TO_B(ei->dir.size, sbi) || - parent_ei->start_clu !=3D ei->dir.dir)) { - exfat_chain_set(&ei->dir, parent_ei->start_clu, - EXFAT_B_TO_CLU_ROUND_UP(parent_isize, sbi), - parent_ei->flags); - } -} - /* rename or move a old file into a new file */ static int __exfat_rename(struct inode *old_parent_inode, struct exfat_inode_info *ei, struct inode *new_parent_inode, @@ -1203,8 +1182,6 @@ static int __exfat_rename(struct inode * return -ENOENT; } =20 - exfat_update_parent_info(ei, old_parent_inode); - exfat_chain_dup(&olddir, &ei->dir); dentry =3D ei->entry; =20 @@ -1225,8 +1202,6 @@ static int __exfat_rename(struct inode * goto out; } =20 - exfat_update_parent_info(new_ei, new_parent_inode); - p_dir =3D &(new_ei->dir); new_entry =3D new_ei->entry; ep =3D exfat_get_dentry(sb, p_dir, new_entry, &new_bh, NULL); From nobody Tue Apr 28 06:30:15 2026 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 409C0C433EF for ; Fri, 3 Jun 2022 17:57:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345933AbiFCR52 (ORCPT ); Fri, 3 Jun 2022 13:57:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346561AbiFCRvR (ORCPT ); Fri, 3 Jun 2022 13:51:17 -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 864465520E; Fri, 3 Jun 2022 10:48: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 ams.source.kernel.org (Postfix) with ESMTPS id 494D8B8241D; Fri, 3 Jun 2022 17:48:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9546FC385A9; Fri, 3 Jun 2022 17:48:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278514; bh=UJYQLVdpOQK+wV5KF+SBi3wrp+2pt2j7/nnYiN29v3U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=moQ5wZpeqw4KKNs7aGM1MeNSDpfthuKG8heYj3sLPTjG86QGwyL/ukKMgtX9yUNj1 fjnB5O7ikbs98RieOfQSf6cqCtmM/HTJgRdN4C2HHqlzxBLufovxcdEuY7PtCSS4Dt LzmFI4ptCU/RKJTKFYlpP8dBvFT/fZsqF/YKeKe0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Herbert Xu , linux-crypto@vger.kernel.org, "Justin M. Forbes" , "Jason A. Donenfeld" Subject: [PATCH 5.10 24/53] lib/crypto: add prompts back to crypto libraries Date: Fri, 3 Jun 2022 19:43:09 +0200 Message-Id: <20220603173819.429401098@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: "Justin M. Forbes" commit e56e18985596617ae426ed5997fb2e737cffb58b upstream. Commit 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") took away a number of prompt texts from other crypto libraries. This makes values flip from built-in to module when oldconfig runs, and causes problems when these crypto libs need to be built in for thingslike BIG_KEYS. Fixes: 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") Cc: Herbert Xu Cc: linux-crypto@vger.kernel.org Signed-off-by: Justin M. Forbes [Jason: - moved menu into submenu of lib/ instead of root menu - fixed chacha sub-dependencies for CONFIG_CRYPTO] Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- crypto/Kconfig | 2 -- lib/Kconfig | 2 ++ lib/crypto/Kconfig | 17 ++++++++++++----- 3 files changed, 14 insertions(+), 7 deletions(-) --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1941,5 +1941,3 @@ source "crypto/asymmetric_keys/Kconfig" source "certs/Kconfig" =20 endif # if CRYPTO - -source "lib/crypto/Kconfig" --- a/lib/Kconfig +++ b/lib/Kconfig @@ -101,6 +101,8 @@ config INDIRECT_PIO =20 When in doubt, say N. =20 +source "lib/crypto/Kconfig" + config CRC_CCITT tristate "CRC-CCITT functions" help --- a/lib/crypto/Kconfig +++ b/lib/crypto/Kconfig @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 =20 +menu "Crypto library routines" + config CRYPTO_LIB_AES tristate =20 @@ -31,7 +33,7 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA =20 config CRYPTO_LIB_CHACHA_GENERIC tristate - select CRYPTO_ALGAPI + select XOR_BLOCKS help This symbol can be depended upon by arch implementations of the ChaCha library interface that require the generic code as a @@ -40,7 +42,8 @@ config CRYPTO_LIB_CHACHA_GENERIC of CRYPTO_LIB_CHACHA. =20 config CRYPTO_LIB_CHACHA - tristate + tristate "ChaCha library interface" + depends on CRYPTO depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA select CRYPTO_LIB_CHACHA_GENERIC if CRYPTO_ARCH_HAVE_LIB_CHACHA=3Dn help @@ -65,7 +68,7 @@ config CRYPTO_LIB_CURVE25519_GENERIC of CRYPTO_LIB_CURVE25519. =20 config CRYPTO_LIB_CURVE25519 - tristate + tristate "Curve25519 scalar multiplication library" depends on CRYPTO_ARCH_HAVE_LIB_CURVE25519 || !CRYPTO_ARCH_HAVE_LIB_CURVE= 25519 select CRYPTO_LIB_CURVE25519_GENERIC if CRYPTO_ARCH_HAVE_LIB_CURVE25519= =3Dn help @@ -100,7 +103,7 @@ config CRYPTO_LIB_POLY1305_GENERIC of CRYPTO_LIB_POLY1305. =20 config CRYPTO_LIB_POLY1305 - tristate + tristate "Poly1305 library interface" depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305 select CRYPTO_LIB_POLY1305_GENERIC if CRYPTO_ARCH_HAVE_LIB_POLY1305=3Dn help @@ -109,11 +112,15 @@ config CRYPTO_LIB_POLY1305 is available and enabled. =20 config CRYPTO_LIB_CHACHA20POLY1305 - tristate + tristate "ChaCha20-Poly1305 AEAD support (8-byte nonce library version)" depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305 + depends on CRYPTO select CRYPTO_LIB_CHACHA select CRYPTO_LIB_POLY1305 + select CRYPTO_ALGAPI =20 config CRYPTO_LIB_SHA256 tristate + +endmenu From nobody Tue Apr 28 06:30:15 2026 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 16733CCA480 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346855AbiFCSF1 (ORCPT ); Fri, 3 Jun 2022 14:05:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346562AbiFCRvR (ORCPT ); Fri, 3 Jun 2022 13:51:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E7715710D; Fri, 3 Jun 2022 10:48: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 dfw.source.kernel.org (Postfix) with ESMTPS id 9524760F3E; Fri, 3 Jun 2022 17:48:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 961DAC385A9; Fri, 3 Jun 2022 17:48:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278517; bh=0dps9+gQ/mQziwxK62E4J5kQRKRytCDyJYGrbsF67c8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pM0C7UQB28NwFP4LtvYQcZg77wCelOk4eyokdUQ2Q8eHzn7aGa/B4FBUyrbrQr20b 5ECFZTyew05aSyWTl90pa//7LGHlxN63UetkN/o4YjGwzm4hAjqCs7I6IvzeQI1vwc zzQTxbJVjX7M2TcvtgfyEfVSova8lfk6EJHDkHUI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , =?UTF-8?q?Stephan=20M=C3=BCller?= , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.10 25/53] crypto: drbg - prepare for more fine-grained tracking of seeding state Date: Fri, 3 Jun 2022 19:43:10 +0200 Message-Id: <20220603173819.458280524@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Nicolai Stange commit ce8ce31b2c5c8b18667784b8c515650c65d57b4e upstream. There are two different randomness sources the DRBGs are getting seeded from, namely the jitterentropy source (if enabled) and get_random_bytes(). At initial DRBG seeding time during boot, the latter might not have collected sufficient entropy for seeding itself yet and thus, the DRBG implementation schedules a reseed work from a random_ready_callback once that has happened. This is particularly important for the !->pr DRBG instances, for which (almost) no further reseeds are getting triggered during their lifetime. Because collecting data from the jitterentropy source is a rather expensive operation, the aforementioned asynchronously scheduled reseed work restricts itself to get_random_bytes() only. That is, it in some sense amends the initial DRBG seed derived from jitterentropy output at full (estimated) entropy with fresh randomness obtained from get_random_bytes() once that has been seeded with sufficient entropy itself. With the advent of rng_is_initialized(), there is no real need for doing the reseed operation from an asynchronously scheduled work anymore and a subsequent patch will make it synchronous by moving it next to related logic already present in drbg_generate(). However, for tracking whether a full reseed including the jitterentropy source is required or a "partial" reseed involving only get_random_bytes() would be sufficient already, the boolean struct drbg_state's ->seeded member must become a tristate value. Prepare for this by introducing the new enum drbg_seed_state and change struct drbg_state's ->seeded member's type from bool to that type. For facilitating review, enum drbg_seed_state is made to only contain two members corresponding to the former ->seeded values of false and true resp. at this point: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. A third one for tracking the intermediate state of "seeded from jitterentropy only" will be introduced with a subsequent patch. There is no change in behaviour at this point. Signed-off-by: Nicolai Stange Reviewed-by: Stephan M=C3=BCller Signed-off-by: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- crypto/drbg.c | 19 ++++++++++--------- include/crypto/drbg.h | 7 ++++++- 2 files changed, 16 insertions(+), 10 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1042,7 +1042,7 @@ static inline int __drbg_seed(struct drb if (ret) return ret; =20 - drbg->seeded =3D true; + drbg->seeded =3D DRBG_SEED_STATE_FULL; /* 10.1.1.2 / 10.1.1.3 step 5 */ drbg->reseed_ctr =3D 1; =20 @@ -1087,14 +1087,14 @@ static void drbg_async_seed(struct work_ if (ret) goto unlock; =20 - /* Set seeded to false so that if __drbg_seed fails the - * next generate call will trigger a reseed. + /* Reset ->seeded so that if __drbg_seed fails the next + * generate call will trigger a reseed. */ - drbg->seeded =3D false; + drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; =20 __drbg_seed(drbg, &seedlist, true); =20 - if (drbg->seeded) + if (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL) drbg->reseed_threshold =3D drbg_max_requests(drbg); =20 unlock: @@ -1385,13 +1385,14 @@ static int drbg_generate(struct drbg_sta * here. The spec is a bit convoluted here, we make it simpler. */ if (drbg->reseed_threshold < drbg->reseed_ctr) - drbg->seeded =3D false; + drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; =20 - if (drbg->pr || !drbg->seeded) { + if (drbg->pr || drbg->seeded =3D=3D DRBG_SEED_STATE_UNSEEDED) { pr_devel("DRBG: reseeding before generation (prediction " "resistance: %s, state %s)\n", drbg->pr ? "true" : "false", - drbg->seeded ? "seeded" : "unseeded"); + (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL ? + "seeded" : "unseeded")); /* 9.3.1 steps 7.1 through 7.3 */ len =3D drbg_seed(drbg, addtl, true); if (len) @@ -1576,7 +1577,7 @@ static int drbg_instantiate(struct drbg_ if (!drbg->core) { drbg->core =3D &drbg_cores[coreref]; drbg->pr =3D pr; - drbg->seeded =3D false; + drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; drbg->reseed_threshold =3D drbg_max_requests(drbg); =20 ret =3D drbg_alloc_state(drbg); --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -105,6 +105,11 @@ struct drbg_test_data { struct drbg_string *testentropy; /* TEST PARAMETER: test entropy */ }; =20 +enum drbg_seed_state { + DRBG_SEED_STATE_UNSEEDED, + DRBG_SEED_STATE_FULL, +}; + struct drbg_state { struct mutex drbg_mutex; /* lock around DRBG */ unsigned char *V; /* internal state 10.1.1.1 1a) */ @@ -127,7 +132,7 @@ struct drbg_state { struct crypto_wait ctr_wait; /* CTR mode async wait obj */ struct scatterlist sg_in, sg_out; /* CTR mode SGLs */ =20 - bool seeded; /* DRBG fully seeded? */ + enum drbg_seed_state seeded; /* DRBG fully seeded? */ bool pr; /* Prediction resistance enabled? */ bool fips_primed; /* Continuous test primed? */ unsigned char *prev; /* FIPS 140-2 continuous test value */ From nobody Tue Apr 28 06:30:15 2026 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 B944CC43334 for ; Fri, 3 Jun 2022 17:59:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346046AbiFCR7y (ORCPT ); Fri, 3 Jun 2022 13:59:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346579AbiFCRvS (ORCPT ); Fri, 3 Jun 2022 13:51:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2013157124; Fri, 3 Jun 2022 10:48:41 -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 9D54960F7F; Fri, 3 Jun 2022 17:48:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E306C385A9; Fri, 3 Jun 2022 17:48:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278520; bh=bA32dH1FbReMD6dkPhjw3sLV/3rPluZTJVYOKOMlN8s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GAitTYYF9rQVDpo/S80ToYmBR3CmU9IkzFJaORvKjNu2ZMzEitYmHN6cTq+ajVhsi 4liNF9P0PIiGBMX1gHmkRZSy3s/i/JnDt26H6H8Oeqpz+Vz+/QAeZd2aQxm64feOcW XYtitBy+lPTg+FbEWNu4V+bCPhyVhsaMr1NswyuE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , =?UTF-8?q?Stephan=20M=C3=BCller?= , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.10 26/53] crypto: drbg - track whether DRBG was seeded with !rng_is_initialized() Date: Fri, 3 Jun 2022 19:43:11 +0200 Message-Id: <20220603173819.486438097@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Nicolai Stange commit 2bcd25443868aa8863779a6ebc6c9319633025d2 upstream. Currently, the DRBG implementation schedules asynchronous works from random_ready_callbacks for reseeding the DRBG instances with output from get_random_bytes() once the latter has sufficient entropy available. However, as the get_random_bytes() initialization state can get queried by means of rng_is_initialized() now, there is no real need for this asynchronous reseeding logic anymore and it's better to keep things simple by doing it synchronously when needed instead, i.e. from drbg_generate() once rng_is_initialized() has flipped to true. Of course, for this to work, drbg_generate() would need some means by which it can tell whether or not rng_is_initialized() has flipped to true since the last seeding from get_random_bytes(). Or equivalently, whether or not the last seed from get_random_bytes() has happened when rng_is_initialized() was still evaluating to false. As it currently stands, enum drbg_seed_state allows for the representation of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full reseeding operation involving both, the rather expensive jitterentropy as well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL state on the other hand implies that no reseeding at all is required for a !->pr DRBG variant. Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for representing the condition that a DRBG was being seeded when rng_is_initialized() had still been false. In particular, this new state implies that - the given DRBG instance has been fully seeded from the jitterentropy source (if enabled) - and drbg_generate() is supposed to reseed from get_random_bytes() *only* once rng_is_initialized() turns to true. Up to now, the __drbg_seed() helper used to set the given DRBG instance's ->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument allowing for the specification of the to be written ->seeded value instead. Make the first of its two callers, drbg_seed(), determine the appropriate value based on rng_is_initialized(). The remaining caller, drbg_async_seed(), is known to get invoked only once rng_is_initialized() is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new argument to __drbg_seed(). There is no change in behaviour, except for that the pr_devel() in drbg_generate() would now report "unseeded" for ->pr DRBG instances which had last been seeded when rng_is_initialized() was still evaluating to false. Signed-off-by: Nicolai Stange Reviewed-by: Stephan M=C3=BCller Signed-off-by: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- crypto/drbg.c | 12 ++++++++---- include/crypto/drbg.h | 1 + 2 files changed, 9 insertions(+), 4 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1035,14 +1035,14 @@ static const struct drbg_state_ops drbg_ ******************************************************************/ =20 static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *s= eed, - int reseed) + int reseed, enum drbg_seed_state new_seed_state) { int ret =3D drbg->d_ops->update(drbg, seed, reseed); =20 if (ret) return ret; =20 - drbg->seeded =3D DRBG_SEED_STATE_FULL; + drbg->seeded =3D new_seed_state; /* 10.1.1.2 / 10.1.1.3 step 5 */ drbg->reseed_ctr =3D 1; =20 @@ -1092,7 +1092,7 @@ static void drbg_async_seed(struct work_ */ drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; =20 - __drbg_seed(drbg, &seedlist, true); + __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); =20 if (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL) drbg->reseed_threshold =3D drbg_max_requests(drbg); @@ -1122,6 +1122,7 @@ static int drbg_seed(struct drbg_state * unsigned int entropylen =3D drbg_sec_strength(drbg->core->flags); struct drbg_string data1; LIST_HEAD(seedlist); + enum drbg_seed_state new_seed_state =3D DRBG_SEED_STATE_FULL; =20 /* 9.1 / 9.2 / 9.3.1 step 3 */ if (pers && pers->len > (drbg_max_addtl(drbg))) { @@ -1149,6 +1150,9 @@ static int drbg_seed(struct drbg_state * BUG_ON((entropylen * 2) > sizeof(entropy)); =20 /* Get seed from in-kernel /dev/urandom */ + if (!rng_is_initialized()) + new_seed_state =3D DRBG_SEED_STATE_PARTIAL; + ret =3D drbg_get_random_bytes(drbg, entropy, entropylen); if (ret) goto out; @@ -1205,7 +1209,7 @@ static int drbg_seed(struct drbg_state * memset(drbg->C, 0, drbg_statelen(drbg)); } =20 - ret =3D __drbg_seed(drbg, &seedlist, reseed); + ret =3D __drbg_seed(drbg, &seedlist, reseed, new_seed_state); =20 out: memzero_explicit(entropy, entropylen * 2); --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -107,6 +107,7 @@ struct drbg_test_data { =20 enum drbg_seed_state { DRBG_SEED_STATE_UNSEEDED, + DRBG_SEED_STATE_PARTIAL, /* Seeded with !rng_is_initialized() */ DRBG_SEED_STATE_FULL, }; =20 From nobody Tue Apr 28 06:30:15 2026 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 E9286CCA47E for ; Fri, 3 Jun 2022 18:07:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346815AbiFCSFR (ORCPT ); Fri, 3 Jun 2022 14:05:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346588AbiFCRvS (ORCPT ); Fri, 3 Jun 2022 13:51:18 -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 CE8B457136; Fri, 3 Jun 2022 10:48: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 6AF42B82433; Fri, 3 Jun 2022 17:48:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3FD8C385A9; Fri, 3 Jun 2022 17:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278523; bh=5472PgeiF25eTzaG8Pxt7MVzcW+2xzwpBTW6xW3eu1U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2oEyj6HP1SEm52fZwWU1Bxgwn+lXT434WV2+0CfJn1o8Ds9wlrbF+6y8+KKJ/4fXi arPN/3/qTVnXtcc3X+5u3dTGoD+vhdhIMaen2JtC2DxDvqwCFBjfmK2F1D0Ca98QfV 29UbQc0CThYCOXmJfDWUgrpQr1xceLQa7Jt2gQYg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , =?UTF-8?q?Stephan=20M=C3=BCller?= , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.10 27/53] crypto: drbg - move dynamic ->reseed_threshold adjustments to __drbg_seed() Date: Fri, 3 Jun 2022 19:43:12 +0200 Message-Id: <20220603173819.514319812@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Nicolai Stange commit 262d83a4290c331cd4f617a457408bdb82fbb738 upstream. Since commit 42ea507fae1a ("crypto: drbg - reseed often if seedsource is degraded"), the maximum seed lifetime represented by ->reseed_threshold gets temporarily lowered if the get_random_bytes() source cannot provide sufficient entropy yet, as is common during boot, and restored back to the original value again once that has changed. More specifically, if the add_random_ready_callback() invoked from drbg_prepare_hrng() in the course of DRBG instantiation does not return -EALREADY, that is, if get_random_bytes() has not been fully initialized at this point yet, drbg_prepare_hrng() will lower ->reseed_threshold to a value of 50. The drbg_async_seed() scheduled from said random_ready_callback will eventually restore the original value. A future patch will replace the random_ready_callback based notification mechanism and thus, there will be no add_random_ready_callback() return value anymore which could get compared to -EALREADY. However, there's __drbg_seed() which gets invoked in the course of both, the DRBG instantiation as well as the eventual reseeding from get_random_bytes() in aforementioned drbg_async_seed(), if any. Moreover, it knows about the get_random_bytes() initialization state by the time the seed data had been obtained from it: the new_seed_state argument introduced with the previous patch would get set to DRBG_SEED_STATE_PARTIAL in case get_random_bytes() had not been fully initialized yet and to DRBG_SEED_STATE_FULL otherwise. Thus, __drbg_seed() provides a convenient alternative for managing that ->reseed_threshold lowering and restoring at a central place. Move all ->reseed_threshold adjustment code from drbg_prepare_hrng() and drbg_async_seed() respectively to __drbg_seed(). Make __drbg_seed() lower the ->reseed_threshold to 50 in case its new_seed_state argument equals DRBG_SEED_STATE_PARTIAL and let it restore the original value otherwise. There is no change in behaviour. Signed-off-by: Nicolai Stange Reviewed-by: Stephan M=C3=BCller Signed-off-by: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- crypto/drbg.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1046,6 +1046,27 @@ static inline int __drbg_seed(struct drb /* 10.1.1.2 / 10.1.1.3 step 5 */ drbg->reseed_ctr =3D 1; =20 + switch (drbg->seeded) { + case DRBG_SEED_STATE_UNSEEDED: + /* Impossible, but handle it to silence compiler warnings. */ + fallthrough; + case DRBG_SEED_STATE_PARTIAL: + /* + * Require frequent reseeds until the seed source is + * fully initialized. + */ + drbg->reseed_threshold =3D 50; + break; + + case DRBG_SEED_STATE_FULL: + /* + * Seed source has become fully initialized, frequent + * reseeds no longer required. + */ + drbg->reseed_threshold =3D drbg_max_requests(drbg); + break; + } + return ret; } =20 @@ -1094,9 +1115,6 @@ static void drbg_async_seed(struct work_ =20 __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); =20 - if (drbg->seeded =3D=3D DRBG_SEED_STATE_FULL) - drbg->reseed_threshold =3D drbg_max_requests(drbg); - unlock: mutex_unlock(&drbg->drbg_mutex); =20 @@ -1532,12 +1550,6 @@ static int drbg_prepare_hrng(struct drbg return err; } =20 - /* - * Require frequent reseeds until the seed source is fully - * initialized. - */ - drbg->reseed_threshold =3D 50; - return err; } =20 From nobody Tue Apr 28 06:30:15 2026 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 7ED9FC433EF for ; Fri, 3 Jun 2022 17:56:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345636AbiFCR4A (ORCPT ); Fri, 3 Jun 2022 13:56:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346154AbiFCRuu (ORCPT ); Fri, 3 Jun 2022 13:50:50 -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 6F22A59B90; Fri, 3 Jun 2022 10:47: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 8E984B82436; Fri, 3 Jun 2022 17:47:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC0B1C385A9; Fri, 3 Jun 2022 17:47:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278422; bh=aUs8o8xuQtTJ/rkv3dVMG6jokAsU4oCydVaIxfQmXrk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=10uv/nywsQJZDAMhvvzV1HiD65Agsul59C8P+nnSt2Jx9mQ0QDodvd1Iojlmhbfup aTck9bkRG/EKQA20ro8DOaRLOqxfaBMuO+h76PVt/UajCciK242XnCez71/DJ1DWSD veZK9R4r2d5tvoXASrn0HIW3bgTJYmCh8BeSUNMU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolai Stange , Herbert Xu , "Jason A. Donenfeld" Subject: [PATCH 5.10 28/53] crypto: drbg - make reseeding from get_random_bytes() synchronous Date: Fri, 3 Jun 2022 19:43:13 +0200 Message-Id: <20220603173819.543662944@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Nicolai Stange commit 074bcd4000e0d812bc253f86fedc40f81ed59ccc upstream. get_random_bytes() usually hasn't full entropy available by the time DRBG instances are first getting seeded from it during boot. Thus, the DRBG implementation registers random_ready_callbacks which would in turn schedule some work for reseeding the DRBGs once get_random_bytes() has sufficient entropy available. For reference, the relevant history around handling DRBG (re)seeding in the context of a not yet fully seeded get_random_bytes() is: commit 16b369a91d0d ("random: Blocking API for accessing nonblocking_pool") commit 4c7879907edd ("crypto: drbg - add async seeding operation") commit 205a525c3342 ("random: Add callback API for random pool readiness") commit 57225e679788 ("crypto: drbg - Use callback API for random readiness") commit c2719503f5e1 ("random: Remove kernel blocking API") However, some time later, the initialization state of get_random_bytes() has been made queryable via rng_is_initialized() introduced with commit 9a47249d444d ("random: Make crng state queryable"). This primitive now allows for streamlining the DRBG reseeding from get_random_bytes() by replacing that aforementioned asynchronous work scheduling from random_ready_callbacks with some simpler, synchronous code in drbg_generate() next to the related logic already present therein. Apart from improving overall code readability, this change will also enable DRBG users to rely on wait_for_random_bytes() for ensuring that the initial seeding has completed, if desired. The previous patches already laid the grounds by making drbg_seed() to record at each DRBG instance whether it was being seeded at a time when rng_is_initialized() still had been false as indicated by ->seeded =3D=3D DRBG_SEED_STATE_PARTIAL. All that remains to be done now is to make drbg_generate() check for this condition, determine whether rng_is_initialized() has flipped to true in the meanwhile and invoke a reseed from get_random_bytes() if so. Make this move: - rename the former drbg_async_seed() work handler, i.e. the one in charge of reseeding a DRBG instance from get_random_bytes(), to "drbg_seed_from_random()", - change its signature as appropriate, i.e. make it take a struct drbg_state rather than a work_struct and change its return type from "void" to "int" in order to allow for passing error information from e.g. its __drbg_seed() invocation onwards to callers, - make drbg_generate() invoke this drbg_seed_from_random() once it encounters a DRBG instance with ->seeded =3D=3D DRBG_SEED_STATE_PARTIAL by the time rng_is_initialized() has flipped to true and - prune everything related to the former, random_ready_callback based mechanism. As drbg_seed_from_random() is now getting invoked from drbg_generate() with the ->drbg_mutex being held, it must not attempt to recursively grab it once again. Remove the corresponding mutex operations from what is now drbg_seed_from_random(). Furthermore, as drbg_seed_from_random() can now report errors directly to its caller, there's no need for it to temporarily switch the DRBG's ->seeded state to DRBG_SEED_STATE_UNSEEDED so that a failure of the subsequently invoked __drbg_seed() will get signaled to drbg_generate(). Don't do it then. Signed-off-by: Nicolai Stange Signed-off-by: Herbert Xu [Jason: for stable, undid the modifications for the backport of 5acd3548.] Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- crypto/drbg.c | 61 +++++++++------------------------------------= ----- drivers/char/random.c | 2 - include/crypto/drbg.h | 2 - 3 files changed, 11 insertions(+), 54 deletions(-) --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1086,12 +1086,10 @@ static inline int drbg_get_random_bytes( return 0; } =20 -static void drbg_async_seed(struct work_struct *work) +static int drbg_seed_from_random(struct drbg_state *drbg) { struct drbg_string data; LIST_HEAD(seedlist); - struct drbg_state *drbg =3D container_of(work, struct drbg_state, - seed_work); unsigned int entropylen =3D drbg_sec_strength(drbg->core->flags); unsigned char entropy[32]; int ret; @@ -1102,23 +1100,15 @@ static void drbg_async_seed(struct work_ drbg_string_fill(&data, entropy, entropylen); list_add_tail(&data.list, &seedlist); =20 - mutex_lock(&drbg->drbg_mutex); - ret =3D drbg_get_random_bytes(drbg, entropy, entropylen); if (ret) - goto unlock; - - /* Reset ->seeded so that if __drbg_seed fails the next - * generate call will trigger a reseed. - */ - drbg->seeded =3D DRBG_SEED_STATE_UNSEEDED; + goto out; =20 - __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); - -unlock: - mutex_unlock(&drbg->drbg_mutex); + ret =3D __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); =20 +out: memzero_explicit(entropy, entropylen); + return ret; } =20 /* @@ -1421,6 +1411,11 @@ static int drbg_generate(struct drbg_sta goto err; /* 9.3.1 step 7.4 */ addtl =3D NULL; + } else if (rng_is_initialized() && + drbg->seeded =3D=3D DRBG_SEED_STATE_PARTIAL) { + len =3D drbg_seed_from_random(drbg); + if (len) + goto err; } =20 if (addtl && 0 < addtl->len) @@ -1513,44 +1508,15 @@ static int drbg_generate_long(struct drb return 0; } =20 -static int drbg_schedule_async_seed(struct notifier_block *nb, unsigned lo= ng action, void *data) -{ - struct drbg_state *drbg =3D container_of(nb, struct drbg_state, - random_ready); - - schedule_work(&drbg->seed_work); - return 0; -} - static int drbg_prepare_hrng(struct drbg_state *drbg) { - int err; - /* We do not need an HRNG in test mode. */ if (list_empty(&drbg->test_data.list)) return 0; =20 drbg->jent =3D crypto_alloc_rng("jitterentropy_rng", 0, 0); =20 - INIT_WORK(&drbg->seed_work, drbg_async_seed); - - drbg->random_ready.notifier_call =3D drbg_schedule_async_seed; - err =3D register_random_ready_notifier(&drbg->random_ready); - - switch (err) { - case 0: - break; - - case -EALREADY: - err =3D 0; - fallthrough; - - default: - drbg->random_ready.notifier_call =3D NULL; - return err; - } - - return err; + return 0; } =20 /* @@ -1644,11 +1610,6 @@ free_everything: */ static int drbg_uninstantiate(struct drbg_state *drbg) { - if (drbg->random_ready.notifier_call) { - unregister_random_ready_notifier(&drbg->random_ready); - cancel_work_sync(&drbg->seed_work); - } - if (!IS_ERR_OR_NULL(drbg->jent)) crypto_free_rng(drbg->jent); drbg->jent =3D NULL; --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -163,7 +163,6 @@ int __cold register_random_ready_notifie spin_unlock_irqrestore(&random_ready_chain_lock, flags); return ret; } -EXPORT_SYMBOL(register_random_ready_notifier); =20 /* * Delete a previously registered readiness callback function. @@ -178,7 +177,6 @@ int __cold unregister_random_ready_notif spin_unlock_irqrestore(&random_ready_chain_lock, flags); return ret; } -EXPORT_SYMBOL(unregister_random_ready_notifier); =20 static void __cold process_random_ready_list(void) { --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -137,12 +137,10 @@ struct drbg_state { bool pr; /* Prediction resistance enabled? */ bool fips_primed; /* Continuous test primed? */ unsigned char *prev; /* FIPS 140-2 continuous test value */ - struct work_struct seed_work; /* asynchronous seeding support */ struct crypto_rng *jent; const struct drbg_state_ops *d_ops; const struct drbg_core *core; struct drbg_string test_data; - struct notifier_block random_ready; }; =20 static inline __u8 drbg_statelen(struct drbg_state *drbg) From nobody Tue Apr 28 06:30:15 2026 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 B892DC43334 for ; Fri, 3 Jun 2022 17:55:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345554AbiFCRzy (ORCPT ); Fri, 3 Jun 2022 13:55:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346140AbiFCRut (ORCPT ); Fri, 3 Jun 2022 13:50:49 -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 84E0559BA1; Fri, 3 Jun 2022 10:47:06 -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 1C82C60A54; Fri, 3 Jun 2022 17:47:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB60BC385A9; Fri, 3 Jun 2022 17:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278425; bh=liVSteoCj2Tuco0mXW8SxqR0o1L93a4IevrYkT04wk8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bBwv3Y8NBCQXXcD6sKyFMN9e1njcH46wtY6TpjbKW16dzVnXHAYFBjJLApSFW4Aei Zuhw2SOuX32o99Nz8XoncDAU1Klm8LL8y/G4jZRjTmuiPSmSGRwoL5eDBkTWgo67B3 ZJvaZ6q7tyHkyZJ8ey5HW0BU5jJ3oKvnCziyOld4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, zhangziming.zzm@antgroup.com, Stefano Brivio , Florian Westphal , Pablo Neira Ayuso Subject: [PATCH 5.10 29/53] netfilter: nf_tables: sanitize nft_set_desc_concat_parse() Date: Fri, 3 Jun 2022 19:43:14 +0200 Message-Id: <20220603173819.571904847@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 commit fecf31ee395b0295f2d7260aa29946b7605f7c85 upstream. Add several sanity checks for nft_set_desc_concat_parse(): - validate desc->field_count not larger than desc->field_len array. - field length cannot be larger than desc->field_len (ie. U8_MAX) - total length of the concatenation cannot be larger than register array. Joint work with Florian Westphal. Fixes: f3a2181e16f1 ("netfilter: nf_tables: Support for sets with multiple = ranged fields") Reported-by: Reviewed-by: Stefano Brivio Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- net/netfilter/nf_tables_api.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -4051,6 +4051,9 @@ static int nft_set_desc_concat_parse(con u32 len; int err; =20 + if (desc->field_count >=3D ARRAY_SIZE(desc->field_len)) + return -E2BIG; + err =3D nla_parse_nested_deprecated(tb, NFTA_SET_FIELD_MAX, attr, nft_concat_policy, NULL); if (err < 0) @@ -4060,9 +4063,8 @@ static int nft_set_desc_concat_parse(con return -EINVAL; =20 len =3D ntohl(nla_get_be32(tb[NFTA_SET_FIELD_LEN])); - - if (len * BITS_PER_BYTE / 32 > NFT_REG32_COUNT) - return -E2BIG; + if (!len || len > U8_MAX) + return -EINVAL; =20 desc->field_len[desc->field_count++] =3D len; =20 @@ -4073,7 +4075,8 @@ static int nft_set_desc_concat(struct nf const struct nlattr *nla) { struct nlattr *attr; - int rem, err; + u32 num_regs =3D 0; + int rem, err, i; =20 nla_for_each_nested(attr, nla, rem) { if (nla_type(attr) !=3D NFTA_LIST_ELEM) @@ -4084,6 +4087,12 @@ static int nft_set_desc_concat(struct nf return err; } =20 + for (i =3D 0; i < desc->field_count; i++) + num_regs +=3D DIV_ROUND_UP(desc->field_len[i], sizeof(u32)); + + if (num_regs > NFT_REG32_COUNT) + return -E2BIG; + return 0; } From nobody Tue Apr 28 06:30:15 2026 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 68357CCA47E for ; Fri, 3 Jun 2022 17:55:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343794AbiFCRzo (ORCPT ); Fri, 3 Jun 2022 13:55:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346103AbiFCRus (ORCPT ); Fri, 3 Jun 2022 13:50: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 5EBF759BAF; Fri, 3 Jun 2022 10:47: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 dfw.source.kernel.org (Postfix) with ESMTPS id 66A6C60C3D; Fri, 3 Jun 2022 17:47:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECBD8C385A9; Fri, 3 Jun 2022 17:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278428; bh=7yMpx/p4JIbj1RxSrsvc4F7sy+yL65SQaQLr9b7p4J4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZU0YgQ8ylEEj8vMI1DlAEdglLFn2EKU7Z3L1O4DKzC3hqJ1VlD9a+leC7PNIgG/FZ nF+fnPgNBmybb+PNm7XgWatQP4cJbLcBLKaZPLtcbZLS2CcLRxTloSikpsY7LHH+j3 olUCFkGoyJqGX3N2D84x+h5zBiZmgBYyVS8JhoVw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+793a590957d9c1b96620@syzkaller.appspotmail.com, Florian Westphal , Pablo Neira Ayuso Subject: [PATCH 5.10 30/53] netfilter: conntrack: re-fetch conntrack after insertion Date: Fri, 3 Jun 2022 19:43:15 +0200 Message-Id: <20220603173819.600692184@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 commit 56b14ecec97f39118bf85c9ac2438c5a949509ed upstream. In case the conntrack is clashing, insertion can free skb->_nfct and set skb->_nfct to the already-confirmed entry. This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger. Reported-by: Fixes: 71d8c47fc653 ("netfilter: conntrack: introduce clash resolution on i= nsertion race") Fixes: 2ad9d7747c10 ("netfilter: conntrack: free extension area immediately= ") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- include/net/netfilter/nf_conntrack_core.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/include/net/netfilter/nf_conntrack_core.h +++ b/include/net/netfilter/nf_conntrack_core.h @@ -59,8 +59,13 @@ static inline int nf_conntrack_confirm(s int ret =3D NF_ACCEPT; =20 if (ct) { - if (!nf_ct_is_confirmed(ct)) + if (!nf_ct_is_confirmed(ct)) { ret =3D __nf_conntrack_confirm(skb); + + if (ret =3D=3D NF_ACCEPT) + ct =3D (struct nf_conn *)skb_nfct(skb); + } + if (likely(ret =3D=3D NF_ACCEPT)) nf_ct_deliver_cached_events(ct); } From nobody Tue Apr 28 06:30:15 2026 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 3AE04C433EF for ; Fri, 3 Jun 2022 17:59:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345956AbiFCR7a (ORCPT ); Fri, 3 Jun 2022 13:59:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346215AbiFCRux (ORCPT ); Fri, 3 Jun 2022 13:50: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 C18905A08F; Fri, 3 Jun 2022 10:47:14 -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 336C6B823B0; Fri, 3 Jun 2022 17:47:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A13AC385A9; Fri, 3 Jun 2022 17:47:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278432; bh=64b60f8+CF+lQiNlhXAdnNtTZB8o0DTFOS04/xU40G4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SrFetdNMGXc/S0IJNfpbEkCPtE5Ap/DPzVKD1i8Jcg/ebbsdohjJ5C93w44h+NF1G eMHQ5cKE4Y8lJeF8W8ip67KJVO0mZANW5xjmFKJcKK0+nxroDl2pLDgZ66ram+NK6l 4t2vuSFnC5GlO/F6y5Z/GXamk7AcLRTe1Tx1b6Lw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiaomeng Tong , Michael Ellerman Subject: [PATCH 5.10 31/53] KVM: PPC: Book3S HV: fix incorrect NULL check on list iterator Date: Fri, 3 Jun 2022 19:43:16 +0200 Message-Id: <20220603173819.628510060@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Xiaomeng Tong commit 300981abddcb13f8f06ad58f52358b53a8096775 upstream. The bug is here: if (!p) return ret; The list iterator value 'p' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, Use a new value 'iter' as the list iterator, while use the old value 'p' as a dedicated variable to point to the found element. Fixes: dfaa973ae960 ("KVM: PPC: Book3S HV: In H_SVM_INIT_DONE, migrate rema= ining normal-GFNs to secure-GFNs") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Xiaomeng Tong Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220414062103.8153-1-xiam0nd.tong@gmail.com Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- arch/powerpc/kvm/book3s_hv_uvmem.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/arch/powerpc/kvm/book3s_hv_uvmem.c +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c @@ -359,13 +359,15 @@ static bool kvmppc_gfn_is_uvmem_pfn(unsi static bool kvmppc_next_nontransitioned_gfn(const struct kvm_memory_slot *= memslot, struct kvm *kvm, unsigned long *gfn) { - struct kvmppc_uvmem_slot *p; + struct kvmppc_uvmem_slot *p =3D NULL, *iter; bool ret =3D false; unsigned long i; =20 - list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) - if (*gfn >=3D p->base_pfn && *gfn < p->base_pfn + p->nr_pfns) + list_for_each_entry(iter, &kvm->arch.uvmem_pfns, list) + if (*gfn >=3D iter->base_pfn && *gfn < iter->base_pfn + iter->nr_pfns) { + p =3D iter; break; + } if (!p) return ret; /* From nobody Tue Apr 28 06:30:15 2026 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 268CAC43334 for ; Fri, 3 Jun 2022 17:59:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346084AbiFCR7h (ORCPT ); Fri, 3 Jun 2022 13:59:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346235AbiFCRuy (ORCPT ); Fri, 3 Jun 2022 13:50:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 930CD5A09A; Fri, 3 Jun 2022 10:47: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 A6C2260A57; Fri, 3 Jun 2022 17:47:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B821EC385A9; Fri, 3 Jun 2022 17:47:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278435; bh=4CV2YYdOdmtQY/EHPZAR8SenSGDXz6x4jpKV19cuIKQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UtaAMXSFh/jUidi3209vJXcff2PlDFoyIri/41GRdi74FUtEb+6TPuRe23CtJ5WJq hL2wUWCioEWXS7HNYK9CzKVWbt8oGEcrqrpmkKCPD8t6zZUCPlJq9x1PYYcyt+/VFE Xh2iPgyY2ybo+Pjb2MRpK2pgjKN1Y1IR66ttM7G0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yajun Deng , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.10 32/53] x86/kvm: Alloc dummy async #PF token outside of raw spinlock Date: Fri, 3 Jun 2022 19:43:17 +0200 Message-Id: <20220603173819.658900854@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Sean Christopherson commit 0547758a6de3cc71a0cfdd031a3621a30db6a68b upstream. Drop the raw spinlock in kvm_async_pf_task_wake() before allocating the the dummy async #PF token, the allocator is preemptible on PREEMPT_RT kernels and must not be called from truly atomic contexts. Opportunistically document why it's ok to loop on allocation failure, i.e. why the function won't get stuck in an infinite loop. Reported-by: Yajun Deng Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- arch/x86/kernel/kvm.c | 41 +++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 14 deletions(-) --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -188,7 +188,7 @@ void kvm_async_pf_task_wake(u32 token) { u32 key =3D hash_32(token, KVM_TASK_SLEEP_HASHBITS); struct kvm_task_sleep_head *b =3D &async_pf_sleepers[key]; - struct kvm_task_sleep_node *n; + struct kvm_task_sleep_node *n, *dummy =3D NULL; =20 if (token =3D=3D ~0) { apf_task_wake_all(); @@ -200,28 +200,41 @@ again: n =3D _find_apf_task(b, token); if (!n) { /* - * async PF was not yet handled. - * Add dummy entry for the token. + * Async #PF not yet handled, add a dummy entry for the token. + * Allocating the token must be down outside of the raw lock + * as the allocator is preemptible on PREEMPT_RT kernels. */ - n =3D kzalloc(sizeof(*n), GFP_ATOMIC); - if (!n) { + if (!dummy) { + raw_spin_unlock(&b->lock); + dummy =3D kzalloc(sizeof(*dummy), GFP_KERNEL); + /* - * Allocation failed! Busy wait while other cpu - * handles async PF. + * Continue looping on allocation failure, eventually + * the async #PF will be handled and allocating a new + * node will be unnecessary. + */ + if (!dummy) + cpu_relax(); + + /* + * Recheck for async #PF completion before enqueueing + * the dummy token to avoid duplicate list entries. */ - raw_spin_unlock(&b->lock); - cpu_relax(); goto again; } - n->token =3D token; - n->cpu =3D smp_processor_id(); - init_swait_queue_head(&n->wq); - hlist_add_head(&n->link, &b->list); + dummy->token =3D token; + dummy->cpu =3D smp_processor_id(); + init_swait_queue_head(&dummy->wq); + hlist_add_head(&dummy->link, &b->list); + dummy =3D NULL; } else { apf_task_wake_one(n); } raw_spin_unlock(&b->lock); - return; + + /* A dummy token might be allocated and ultimately not used. */ + if (dummy) + kfree(dummy); } EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake); From nobody Tue Apr 28 06:30:15 2026 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 B034ACCA480 for ; Fri, 3 Jun 2022 17:56:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241354AbiFCR4S (ORCPT ); Fri, 3 Jun 2022 13:56:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346249AbiFCRuy (ORCPT ); Fri, 3 Jun 2022 13:50:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E5395A0A6; Fri, 3 Jun 2022 10:47: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 C0F2B604EF; Fri, 3 Jun 2022 17:47:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCD91C385B8; Fri, 3 Jun 2022 17:47:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278438; bh=HgO/YYUBUaikVJTuqzSnhSDHKguXOeaqQnh/CGNBQlo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u/tl/xCVUs9hBRTAjQhpLrxgh0fGYmYJO/LvNSjN/kkgCZbA4Z7d4zDM6Nh9/KoiS fvmm52hbaZhGjaNV85p0GRHTL+jA6DF0+QasuVJnyOJ6QaIdQgUa8uc9D9UlzI6qaW f4KZ9CLyxVjI/qpmMZXQ50NXfRCqshdyZEx3pVCk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Paolo Bonzini Subject: [PATCH 5.10 33/53] x86, kvm: use correct GFP flags for preemption disabled Date: Fri, 3 Jun 2022 19:43:18 +0200 Message-Id: <20220603173819.687439393@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Paolo Bonzini commit baec4f5a018fe2d708fc1022330dba04b38b5fe3 upstream. Commit ddd7ed842627 ("x86/kvm: Alloc dummy async #PF token outside of raw spinlock") leads to the following Smatch static checker warning: arch/x86/kernel/kvm.c:212 kvm_async_pf_task_wake() warn: sleeping in atomic context arch/x86/kernel/kvm.c 202 raw_spin_lock(&b->lock); 203 n =3D _find_apf_task(b, token); 204 if (!n) { 205 /* 206 * Async #PF not yet handled, add a dummy entry for= the token. 207 * Allocating the token must be down outside of the= raw lock 208 * as the allocator is preemptible on PREEMPT_RT ke= rnels. 209 */ 210 if (!dummy) { 211 raw_spin_unlock(&b->lock); --> 212 dummy =3D kzalloc(sizeof(*dummy), GFP_KERNE= L); ^^^^^^^^^^ Smatch thinks the caller has preempt disabled. The `smdb.py preempt kvm_async_pf_task_wake` output call tree is: sysvec_kvm_asyncpf_interrupt() <- disables preempt -> __sysvec_kvm_asyncpf_interrupt() -> kvm_async_pf_task_wake() The caller is this: arch/x86/kernel/kvm.c 290 DEFINE_IDTENTRY_SYSVEC(sysvec_kvm_asyncpf_interrupt) 291 { 292 struct pt_regs *old_regs =3D set_irq_regs(regs); 293 u32 token; 294 295 ack_APIC_irq(); 296 297 inc_irq_stat(irq_hv_callback_count); 298 299 if (__this_cpu_read(apf_reason.enabled)) { 300 token =3D __this_cpu_read(apf_reason.token); 301 kvm_async_pf_task_wake(token); 302 __this_cpu_write(apf_reason.token, 0); 303 wrmsrl(MSR_KVM_ASYNC_PF_ACK, 1); 304 } 305 306 set_irq_regs(old_regs); 307 } The DEFINE_IDTENTRY_SYSVEC() is a wrapper that calls this function from the call_on_irqstack_cond(). It's inside the call_on_irqstack_cond() where preempt is disabled (unless it's already disabled). The irq_enter/exit_rcu() functions disable/enable preempt. Reported-by: Dan Carpenter Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- arch/x86/kernel/kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -206,7 +206,7 @@ again: */ if (!dummy) { raw_spin_unlock(&b->lock); - dummy =3D kzalloc(sizeof(*dummy), GFP_KERNEL); + dummy =3D kzalloc(sizeof(*dummy), GFP_ATOMIC); =20 /* * Continue looping on allocation failure, eventually From nobody Tue Apr 28 06:30:15 2026 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 8CDBAC433EF for ; Fri, 3 Jun 2022 17:59:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346171AbiFCR7n (ORCPT ); Fri, 3 Jun 2022 13:59:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346266AbiFCRuz (ORCPT ); Fri, 3 Jun 2022 13:50:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B625853E17; Fri, 3 Jun 2022 10:47: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 65F39B82419; Fri, 3 Jun 2022 17:47:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7E72C3411C; Fri, 3 Jun 2022 17:47:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278441; bh=Fs21flBi8rskNmGB/wYdHLUt89Tc48X3AqqhqIkacvU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xOvhvv2dULnUQkVfTFPPRYmWzWutI3RHGBK8X8VPJJx2VE8VaImJ+/AafzLFeIVvz e/elV6i9PKZkhrPE/JIgX+O4IQTkq6WdwfSsMROaxuvgjpgDgCD4ekM4zCY6CtdaCT sSyMGbKfBDCmQFCRRyGZJaAIwyzuu+2BhBjbS6q8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qiuhao Li , Gaoning Pan , Yongkang Jia , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.10 34/53] KVM: x86: avoid calling x86 emulator without a decoded instruction Date: Fri, 3 Jun 2022 19:43:19 +0200 Message-Id: <20220603173819.716227512@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Sean Christopherson commit fee060cd52d69c114b62d1a2948ea9648b5131f9 upstream. Whenever x86_decode_emulated_instruction() detects a breakpoint, it returns the value that kvm_vcpu_check_breakpoint() writes into its pass-by-reference second argument. Unfortunately this is completely bogus because the expected outcome of x86_decode_emulated_instruction is an EMULATION_* value. Then, if kvm_vcpu_check_breakpoint() does "*r =3D 0" (corresponding to a KVM_EXIT_DEBUG userspace exit), it is misunderstood as EMULATION_OK and x86_emulate_instruction() is called without having decoded the instruction. This causes various havoc from running with a stale emulation context. The fix is to move the call to kvm_vcpu_check_breakpoint() where it was before commit 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction emulation with decoding") introduced x86_decode_emulated_instruction(). The other caller of the function does not need breakpoint checks, because it is invoked as part of a vmexit and the processor has already checked those before executing the instruction that #GP'd. This fixes CVE-2022-1852. Reported-by: Qiuhao Li Reported-by: Gaoning Pan Reported-by: Yongkang Jia Fixes: 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction emulation with d= ecoding") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20220311032801.3467418-2-seanjc@google.com> [Rewrote commit message according to Qiuhao's report, since a patch already existed to fix the bug. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- arch/x86/kvm/x86.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7295,7 +7295,7 @@ int kvm_skip_emulated_instruction(struct } EXPORT_SYMBOL_GPL(kvm_skip_emulated_instruction); =20 -static bool kvm_vcpu_check_breakpoint(struct kvm_vcpu *vcpu, int *r) +static bool kvm_vcpu_check_code_breakpoint(struct kvm_vcpu *vcpu, int *r) { if (unlikely(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) && (vcpu->arch.guest_debug_dr7 & DR7_BP_EN_MASK)) { @@ -7364,25 +7364,23 @@ static bool is_vmware_backdoor_opcode(st } =20 /* - * Decode to be emulated instruction. Return EMULATION_OK if success. + * Decode an instruction for emulation. The caller is responsible for han= dling + * code breakpoints. Note, manually detecting code breakpoints is unneces= sary + * (and wrong) when emulating on an intercepted fault-like exception[*], as + * code breakpoints have higher priority and thus have already been done by + * hardware. + * + * [*] Except #MC, which is higher priority, but KVM should never emulate = in + * response to a machine check. */ int x86_decode_emulated_instruction(struct kvm_vcpu *vcpu, int emulation_t= ype, void *insn, int insn_len) { - int r =3D EMULATION_OK; struct x86_emulate_ctxt *ctxt =3D vcpu->arch.emulate_ctxt; + int r; =20 init_emulate_ctxt(vcpu); =20 - /* - * We will reenter on the same instruction since we do not set - * complete_userspace_io. This does not handle watchpoints yet, - * those would be handled in the emulate_ops. - */ - if (!(emulation_type & EMULTYPE_SKIP) && - kvm_vcpu_check_breakpoint(vcpu, &r)) - return r; - ctxt->ud =3D emulation_type & EMULTYPE_TRAP_UD; =20 r =3D x86_decode_insn(ctxt, insn, insn_len); @@ -7417,6 +7415,15 @@ int x86_emulate_instruction(struct kvm_v if (!(emulation_type & EMULTYPE_NO_DECODE)) { kvm_clear_exception_queue(vcpu); =20 + /* + * Return immediately if RIP hits a code breakpoint, such #DBs + * are fault-like and are higher priority than any faults on + * the code fetch itself. + */ + if (!(emulation_type & EMULTYPE_SKIP) && + kvm_vcpu_check_code_breakpoint(vcpu, &r)) + return r; + r =3D x86_decode_emulated_instruction(vcpu, emulation_type, insn, insn_len); if (r !=3D EMULATION_OK) { From nobody Tue Apr 28 06:30:15 2026 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 61630C433EF for ; Fri, 3 Jun 2022 17:56:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239219AbiFCR42 (ORCPT ); Fri, 3 Jun 2022 13:56:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346299AbiFCRvD (ORCPT ); Fri, 3 Jun 2022 13:51:03 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BB635400C; Fri, 3 Jun 2022 10:47:27 -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 539E6B823B0; Fri, 3 Jun 2022 17:47:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 984F5C385A9; Fri, 3 Jun 2022 17:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278444; bh=tSQXz/ZFbI2pYTh4TigjjrPwJuuXCKdaX9A7q3dypck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AhTTo7nQN7CvEfTPfyXFPoUGlkrlG1T5se+xmQ597i8ZiixEtTD/3qkld6OVX2/j8 b6wHAnLXknJtpK5BUidVZ5GJ1qDmy7N4LW0biJZcLUgakUKNqdx4tC38qjDhTy5J+v aKtl6fNzCLWU7SNv36YeN3G0AI/a2tPHkhHVBZFM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Fabio Estevam , =?UTF-8?q?Horia=20Geant=C4=83?= , Vabhav Sharma , Gaurav Jain , Herbert Xu Subject: [PATCH 5.10 35/53] crypto: caam - fix i.MX6SX entropy delay value Date: Fri, 3 Jun 2022 19:43:20 +0200 Message-Id: <20220603173819.744914090@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Fabio Estevam commit 4ee4cdad368a26de3967f2975806a9ee2fa245df upstream. Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG") the following CAAM errors can be seen on i.MX6SX: caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error hwrng: no data available This error is due to an incorrect entropy delay for i.MX6SX. Fix it by increasing the minimum entropy delay for i.MX6SX as done in U-Boot: https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-g= aurav.jain@nxp.com/ As explained in the U-Boot patch: "RNG self tests are run to determine the correct entropy delay. Such tests are executed with different voltages and temperatures to identify the worst case value for the entropy delay. For i.MX6SX, it was determined that after adding a margin value of 1000 the minimum entropy delay should be at least 12000." Cc: Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG") Signed-off-by: Fabio Estevam Reviewed-by: Horia Geant=C4=83 Reviewed-by: Vabhav Sharma Reviewed-by: Gaurav Jain Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/crypto/caam/ctrl.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/crypto/caam/ctrl.c +++ b/drivers/crypto/caam/ctrl.c @@ -609,6 +609,13 @@ static bool check_version(struct fsl_mc_ } #endif =20 +static bool needs_entropy_delay_adjustment(void) +{ + if (of_machine_is_compatible("fsl,imx6sx")) + return true; + return false; +} + /* Probe routine for CAAM top (controller) level */ static int caam_probe(struct platform_device *pdev) { @@ -855,6 +862,8 @@ static int caam_probe(struct platform_de * Also, if a handle was instantiated, do not change * the TRNG parameters. */ + if (needs_entropy_delay_adjustment()) + ent_delay =3D 12000; if (!(ctrlpriv->rng4_sh_init || inst_handles)) { dev_info(dev, "Entropy delay =3D %u\n", @@ -871,6 +880,15 @@ static int caam_probe(struct platform_de */ ret =3D instantiate_rng(dev, inst_handles, gen_sk); + /* + * Entropy delay is determined via TRNG characterization. + * TRNG characterization is run across different voltages + * and temperatures. + * If worst case value for ent_dly is identified, + * the loop can be skipped for that platform. + */ + if (needs_entropy_delay_adjustment()) + break; if (ret =3D=3D -EAGAIN) /* * if here, the loop will rerun, From nobody Tue Apr 28 06:30:15 2026 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 06B82C43334 for ; Fri, 3 Jun 2022 17:59:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346178AbiFCR7q (ORCPT ); Fri, 3 Jun 2022 13:59:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346313AbiFCRvE (ORCPT ); Fri, 3 Jun 2022 13:51: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 F38F65372D; Fri, 3 Jun 2022 10:47:27 -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 83DAB60A0F; Fri, 3 Jun 2022 17:47:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84E26C385A9; Fri, 3 Jun 2022 17:47:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278446; bh=sQ0GPSl5NoQwPN9POfGGNsMy+Sxch4CTIxQGvcHIVJU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g90jNOUm3qi7wUq/iPH57bApQtGrtWlEst3S7sBv9rFp65fpYIIKZrSV1ObJZ7+99 YRoCmM6FeRPsruJe2PAsnVpGBp7AS+OIhNDlvboDJzDRNkOeLKnstTgVVrR0PSkT/U ubxTfcGKZpEDD5/LT5BClXESfKIOVQxNXKKak2wU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vitaly Chikunov , Herbert Xu Subject: [PATCH 5.10 36/53] crypto: ecrdsa - Fix incorrect use of vli_cmp Date: Fri, 3 Jun 2022 19:43:21 +0200 Message-Id: <20220603173819.772771364@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Vitaly Chikunov commit 7cc7ab73f83ee6d50dc9536bc3355495d8600fad upstream. Correctly compare values that shall be greater-or-equal and not just greater. Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Cc: Signed-off-by: Vitaly Chikunov Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- crypto/ecrdsa.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/crypto/ecrdsa.c +++ b/crypto/ecrdsa.c @@ -113,15 +113,15 @@ static int ecrdsa_verify(struct akcipher =20 /* Step 1: verify that 0 < r < q, 0 < s < q */ if (vli_is_zero(r, ndigits) || - vli_cmp(r, ctx->curve->n, ndigits) =3D=3D 1 || + vli_cmp(r, ctx->curve->n, ndigits) >=3D 0 || vli_is_zero(s, ndigits) || - vli_cmp(s, ctx->curve->n, ndigits) =3D=3D 1) + vli_cmp(s, ctx->curve->n, ndigits) >=3D 0) return -EKEYREJECTED; =20 /* Step 2: calculate hash (h) of the message (passed as input) */ /* Step 3: calculate e =3D h \mod q */ vli_from_le64(e, digest, ndigits); - if (vli_cmp(e, ctx->curve->n, ndigits) =3D=3D 1) + if (vli_cmp(e, ctx->curve->n, ndigits) >=3D 0) vli_sub(e, e, ctx->curve->n, ndigits); if (vli_is_zero(e, ndigits)) e[0] =3D 1; @@ -137,7 +137,7 @@ static int ecrdsa_verify(struct akcipher /* Step 6: calculate point C =3D z_1P + z_2Q, and R =3D x_c \mod q */ ecc_point_mult_shamir(&cc, z1, &ctx->curve->g, z2, &ctx->pub_key, ctx->curve); - if (vli_cmp(cc.x, ctx->curve->n, ndigits) =3D=3D 1) + if (vli_cmp(cc.x, ctx->curve->n, ndigits) >=3D 0) vli_sub(cc.x, cc.x, ctx->curve->n, ndigits); =20 /* Step 7: if R =3D=3D r signature is valid */ From nobody Tue Apr 28 06:30:15 2026 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 B933BC43334 for ; Fri, 3 Jun 2022 17:56:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345807AbiFCR4Y (ORCPT ); Fri, 3 Jun 2022 13:56:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346325AbiFCRvE (ORCPT ); Fri, 3 Jun 2022 13:51:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C218D54020; Fri, 3 Jun 2022 10:47: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 7DFD3B823B0; Fri, 3 Jun 2022 17:47:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C78AC3411C; Fri, 3 Jun 2022 17:47:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278450; bh=V/yGTt7Ocp4ajWdl5FHnoH8c4RKdCJlTJGqL+no4af0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CI+ZXyKWUfXJaEliAU14xeyRbAkYLjq8qibbJ/E/j2NrdPSH3cLawwhnafVlhBeiJ RN5FYfyacyPY3Ho7KjBivf9IKihRNPCirA73GufBelTjS2+QVlrmYyoTSFrJ1gyLBH dZmfkP1Gb85cSenX5daB44m8oJ+BxHhBZRw+qR6s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sultan Alsawaf , Minchan Kim , Nitin Gupta , Sergey Senozhatsky , Andrew Morton Subject: [PATCH 5.10 37/53] zsmalloc: fix races between asynchronous zspage free and page migration Date: Fri, 3 Jun 2022 19:43:22 +0200 Message-Id: <20220603173819.801075996@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Sultan Alsawaf commit 2505a981114dcb715f8977b8433f7540854851d8 upstream. The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration. Link: https://lkml.kernel.org/r/20220509024703.243847-1-sultan@kerneltoast.= com Fixes: 77ff465799c602 ("zsmalloc: zs_page_migrate: skip unnecessary loops b= ut not return -EBUSY if zspage is not inuse") Signed-off-by: Sultan Alsawaf Acked-by: Minchan Kim Cc: Nitin Gupta Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- mm/zsmalloc.c | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1748,11 +1748,40 @@ static enum fullness_group putback_zspag */ static void lock_zspage(struct zspage *zspage) { - struct page *page =3D get_first_page(zspage); + struct page *curr_page, *page; =20 - do { - lock_page(page); - } while ((page =3D get_next_page(page)) !=3D NULL); + /* + * Pages we haven't locked yet can be migrated off the list while we're + * trying to lock them, so we need to be careful and only attempt to + * lock each page under migrate_read_lock(). Otherwise, the page we lock + * may no longer belong to the zspage. This means that we may wait for + * the wrong page to unlock, so we must take a reference to the page + * prior to waiting for it to unlock outside migrate_read_lock(). + */ + while (1) { + migrate_read_lock(zspage); + page =3D get_first_page(zspage); + if (trylock_page(page)) + break; + get_page(page); + migrate_read_unlock(zspage); + wait_on_page_locked(page); + put_page(page); + } + + curr_page =3D page; + while ((page =3D get_next_page(curr_page))) { + if (trylock_page(page)) { + curr_page =3D page; + } else { + get_page(page); + migrate_read_unlock(zspage); + wait_on_page_locked(page); + put_page(page); + migrate_read_lock(zspage); + } + } + migrate_read_unlock(zspage); } =20 static int zs_init_fs_context(struct fs_context *fc) From nobody Tue Apr 28 06:30:15 2026 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 9116FCCA489 for ; Fri, 3 Jun 2022 18:07:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347731AbiFCSGO (ORCPT ); Fri, 3 Jun 2022 14:06:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346337AbiFCRvF (ORCPT ); Fri, 3 Jun 2022 13:51:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CCA0544E8; Fri, 3 Jun 2022 10:47:39 -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 B3C12B82189; Fri, 3 Jun 2022 17:47:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F23E8C385A9; Fri, 3 Jun 2022 17:47:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278456; bh=BVFr+pAZdwYA4VJCP8WE7tfQLDjYn0csV1UYSw2SV0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ta791vTtSp0YeimrYbWtzds9Arftdvj6zZjM64MWT1acZt5S0mBLhpvTQvO8K0RTK ltEcaGLdqAYJU5M6wZYSws4q2TKa9FM+eGXV3v+f+ZeFUd92bdlPNcFR2gIsc7cPBg 9ierXPfRYvsfr6i5EmIU4To8oKf2ULBuysfYtT1w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , "Steven Rostedt (Google)" , Marcel Holtmann Subject: [PATCH 5.10 38/53] Bluetooth: hci_qca: Use del_timer_sync() before freeing Date: Fri, 3 Jun 2022 19:43:23 +0200 Message-Id: <20220603173819.829448877@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Steven Rostedt commit 72ef98445aca568a81c2da050532500a8345ad3a upstream. While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync(). Cc: Eric Dumazet Cc: stable@vger.kernel.org Fixes: 0ff252c1976da ("Bluetooth: hciuart: Add support QCA chipset for UART= ") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/bluetooth/hci_qca.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -689,9 +689,9 @@ static int qca_close(struct hci_uart *hu skb_queue_purge(&qca->tx_wait_q); skb_queue_purge(&qca->txq); skb_queue_purge(&qca->rx_memdump_q); - del_timer(&qca->tx_idle_timer); - del_timer(&qca->wake_retrans_timer); destroy_workqueue(qca->workqueue); + del_timer_sync(&qca->tx_idle_timer); + del_timer_sync(&qca->wake_retrans_timer); qca->hu =3D NULL; =20 kfree_skb(qca->rx_skb); From nobody Tue Apr 28 06:30:15 2026 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 1861CCCA48A for ; Fri, 3 Jun 2022 18:07:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347640AbiFCSGL (ORCPT ); Fri, 3 Jun 2022 14:06:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346343AbiFCRvG (ORCPT ); Fri, 3 Jun 2022 13:51:06 -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 064A054BCD; Fri, 3 Jun 2022 10:47: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 B25E0B82189; Fri, 3 Jun 2022 17:47:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07CE0C385A9; Fri, 3 Jun 2022 17:47:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278459; bh=40Dw1jN3ldvZgbMeHGnjn/t9svfNtIvS+9qMXPFOHNc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SQya78MlU0wu7LbWDhutTnASZq08De7xJLN7sAR37N7yX9drSEeVGM8UlWQg/1yeg fSwDsxJ+gwsiDZ3ax27jFEsaR8mh+Z6schqYCjN14LJHJHDR2GaFNdNciTrmU5RtSA l+HpIp85eeT15T7vutL45JcIIYKdXJA1VXAvAHDE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jonathan Bakker , Krzysztof Kozlowski Subject: [PATCH 5.10 39/53] ARM: dts: s5pv210: Correct interrupt name for bluetooth in Aries Date: Fri, 3 Jun 2022 19:43:24 +0200 Message-Id: <20220603173819.858782061@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 Bakker commit 3f5e3d3a8b895c8a11da8b0063ba2022dd9e2045 upstream. Correct the name of the bluetooth interrupt from host-wake to host-wakeup. Fixes: 1c65b6184441b ("ARM: dts: s5pv210: Correct BCM4329 bluetooth node") Cc: Signed-off-by: Jonathan Bakker Link: https://lore.kernel.org/r/CY4PR04MB0567495CFCBDC8D408D44199CB1C9@CY4P= R04MB0567.namprd04.prod.outlook.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- arch/arm/boot/dts/s5pv210-aries.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/s5pv210-aries.dtsi +++ b/arch/arm/boot/dts/s5pv210-aries.dtsi @@ -896,7 +896,7 @@ device-wakeup-gpios =3D <&gpg3 4 GPIO_ACTIVE_HIGH>; interrupt-parent =3D <&gph2>; interrupts =3D <5 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names =3D "host-wake"; + interrupt-names =3D "host-wakeup"; }; }; From nobody Tue Apr 28 06:30:15 2026 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 C8AC7CCA48E for ; Fri, 3 Jun 2022 18:07:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347558AbiFCSGI (ORCPT ); Fri, 3 Jun 2022 14:06:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346349AbiFCRvG (ORCPT ); Fri, 3 Jun 2022 13:51:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A743654BDA; Fri, 3 Jun 2022 10:47: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 dfw.source.kernel.org (Postfix) with ESMTPS id 1789260EE9; Fri, 3 Jun 2022 17:47:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22192C385A9; Fri, 3 Jun 2022 17:47:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278462; bh=8J6A5geKPVvuD2x5UavjHBtKad8WfOYc+Ka14cVs3HU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=STVeq1DZ88cqGdFrFNFCJcxKrGXqIL8uGMKTKGpCFRoUB7iznXmS6AdhVV2y3iOXk 1JfWoZeK49qLkDsRp1XKBcopu1YiafZVfnfDY/BtxqK9VLDk6vZ3UDRaJaK8HcsHAp rRH8jzktJGPFdwl9O6mUcjz/yxuNW5tWmTQhh88s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Mikulas Patocka , Mike Snitzer Subject: [PATCH 5.10 40/53] dm integrity: fix error code in dm_integrity_ctr() Date: Fri, 3 Jun 2022 19:43:25 +0200 Message-Id: <20220603173819.887024892@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Dan Carpenter commit d3f2a14b8906df913cb04a706367b012db94a6e8 upstream. The "r" variable shadows an earlier "r" that has function scope. It means that we accidentally return success instead of an error code. Smatch has a warning for this: drivers/md/dm-integrity.c:4503 dm_integrity_ctr() warn: missing error code 'r' Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/md/dm-integrity.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -4327,8 +4327,6 @@ try_smaller_buffer: } =20 if (should_write_sb) { - int r; - init_journal(ic, 0, ic->journal_sections, 0); r =3D dm_integrity_failed(ic); if (unlikely(r)) { From nobody Tue Apr 28 06:30:15 2026 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 E9816CCA487 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347503AbiFCSGF (ORCPT ); Fri, 3 Jun 2022 14:06:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346357AbiFCRvG (ORCPT ); Fri, 3 Jun 2022 13:51:06 -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 CB41C54BF2; Fri, 3 Jun 2022 10:47:46 -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 5E5FE60F36; Fri, 3 Jun 2022 17:47:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 192C1C385A9; Fri, 3 Jun 2022 17:47:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278465; bh=q0pXpUrywR1EhwQ+Bo3vKia0ydjXRDE8ufJ1eppQkXg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wAvBSg1Hwnz26JUeU1t2qpYzhwDqsSDaEiOjW3BYXZD5tKYFDxCrJGA7dkX6hvif/ u+CpYVx/yjwlDfm7gIiyttBSRPlN6QPASmGQN2G7tfP650YnpzgUDAWbZAv1EnTDFh pOB0YaCrl5kgb9qJUsLp0HqcS5nnXF4vULnSN6So= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikulas Patocka , Milan Broz , Mike Snitzer Subject: [PATCH 5.10 41/53] dm crypt: make printing of the key constant-time Date: Fri, 3 Jun 2022 19:43:26 +0200 Message-Id: <20220603173819.915827409@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Mikulas Patocka commit 567dd8f34560fa221a6343729474536aa7ede4fd upstream. The device mapper dm-crypt target is using scnprintf("%02x", cc->key[i]) to report the current key to userspace. However, this is not a constant-time operation and it may leak information about the key via timing, via cache access patterns or via the branch predictor. Change dm-crypt's key printing to use "%c" instead of "%02x". Also introduce hex2asc() that carefully avoids any branching or memory accesses when converting a number in the range 0 ... 15 to an ascii character. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Tested-by: Milan Broz Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/md/dm-crypt.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -3404,6 +3404,11 @@ static int crypt_map(struct dm_target *t return DM_MAPIO_SUBMITTED; } =20 +static char hex2asc(unsigned char c) +{ + return c + '0' + ((unsigned)(9 - c) >> 4 & 0x27); +} + static void crypt_status(struct dm_target *ti, status_type_t type, unsigned status_flags, char *result, unsigned maxlen) { @@ -3422,9 +3427,12 @@ static void crypt_status(struct dm_targe if (cc->key_size > 0) { if (cc->key_string) DMEMIT(":%u:%s", cc->key_size, cc->key_string); - else - for (i =3D 0; i < cc->key_size; i++) - DMEMIT("%02x", cc->key[i]); + else { + for (i =3D 0; i < cc->key_size; i++) { + DMEMIT("%c%c", hex2asc(cc->key[i] >> 4), + hex2asc(cc->key[i] & 0xf)); + } + } } else DMEMIT("-"); From nobody Tue Apr 28 06:30:15 2026 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 CDD39CCA488 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347447AbiFCSGA (ORCPT ); Fri, 3 Jun 2022 14:06:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346361AbiFCRvG (ORCPT ); Fri, 3 Jun 2022 13:51:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A101854BFC; Fri, 3 Jun 2022 10:47: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 dfw.source.kernel.org (Postfix) with ESMTPS id 2B4EE604EF; Fri, 3 Jun 2022 17:47:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F8A7C385B8; Fri, 3 Jun 2022 17:47:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278468; bh=NnEyWjMihEvGC1ycsFdaXgQ+EWmAJe/cwgy1WOjErkM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IyBYEftoQoio5Z1QwBioYoH6ychr6yVSXGY8SFPwA4FpBep0BSHbrsSB1P41ibZKV IMzmMVzn/ic1E4ixT9fU1TJTTiNvrc8WWn2Vhue3IvkPWPrMTf6hpNeypSI1qGlQnn W4h8OSeW4y9q72n86EBAp7749JbCET1KWnW5ck7M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mikulas Patocka , Mike Snitzer Subject: [PATCH 5.10 42/53] dm stats: add cond_resched when looping over entries Date: Fri, 3 Jun 2022 19:43:27 +0200 Message-Id: <20220603173819.944245381@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Mikulas Patocka commit bfe2b0146c4d0230b68f5c71a64380ff8d361f8b upstream. dm-stats can be used with a very large number of entries (it is only limited by 1/4 of total system memory), so add rescheduling points to the loops that iterate over the entries. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/md/dm-stats.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/md/dm-stats.c +++ b/drivers/md/dm-stats.c @@ -224,6 +224,7 @@ void dm_stats_cleanup(struct dm_stats *s atomic_read(&shared->in_flight[READ]), atomic_read(&shared->in_flight[WRITE])); } + cond_resched(); } dm_stat_free(&s->rcu_head); } @@ -313,6 +314,7 @@ static int dm_stats_create(struct dm_sta for (ni =3D 0; ni < n_entries; ni++) { atomic_set(&s->stat_shared[ni].in_flight[READ], 0); atomic_set(&s->stat_shared[ni].in_flight[WRITE], 0); + cond_resched(); } =20 if (s->n_histogram_entries) { @@ -325,6 +327,7 @@ static int dm_stats_create(struct dm_sta for (ni =3D 0; ni < n_entries; ni++) { s->stat_shared[ni].tmp.histogram =3D hi; hi +=3D s->n_histogram_entries + 1; + cond_resched(); } } =20 @@ -345,6 +348,7 @@ static int dm_stats_create(struct dm_sta for (ni =3D 0; ni < n_entries; ni++) { p[ni].histogram =3D hi; hi +=3D s->n_histogram_entries + 1; + cond_resched(); } } } @@ -474,6 +478,7 @@ static int dm_stats_list(struct dm_stats } DMEMIT("\n"); } + cond_resched(); } mutex_unlock(&stats->mutex); =20 @@ -750,6 +755,7 @@ static void __dm_stat_clear(struct dm_st local_irq_enable(); } } + cond_resched(); } } =20 @@ -865,6 +871,8 @@ static int dm_stats_print(struct dm_stat =20 if (unlikely(sz + 1 >=3D maxlen)) goto buffer_overflow; + + cond_resched(); } =20 if (clear) From nobody Tue Apr 28 06:30:15 2026 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 AFE98CCA485 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347373AbiFCSF5 (ORCPT ); Fri, 3 Jun 2022 14:05:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346382AbiFCRvH (ORCPT ); Fri, 3 Jun 2022 13:51: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 4EA4454BEE; Fri, 3 Jun 2022 10:47: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 ams.source.kernel.org (Postfix) with ESMTPS id F1EBBB82419; Fri, 3 Jun 2022 17:47:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 455AFC385A9; Fri, 3 Jun 2022 17:47:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278471; bh=Q8CnHLsLepW4XKMWQD92Z0o3evO6/YHu3TkLR5iToKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cnETZ8Mz7P4DY+Dvr+1WDDa64W+4Cn+C3AYWTI9SkoLOx3TWoN10dJhLem3KrTAJ1 6pxZrodxmmBy2MSoLl4zHE8XGR9+/M0L1RbcEUaUiroY0nhAGMDeLaoWpDsmoTfX9k XAjdpCzWi3oBGAAK/X0j8D323fSD9jh0VoBCHxI0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sarthak Kukreti , Kees Cook , Mike Snitzer Subject: [PATCH 5.10 43/53] dm verity: set DM_TARGET_IMMUTABLE feature flag Date: Fri, 3 Jun 2022 19:43:28 +0200 Message-Id: <20220603173819.973095357@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Sarthak Kukreti commit 4caae58406f8ceb741603eee460d79bacca9b1b5 upstream. The device-mapper framework provides a mechanism to mark targets as immutable (and hence fail table reloads that try to change the target type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's feature flags to prevent switching the verity target with a different target type. Fixes: a4ffc152198e ("dm: add verity target") Cc: stable@vger.kernel.org Signed-off-by: Sarthak Kukreti Reviewed-by: Kees Cook Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/md/dm-verity-target.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -1242,6 +1242,7 @@ bad: =20 static struct target_type verity_target =3D { .name =3D "verity", + .features =3D DM_TARGET_IMMUTABLE, .version =3D {1, 7, 0}, .module =3D THIS_MODULE, .ctr =3D verity_ctr, From nobody Tue Apr 28 06:30:15 2026 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 A0BCECCA486 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347272AbiFCSFw (ORCPT ); Fri, 3 Jun 2022 14:05:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346390AbiFCRvH (ORCPT ); Fri, 3 Jun 2022 13:51:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DE4354F9E; Fri, 3 Jun 2022 10:47:55 -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 27DE060F36; Fri, 3 Jun 2022 17:47:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 351C2C385A9; Fri, 3 Jun 2022 17:47:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278474; bh=YrXhbiJph5afatE3srEUKuLmWGYAxVpDpkaWS5nFUjw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GD2iD4s8B3rjGIX1aC0kaC1sk7I+KYvoGn1BG8ezNut0pxly5xONimt6FocD9ME3M ugbZDSBzay3rtIUWupO6ufh65z3zyIVXGGHffMVAXyUMnPXZKyxtO3PVPIwRxQ19Ji gAOjOOYqFS3Nxs/0n92keDAnFLf8H8A5Ouc16CS0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mariusz Tkaczyk , Song Liu , Xiao Ni Subject: [PATCH 5.10 44/53] raid5: introduce MD_BROKEN Date: Fri, 3 Jun 2022 19:43:29 +0200 Message-Id: <20220603173820.001200691@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Mariusz Tkaczyk commit 57668f0a4cc4083a120cc8c517ca0055c4543b59 upstream. Raid456 module had allowed to achieve failed state. It was fixed by fb73b357fb9 ("raid5: block failing device if raid will be failed"). This fix introduces a bug, now if raid5 fails during IO, it may result with a hung task without completion. Faulty flag on the device is necessary to process all requests and is checked many times, mainly in analyze_stripe(). Allow to set faulty on drive again and set MD_BROKEN if raid is failed. As a result, this level is allowed to achieve failed state again, but communication with userspace (via -EBUSY status) will be preserved. This restores possibility to fail array via #mdadm --set-faulty command and will be fixed by additional verification on mdadm side. Reproduction steps: mdadm -CR imsm -e imsm -n 3 /dev/nvme[0-2]n1 mdadm -CR r5 -e imsm -l5 -n3 /dev/nvme[0-2]n1 --assume-clean mkfs.xfs /dev/md126 -f mount /dev/md126 /mnt/root/ fio --filename=3D/mnt/root/file --size=3D5GB --direct=3D1 --rw=3Drandrw --bs=3D64k --ioengine=3Dlibaio --iodepth=3D64 --runtime=3D240 --numjobs=3D4 --time_based --group_reporting --name=3Dthroughput-test-job --eta-newline=3D1 & echo 1 > /sys/block/nvme2n1/device/device/remove echo 1 > /sys/block/nvme1n1/device/device/remove [ 1475.787779] Call Trace: [ 1475.793111] __schedule+0x2a6/0x700 [ 1475.799460] schedule+0x38/0xa0 [ 1475.805454] raid5_get_active_stripe+0x469/0x5f0 [raid456] [ 1475.813856] ? finish_wait+0x80/0x80 [ 1475.820332] raid5_make_request+0x180/0xb40 [raid456] [ 1475.828281] ? finish_wait+0x80/0x80 [ 1475.834727] ? finish_wait+0x80/0x80 [ 1475.841127] ? finish_wait+0x80/0x80 [ 1475.847480] md_handle_request+0x119/0x190 [ 1475.854390] md_make_request+0x8a/0x190 [ 1475.861041] generic_make_request+0xcf/0x310 [ 1475.868145] submit_bio+0x3c/0x160 [ 1475.874355] iomap_dio_submit_bio.isra.20+0x51/0x60 [ 1475.882070] iomap_dio_bio_actor+0x175/0x390 [ 1475.889149] iomap_apply+0xff/0x310 [ 1475.895447] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.902736] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.909974] iomap_dio_rw+0x2f2/0x490 [ 1475.916415] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.923680] ? atime_needs_update+0x77/0xe0 [ 1475.930674] ? xfs_file_dio_aio_read+0x6b/0xe0 [xfs] [ 1475.938455] xfs_file_dio_aio_read+0x6b/0xe0 [xfs] [ 1475.946084] xfs_file_read_iter+0xba/0xd0 [xfs] [ 1475.953403] aio_read+0xd5/0x180 [ 1475.959395] ? _cond_resched+0x15/0x30 [ 1475.965907] io_submit_one+0x20b/0x3c0 [ 1475.972398] __x64_sys_io_submit+0xa2/0x180 [ 1475.979335] ? do_io_getevents+0x7c/0xc0 [ 1475.986009] do_syscall_64+0x5b/0x1a0 [ 1475.992419] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 1476.000255] RIP: 0033:0x7f11fc27978d [ 1476.006631] Code: Bad RIP value. [ 1476.073251] INFO: task fio:3877 blocked for more than 120 seconds. Cc: stable@vger.kernel.org Fixes: fb73b357fb9 ("raid5: block failing device if raid will be failed") Reviewd-by: Xiao Ni Signed-off-by: Mariusz Tkaczyk Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/md/raid5.c | 47 ++++++++++++++++++++++------------------------- 1 file changed, 22 insertions(+), 25 deletions(-) --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -686,17 +686,17 @@ int raid5_calc_degraded(struct r5conf *c return degraded; } =20 -static int has_failed(struct r5conf *conf) +static bool has_failed(struct r5conf *conf) { - int degraded; + int degraded =3D conf->mddev->degraded; =20 - if (conf->mddev->reshape_position =3D=3D MaxSector) - return conf->mddev->degraded > conf->max_degraded; + if (test_bit(MD_BROKEN, &conf->mddev->flags)) + return true; =20 - degraded =3D raid5_calc_degraded(conf); - if (degraded > conf->max_degraded) - return 1; - return 0; + if (conf->mddev->reshape_position !=3D MaxSector) + degraded =3D raid5_calc_degraded(conf); + + return degraded > conf->max_degraded; } =20 struct stripe_head * @@ -2877,34 +2877,31 @@ static void raid5_error(struct mddev *md unsigned long flags; pr_debug("raid456: error called\n"); =20 + pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n", + mdname(mddev), bdevname(rdev->bdev, b)); + spin_lock_irqsave(&conf->device_lock, flags); + set_bit(Faulty, &rdev->flags); + clear_bit(In_sync, &rdev->flags); + mddev->degraded =3D raid5_calc_degraded(conf); =20 - if (test_bit(In_sync, &rdev->flags) && - mddev->degraded =3D=3D conf->max_degraded) { - /* - * Don't allow to achieve failed state - * Don't try to recover this device - */ + if (has_failed(conf)) { + set_bit(MD_BROKEN, &conf->mddev->flags); conf->recovery_disabled =3D mddev->recovery_disabled; - spin_unlock_irqrestore(&conf->device_lock, flags); - return; + + pr_crit("md/raid:%s: Cannot continue operation (%d/%d failed).\n", + mdname(mddev), mddev->degraded, conf->raid_disks); + } else { + pr_crit("md/raid:%s: Operation continuing on %d devices.\n", + mdname(mddev), conf->raid_disks - mddev->degraded); } =20 - set_bit(Faulty, &rdev->flags); - clear_bit(In_sync, &rdev->flags); - mddev->degraded =3D raid5_calc_degraded(conf); spin_unlock_irqrestore(&conf->device_lock, flags); set_bit(MD_RECOVERY_INTR, &mddev->recovery); =20 set_bit(Blocked, &rdev->flags); set_mask_bits(&mddev->sb_flags, 0, BIT(MD_SB_CHANGE_DEVS) | BIT(MD_SB_CHANGE_PENDING)); - pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n" - "md/raid:%s: Operation continuing on %d devices.\n", - mdname(mddev), - bdevname(rdev->bdev, b), - mdname(mddev), - conf->raid_disks - mddev->degraded); r5c_update_on_rdev_error(mddev, rdev); } From nobody Tue Apr 28 06:30:15 2026 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 70650CCA483 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347223AbiFCSFo (ORCPT ); Fri, 3 Jun 2022 14:05:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346397AbiFCRvI (ORCPT ); Fri, 3 Jun 2022 13:51: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 DD0FF54FB1; Fri, 3 Jun 2022 10:47:59 -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 A2E2DB823B0; Fri, 3 Jun 2022 17:47:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13F13C385A9; Fri, 3 Jun 2022 17:47:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278477; bh=y3BGFbSmlIT+4iN4zliES5xE1cfw7pDm2wu+KvDfUCk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=coxV+srzzOZcimK2rFpwtf1K6DcTA3AJAJ8al+NWQ/HUjB7FkbtFXH+/F2S16N4h6 siJcc+4nD8XQIWAHCJYWajGO9z9syDfjeS1+rsAH94S0KP9W2xxD1B/lbnJI4DX1PO x86zIYRk+tiRY8mQH8hiGCDcI/28ZXUHWTSQsYoc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marek Maslanka , Benjamin Tissoires , Jiri Kosina Subject: [PATCH 5.10 45/53] HID: multitouch: Add support for Google Whiskers Touchpad Date: Fri, 3 Jun 2022 19:43:30 +0200 Message-Id: <20220603173820.029926088@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Marek Ma=C5=9Blanka commit 1d07cef7fd7599450b3d03e1915efc2a96e1f03f upstream. The Google Whiskers touchpad does not work properly with the default multitouch configuration. Instead, use the same configuration as Google Rose. Signed-off-by: Marek Maslanka Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/hid/hid-multitouch.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -2129,6 +2129,9 @@ static const struct hid_device_id mt_dev { .driver_data =3D MT_CLS_GOOGLE, HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_TOUCH_ROSE) }, + { .driver_data =3D MT_CLS_GOOGLE, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_GOOGLE, + USB_DEVICE_ID_GOOGLE_WHISKERS) }, =20 /* Generic MT device */ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) }, From nobody Tue Apr 28 06:30:15 2026 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 5F91FCCA484 for ; Fri, 3 Jun 2022 18:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347167AbiFCSFl (ORCPT ); Fri, 3 Jun 2022 14:05:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346411AbiFCRvJ (ORCPT ); Fri, 3 Jun 2022 13:51: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 E286B56C02; Fri, 3 Jun 2022 10:48: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 A6037B82419; Fri, 3 Jun 2022 17:48:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 030B8C385A9; Fri, 3 Jun 2022 17:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278480; bh=ZIcsYjUnDHt/ILT8b0MIPsTKDV+xT9yctyXLcf5DodE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZBCZYn6ePKNJV7xphVwby3jrQ25BoDRVaonMZft4pqCbFJd2HsaIm8mS5Z03ZasGm gSjm0G4qrfDUnQzVio4HV7baKLoD44SwjnB/fhnCgqoV8lI23r2CRJrGFfwiAHAems owaoJxvqLiMEBnWhcSRGs8o7DWXR0QP6eFCWdXRM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tao Jin , Benjamin Tissoires Subject: [PATCH 5.10 46/53] HID: multitouch: add quirks to enable Lenovo X12 trackpoint Date: Fri, 3 Jun 2022 19:43:31 +0200 Message-Id: <20220603173820.057457416@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Tao Jin commit 95cd2cdc88c755dcd0a58b951faeb77742c733a4 upstream. This applies the similar quirks used by previous generation devices such as X1 tablet for X12 tablet, so that the trackpoint and buttons can work. This patch was applied and tested working on 5.17.1 . Cc: stable@vger.kernel.org # 5.8+ given that it relies on 40d5bb87377a Signed-off-by: Tao Jin Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/CO6PR03MB6241CB276FCDC7F4CEDC34F6E1E29@CO6P= R03MB6241.namprd03.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-multitouch.c | 6 ++++++ 2 files changed, 7 insertions(+) --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -743,6 +743,7 @@ #define USB_DEVICE_ID_LENOVO_X1_COVER 0x6085 #define USB_DEVICE_ID_LENOVO_X1_TAB 0x60a3 #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5 +#define USB_DEVICE_ID_LENOVO_X12_TAB 0x60fe #define USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E 0x600e #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -1990,6 +1990,12 @@ static const struct hid_device_id mt_dev USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB3) }, =20 + /* Lenovo X12 TAB Gen 1 */ + { .driver_data =3D MT_CLS_WIN_8_FORCE_MULTI_INPUT, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, + USB_VENDOR_ID_LENOVO, + USB_DEVICE_ID_LENOVO_X12_TAB) }, + /* MosArt panels */ { .driver_data =3D MT_CLS_CONFIDENCE_MINUS_ONE, MT_USB_DEVICE(USB_VENDOR_ID_ASUS, From nobody Tue Apr 28 06:30:15 2026 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 BB64EC43334 for ; Fri, 3 Jun 2022 17:56:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345808AbiFCR4f (ORCPT ); Fri, 3 Jun 2022 13:56:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346421AbiFCRvJ (ORCPT ); Fri, 3 Jun 2022 13:51: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 53EA756C0C; Fri, 3 Jun 2022 10:48: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 CF207604EF; Fri, 3 Jun 2022 17:48:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E164AC385A9; Fri, 3 Jun 2022 17:48:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278483; bh=yyrGhqI8IVeC53hKFu4TYqVuzOZWCA2X3vdF+q2ZsDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qVkEoYM32u4COSJsWOqgCcDmGSVc+acP1tB7ZWFKerYd8EHcPZcmEuXpEBnTC2ZWs zzWCE7HTcvewZPIER4f5WZDnogLHUj5fKP3E8KpL7MV9/R+czFuGDC/wxznwca7v8n LhRCZtG2AULRpg2V/Vo/Qr5FymfJ2OgS+SW8FoDw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stefan Mahnke-Hartmann , Jarkko Sakkinen Subject: [PATCH 5.10 47/53] tpm: Fix buffer access in tpm2_get_tpm_pt() Date: Fri, 3 Jun 2022 19:43:32 +0200 Message-Id: <20220603173820.087135017@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Stefan Mahnke-Hartmann commit e57b2523bd37e6434f4e64c7a685e3715ad21e9a upstream. Under certain conditions uninitialized memory will be accessed. As described by TCG Trusted Platform Module Library Specification, rev. 1.59 (Part 3: Commands), if a TPM2_GetCapability is received, requesting a capability, the TPM in field upgrade mode may return a zero length list. Check the property count in tpm2_get_tpm_pt(). Fixes: 2ab3241161b3 ("tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf") Cc: stable@vger.kernel.org Signed-off-by: Stefan Mahnke-Hartmann Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/char/tpm/tpm2-cmd.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -400,7 +400,16 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip if (!rc) { out =3D (struct tpm2_get_cap_out *) &buf.data[TPM_HEADER_SIZE]; - *value =3D be32_to_cpu(out->value); + /* + * To prevent failing boot up of some systems, Infineon TPM2.0 + * returns SUCCESS on TPM2_Startup in field upgrade mode. Also + * the TPM2_Getcapability command returns a zero length list + * in field upgrade mode. + */ + if (be32_to_cpu(out->property_cnt) > 0) + *value =3D be32_to_cpu(out->value); + else + rc =3D -ENODATA; } tpm_buf_destroy(&buf); return rc; From nobody Tue Apr 28 06:30:15 2026 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 8B22FC433EF for ; Fri, 3 Jun 2022 17:56:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345838AbiFCR4i (ORCPT ); Fri, 3 Jun 2022 13:56:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346431AbiFCRvK (ORCPT ); Fri, 3 Jun 2022 13:51:10 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2F8B53A73; Fri, 3 Jun 2022 10:48: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 dfw.source.kernel.org (Postfix) with ESMTPS id 6502B60EE9; Fri, 3 Jun 2022 17:48:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B597C385B8; Fri, 3 Jun 2022 17:48:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278489; bh=t2iku9VsGb3Gnb7+FcVhBaBUkyqnTKlCN7xRRtn7nVw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=caxM0skyVyLeF56lD7qbX6u/BhwDbRITveH0BKuDGcl+qAQYqC85XB7pKHIwE+t4z gPV5NDoEfkqNH7WhlgIOX5Jyzts1sd2adM/Nd3Dicl2b4iVtY+vWciVzaJBUk3IENt O++K7KjgGSS4zzFvk0uV9hgO9JhdTU1USfxC8Sdg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiu Jianfeng , Stefan Berger , Jarkko Sakkinen Subject: [PATCH 5.10 48/53] tpm: ibmvtpm: Correct the return value in tpm_ibmvtpm_probe() Date: Fri, 3 Jun 2022 19:43:33 +0200 Message-Id: <20220603173820.116053243@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Xiu Jianfeng commit d0dc1a7100f19121f6e7450f9cdda11926aa3838 upstream. Currently it returns zero when CRQ response timed out, it should return an error code instead. Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before procee= ding") Signed-off-by: Xiu Jianfeng Reviewed-by: Stefan Berger Acked-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- drivers/char/tpm/tpm_ibmvtpm.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/char/tpm/tpm_ibmvtpm.c +++ b/drivers/char/tpm/tpm_ibmvtpm.c @@ -683,6 +683,7 @@ static int tpm_ibmvtpm_probe(struct vio_ if (!wait_event_timeout(ibmvtpm->crq_queue.wq, ibmvtpm->rtce_buf !=3D NULL, HZ)) { + rc =3D -ENODEV; dev_err(dev, "CRQ response timed out\n"); goto init_irq_cleanup; } From nobody Tue Apr 28 06:30:15 2026 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 71EC0C43334 for ; Fri, 3 Jun 2022 17:56:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345624AbiFCR4s (ORCPT ); Fri, 3 Jun 2022 13:56:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346439AbiFCRvK (ORCPT ); Fri, 3 Jun 2022 13:51:10 -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 74C6453B40; Fri, 3 Jun 2022 10:48: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 33734B82189; Fri, 3 Jun 2022 17:48:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 859CBC385A9; Fri, 3 Jun 2022 17:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278493; bh=gL/j46Vo0RPyW+VAjcvOzLGMRh1Gj7E6e1zfGX6QSB8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IbYDt15DTYyuEFGihhxP3/gilgoZeHizO2YfCgWtg9Z5YjdwmyUhenp6ZcNBWmzSY KuFET/JkTwVXMRH6CyHKDfAMJS0mFHTKdAT0ifhbEtfJdrQVxsmXIIiCPCI1uK19oF 4SkrPAgE1Mpvl/Ox7GJEOom49eYdeP9gHPdJJzLk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Akira Yokosawa , Jonathan Corbet , Mauro Carvalho Chehab Subject: [PATCH 5.10 49/53] docs: submitting-patches: Fix crossref to The canonical patch format Date: Fri, 3 Jun 2022 19:43:34 +0200 Message-Id: <20220603173820.143736210@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Akira Yokosawa commit 6d5aa418b3bd42cdccc36e94ee199af423ef7c84 upstream. The reference to `explicit_in_reply_to` is pointless as when the reference was added in the form of "#15" [1], Section 15) was "The canonical patch format". The reference of "#15" had not been properly updated in a couple of reorganizations during the plain-text SubmittingPatches era. Fix it by using `the_canonical_patch_format`. [1]: 2ae19acaa50a ("Documentation: Add "how to write a good patch summary" = to SubmittingPatches") Signed-off-by: Akira Yokosawa Fixes: 5903019b2a5e ("Documentation/SubmittingPatches: convert it to ReST m= arkup") Fixes: 9b2c76777acc ("Documentation/SubmittingPatches: enrich the Sphinx ou= tput") Cc: Jonathan Corbet Cc: Mauro Carvalho Chehab Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.= com Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- Documentation/process/submitting-patches.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -71,7 +71,7 @@ as you intend it to. =20 The maintainer will thank you if you write your patch description in a form which can be easily pulled into Linux's source code management -system, ``git``, as a "commit log". See :ref:`explicit_in_reply_to`. +system, ``git``, as a "commit log". See :ref:`the_canonical_patch_format`. =20 Solve only one problem per patch. If your description starts to get long, that's a sign that you probably need to split up your patch. From nobody Tue Apr 28 06:30:15 2026 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 A3A7CCCA48C for ; Fri, 3 Jun 2022 18:07:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347090AbiFCSFi (ORCPT ); Fri, 3 Jun 2022 14:05:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346442AbiFCRvK (ORCPT ); Fri, 3 Jun 2022 13:51:10 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F010C54012; Fri, 3 Jun 2022 10:48: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 8D46C60EE9; Fri, 3 Jun 2022 17:48:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86BBCC385A9; Fri, 3 Jun 2022 17:48:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278496; bh=KO1ohSc23MpU4JrZTJenIlK69t/iwj/E9M6ULzZ72sA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Axym0vvp4GwdVKjDoAC16aW1tr3knGvpsDkCRMU1VgKI70DlQENqay8AYmCrf5xMm U9nI2BxST+gtjmFauxvDauuJUZx5xaOXMVm/JM9fcRdjGdgr8YUXIQNmZqbKDzkGI6 M4kvzmIEQsh5h2C5IwcXfAIn3PD140hXiB5tU3DI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Olga Kornievskaia , Trond Myklebust , Anna Schumaker Subject: [PATCH 5.10 50/53] NFS: Memory allocation failures are not server fatal errors Date: Fri, 3 Jun 2022 19:43:35 +0200 Message-Id: <20220603173820.173496769@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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 commit 452284407c18d8a522c3039339b1860afa0025a8 upstream. We need to filter out ENOMEM in nfs_error_is_fatal_on_server(), because running out of memory on our client is not a server error. Reported-by: Olga Kornievskaia Fixes: 2dc23afffbca ("NFS: ENOMEM should also be a fatal error.") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/nfs/internal.h | 1 + 1 file changed, 1 insertion(+) --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -832,6 +832,7 @@ static inline bool nfs_error_is_fatal_on case 0: case -ERESTARTSYS: case -EINTR: + case -ENOMEM: return false; } return nfs_error_is_fatal(err); From nobody Tue Apr 28 06:30:15 2026 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 B92EAC433EF for ; Fri, 3 Jun 2022 17:57:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345839AbiFCR45 (ORCPT ); Fri, 3 Jun 2022 13:56:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346456AbiFCRvL (ORCPT ); Fri, 3 Jun 2022 13:51:11 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0818156C3D; Fri, 3 Jun 2022 10:48: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 dfw.source.kernel.org (Postfix) with ESMTPS id 98E4F60F3E; Fri, 3 Jun 2022 17:48:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90F4FC385A9; Fri, 3 Jun 2022 17:48:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278499; bh=21SXVznNk8nrAqUXqJHMAyEw3zH9dw0VNUvKpqJuS0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IxvBQdyO44ggWoIUq8pxz1ZtkctGuZzIDxvR2OhiYe2BmrcuJ6mK38WwtGkpMTyuQ WlFWjYTXafdkcNQ9tytyrsXMNCLjUzFrKluARpzR5JnK4EAkk3GFbfDrj2qvUmsYRw dPaCJP08mJCZ48niOixu03X5UfB7fNZJ+/TaxaQw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dai Ngo , Chuck Lever Subject: [PATCH 5.10 51/53] NFSD: Fix possible sleep during nfsd4_release_lockowner() Date: Fri, 3 Jun 2022 19:43:36 +0200 Message-Id: <20220603173820.202073618@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Chuck Lever commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b upstream. nfsd4_release_lockowner() holds clp->cl_lock when it calls check_for_locks(). However, check_for_locks() calls nfsd_file_get() / nfsd_file_put() to access the backing inode's flc_posix list, and nfsd_file_put() can sleep if the inode was recently removed. Let's instead rely on the stateowner's reference count to gate whether the release is permitted. This should be a reliable indication of locks-in-use since file lock operations and ->lm_get_owner take appropriate references, which are released appropriately when file locks are removed. Reported-by: Dai Ngo Signed-off-by: Chuck Lever Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- fs/nfsd/nfs4state.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -7122,16 +7122,12 @@ nfsd4_release_lockowner(struct svc_rqst if (sop->so_is_open_owner || !same_owner_str(sop, owner)) continue; =20 - /* see if there are still any locks associated with it */ - lo =3D lockowner(sop); - list_for_each_entry(stp, &sop->so_stateids, st_perstateowner) { - if (check_for_locks(stp->st_stid.sc_file, lo)) { - status =3D nfserr_locks_held; - spin_unlock(&clp->cl_lock); - return status; - } + if (atomic_read(&sop->so_count) !=3D 1) { + spin_unlock(&clp->cl_lock); + return nfserr_locks_held; } =20 + lo =3D lockowner(sop); nfs4_get_stateowner(sop); break; } From nobody Tue Apr 28 06:30:15 2026 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 BAC9FCCA47C for ; Fri, 3 Jun 2022 17:57:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244576AbiFCR5D (ORCPT ); Fri, 3 Jun 2022 13:57:03 -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 S1346481AbiFCRvN (ORCPT ); Fri, 3 Jun 2022 13:51:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D051454FB7; Fri, 3 Jun 2022 10:48: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 773D9B82189; Fri, 3 Jun 2022 17:48:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA2BFC3411C; Fri, 3 Jun 2022 17:48:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278502; bh=dqFrCjkKesUQuBXwMi30MVJWQe5C7sFAW1S0r0P/XyE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RpfZ1dWCbJ8E0e6MA3nqzkRpLM3Afr4n3JHJt89rPw3YBn/umaQe2MrmayzGunhRw UtvdvUYIRh7nl9x+zJdgsVYsK3+kXP3Eh+AJ/mVqHWbYEI/BQ1H3BJPRqc0qeuLmGI /ganWLEOKYc3HvUgc4wz2+iyy/Txtf2vHRVGE8Uw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yuntao Wang , Alexei Starovoitov Subject: [PATCH 5.10 52/53] bpf: Fix potential array overflow in bpf_trampoline_get_progs() Date: Fri, 3 Jun 2022 19:43:37 +0200 Message-Id: <20220603173820.230531699@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Yuntao Wang commit a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d upstream. The cnt value in the 'cnt >=3D BPF_MAX_TRAMP_PROGS' check does not include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline can exceed BPF_MAX_TRAMP_PROGS. When this happens, the assignment '*progs++ =3D aux->prog' in bpf_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold at most BPF_MAX_TRAMP_PROGS bpf programs. Fixes: 88fd9e5352fe ("bpf: Refactor trampoline update code") Signed-off-by: Yuntao Wang Link: https://lore.kernel.org/r/20220430130803.210624-1-ytcoode@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- kernel/bpf/trampoline.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c @@ -378,7 +378,7 @@ int bpf_trampoline_link_prog(struct bpf_ { enum bpf_tramp_prog_type kind; int err =3D 0; - int cnt; + int cnt =3D 0, i; =20 kind =3D bpf_attach_type_to_tramp(prog); mutex_lock(&tr->mutex); @@ -389,7 +389,10 @@ int bpf_trampoline_link_prog(struct bpf_ err =3D -EBUSY; goto out; } - cnt =3D tr->progs_cnt[BPF_TRAMP_FENTRY] + tr->progs_cnt[BPF_TRAMP_FEXIT]; + + for (i =3D 0; i < BPF_TRAMP_MAX; i++) + cnt +=3D tr->progs_cnt[i]; + if (kind =3D=3D BPF_TRAMP_REPLACE) { /* Cannot attach extension if fentry/fexit are in use. */ if (cnt) { @@ -467,16 +470,19 @@ out: =20 void bpf_trampoline_put(struct bpf_trampoline *tr) { + int i; + if (!tr) return; mutex_lock(&trampoline_mutex); if (!refcount_dec_and_test(&tr->refcnt)) goto out; WARN_ON_ONCE(mutex_is_locked(&tr->mutex)); - if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[BPF_TRAMP_FENTRY]))) - goto out; - if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[BPF_TRAMP_FEXIT]))) - goto out; + + for (i =3D 0; i < BPF_TRAMP_MAX; i++) + if (WARN_ON_ONCE(!hlist_empty(&tr->progs_hlist[i]))) + goto out; + /* This code will be executed even when the last bpf_tramp_image * is alive. All progs are detached from the trampoline and the * trampoline image is patched with jmp into epilogue to skip From nobody Tue Apr 28 06:30:15 2026 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 57D51C433EF for ; Fri, 3 Jun 2022 17:57:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345904AbiFCR5J (ORCPT ); Fri, 3 Jun 2022 13:57:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346493AbiFCRvN (ORCPT ); Fri, 3 Jun 2022 13:51:13 -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 7DDDA5401D; Fri, 3 Jun 2022 10:48: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 BB3EC604EF; Fri, 3 Jun 2022 17:48:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBE43C385B8; Fri, 3 Jun 2022 17:48:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654278505; bh=kN0AN2TNyRTIymjPqzTViSmge+OvDBcFe42A1QKtWv8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h259kxfL0y/1tng/akEao4zN33LBygStLc/I0vkMq34DkpcJ9PRV2nfyNxBw1tRG5 cTpwX0Rj9wO6+p/Nb+LWRuC04RjUdF1HN/RZ5gYyQZY+5ipr9eX82Tao9o4nqC6s+2 HCADGxmm07eFFb+NZPvUnEk4jaVvjsZDd+tkR8x4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Liu Jian , Daniel Borkmann , Song Liu Subject: [PATCH 5.10 53/53] bpf: Enlarge offset check value to INT_MAX in bpf_skb_{load,store}_bytes Date: Fri, 3 Jun 2022 19:43:38 +0200 Message-Id: <20220603173820.259753943@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173818.716010877@linuxfoundation.org> References: <20220603173818.716010877@linuxfoundation.org> User-Agent: quilt/0.66 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: Liu Jian commit 45969b4152c1752089351cd6836a42a566d49bcf upstream. The data length of skb frags + frag_list may be greater than 0xffff, and skb_header_pointer can not handle negative offset. So, here INT_MAX is used to check the validity of offset. Add the same change to the related function skb_store_bytes. Fixes: 05c74e5e53f6 ("bpf: add bpf_skb_load_bytes helper") Signed-off-by: Liu Jian Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20220416105801.88708-2-liujian56@huawei.c= om Signed-off-by: Greg Kroah-Hartman Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee --- net/core/filter.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/core/filter.c +++ b/net/core/filter.c @@ -1687,7 +1687,7 @@ BPF_CALL_5(bpf_skb_store_bytes, struct s =20 if (unlikely(flags & ~(BPF_F_RECOMPUTE_CSUM | BPF_F_INVALIDATE_HASH))) return -EINVAL; - if (unlikely(offset > 0xffff)) + if (unlikely(offset > INT_MAX)) return -EFAULT; if (unlikely(bpf_try_make_writable(skb, offset + len))) return -EFAULT; @@ -1722,7 +1722,7 @@ BPF_CALL_4(bpf_skb_load_bytes, const str { void *ptr; =20 - if (unlikely(offset > 0xffff)) + if (unlikely(offset > INT_MAX)) goto err_clear; =20 ptr =3D skb_header_pointer(skb, offset, len, to);