From nobody Tue Jun 30 03:34:06 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 21A69C43219 for ; Mon, 31 Jan 2022 11:04:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359117AbiAaLEX (ORCPT ); Mon, 31 Jan 2022 06:04:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359152AbiAaLDB (ORCPT ); Mon, 31 Jan 2022 06:03:01 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 678B2C0612FC; Mon, 31 Jan 2022 03:01:35 -0800 (PST) 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 2CCDEB82A5E; Mon, 31 Jan 2022 11:01:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45954C340E8; Mon, 31 Jan 2022 11:01:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626892; bh=xLeK2P+nBHoZ3TW+XG9S74ef1zCqYwfGpC4fgjP9Lmk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dqKRx4nO43K4aK3IFjsgJrMgpI0lrXCeYXhYdZ3o1knDclabwHJGeyDEAbHOY0xu7 uHp/5t3QfkMqspEQXmY9KQ+IOzD5r1f3+bxLvfQ/f9eEFKJP59JByodE/WCXvUTYMI 6oV74FuaRmK1Nr1KohwEDcejPddfqRdl8lhDB8AA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Gix , Marcel Holtmann , syphyr Subject: [PATCH 5.10 001/100] Bluetooth: refactor malicious adv data check Date: Mon, 31 Jan 2022 11:55:22 +0100 Message-Id: <20220131105220.474074744@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Brian Gix commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream. Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced. Signed-off-by: Brian Gix Signed-off-by: Marcel Holtmann Cc: syphyr Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/bluetooth/hci_event.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -5661,6 +5661,11 @@ static void hci_le_adv_report_evt(struct struct hci_ev_le_advertising_info *ev =3D ptr; s8 rssi; =20 + if (ptr > (void *)skb_tail_pointer(skb) - sizeof(*ev)) { + bt_dev_err(hdev, "Malicious advertising data."); + break; + } + if (ev->length <=3D HCI_MAX_AD_LENGTH && ev->data + ev->length <=3D skb_tail_pointer(skb)) { rssi =3D ev->data[ev->length]; @@ -5672,11 +5677,6 @@ static void hci_le_adv_report_evt(struct } =20 ptr +=3D sizeof(*ev) + ev->length + 1; - - if (ptr > (void *) skb_tail_pointer(skb) - sizeof(*ev)) { - bt_dev_err(hdev, "Malicious advertising data. Stopping processing"); - break; - } } =20 hci_dev_unlock(hdev); From nobody Tue Jun 30 03:34:06 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 DD582C43219 for ; Mon, 31 Jan 2022 11:03:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358445AbiAaLDo (ORCPT ); Mon, 31 Jan 2022 06:03:44 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:50160 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358918AbiAaLCK (ORCPT ); Mon, 31 Jan 2022 06:02:10 -0500 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 0439BB82A63; Mon, 31 Jan 2022 11:02:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18676C340E8; Mon, 31 Jan 2022 11:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626927; bh=roTSABubN/Wi/NZrtktszAYxy/Lk9Du0dr9/MHsZBl4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eYFrd1U3FFANIpgpYn81v8KfRWbfa4LDTav8UjwzL83JVbvM8yZr7okldw7HXaPy1 XMu8XKT+Vb74LI0c0mepfZ+X/FLlsRl9bjDlzIb+7L5+6o86f+GD4qndpcqVu8Sgfy VueXcp4bR+K3I5UxBlvNoHKbbMtn9nnzabbr0Gqc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stanimir Varbanov , Mauro Carvalho Chehab , Martin Faltesek , Guenter Roeck , Bryan ODonoghue Subject: [PATCH 5.10 002/100] media: venus: core: Drop second v4l2 device unregister Date: Mon, 31 Jan 2022 11:55:23 +0100 Message-Id: <20220131105220.504209945@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Stanimir Varbanov commit ddbcd0c58a6a53e2f1600b9de0ce6a20667c031c upstream. Wrong solution of rebase conflict leads to calling twice v4l2_device_unregister in .venus_remove. Delete the second one. Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Cc: Martin Faltesek Cc: Guenter Roeck Cc: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/media/platform/qcom/venus/core.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -375,8 +375,6 @@ static int venus_remove(struct platform_ =20 hfi_destroy(core); =20 - v4l2_device_unregister(&core->v4l2_dev); - mutex_destroy(&core->pm_lock); mutex_destroy(&core->lock); venus_dbgfs_deinit(core); From nobody Tue Jun 30 03:34:06 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 06686C433EF for ; Mon, 31 Jan 2022 11:04:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359030AbiAaLEQ (ORCPT ); Mon, 31 Jan 2022 06:04:16 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:36724 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358992AbiAaLCn (ORCPT ); Mon, 31 Jan 2022 06:02:43 -0500 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 29ACC60B2D; Mon, 31 Jan 2022 11:02:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6DCFC340E8; Mon, 31 Jan 2022 11:02:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626962; bh=JUVBrBiQ+LbRUjdcdSOfk0Z0e9ZPxcAKalrhuiQXluk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0nd4H/qeCjmO2V9ymEgR+cVtl3XWNqWc8fwzh7+IT+K8kvCDSEWSmAEurZhDbe1dq WqUrtho7Ixo+pda1q2wdE136lUZ54MGu72vugaqWfw8lzn4unQeJLNzDsEfSET5lLA cyMNtU/maICuRBAAmOQmBGCdEQDOYnpltwIi+fxs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Marek=20Beh=C3=BAn?= , "David S. Miller" Subject: [PATCH 5.10 003/100] net: sfp: ignore disabled SFP node Date: Mon, 31 Jan 2022 11:55:24 +0100 Message-Id: <20220131105220.543846905@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 Beh=C3=BAn commit 2148927e6ed43a1667baf7c2ae3e0e05a44b51a0 upstream. Commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") added code which finds SFP bus DT node even if the node is disabled with status =3D "disabled". Because of this, when phylink is created, it ends with non-null .sfp_bus member, even though the SFP module is not probed (because the node is disabled). We need to ignore disabled SFP bus node. Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices an= d sfp cages") Signed-off-by: Marek Beh=C3=BAn Cc: stable@vger.kernel.org # 2203cbf2c8b5 ("net: sfp: move fwnode parsing i= nto sfp-bus layer") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/phy/sfp-bus.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/phy/sfp-bus.c +++ b/drivers/net/phy/sfp-bus.c @@ -609,6 +609,11 @@ struct sfp_bus *sfp_bus_find_fwnode(stru else if (ret < 0) return ERR_PTR(ret); =20 + if (!fwnode_device_is_available(ref.fwnode)) { + fwnode_handle_put(ref.fwnode); + return NULL; + } + bus =3D sfp_bus_get(ref.fwnode); fwnode_handle_put(ref.fwnode); if (!bus) From nobody Tue Jun 30 03:34:06 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 E6DD1C433FE for ; Mon, 31 Jan 2022 11:04:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358713AbiAaLE6 (ORCPT ); Mon, 31 Jan 2022 06:04:58 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51100 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359098AbiAaLC5 (ORCPT ); Mon, 31 Jan 2022 06:02:57 -0500 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 9BF39B82A57; Mon, 31 Jan 2022 11:02:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0968C340EF; Mon, 31 Jan 2022 11:02:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626975; bh=7BpYgPwu1UsHm+ODdEAtD9Qh4ktMDhSuWtddKky/638=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=no9CZfXCBw2DV7/GXje1ss3geJTUUu9joFx17Fa2cE0pMjAB13EjhVeNmKrubRqfu QxleRpZbojowtLjXhylR/NzK7mYpNG995JUf5nYwYEIcNlg92Xza8Zekxl0D8FUd7J GQF6nG1pqRlDgPfoUFmISCyhTnleP4jRkqzFiMe8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mohammad Athari Bin Ismail , "David S. Miller" Subject: [PATCH 5.10 004/100] net: stmmac: skip only stmmac_ptp_register when resume from suspend Date: Mon, 31 Jan 2022 11:55:25 +0100 Message-Id: <20220131105220.583649704@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Mohammad Athari Bin Ismail commit 0735e639f129dff455aeb91da291f5c578cc33db upstream. When resume from suspend, besides skipping PTP registration, it also skipping PTP HW initialization. This could cause PTP clock not able to operate properly when resume from suspend. To fix this, only stmmac_ptp_register() is skipped when resume from suspend. Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend= /hibernation") Cc: # 5.15.x Signed-off-by: Mohammad Athari Bin Ismail Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 +++++++++--------= --- 1 file changed, 9 insertions(+), 11 deletions(-) --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -816,8 +816,6 @@ static int stmmac_init_ptp(struct stmmac priv->hwts_tx_en =3D 0; priv->hwts_rx_en =3D 0; =20 - stmmac_ptp_register(priv); - return 0; } =20 @@ -2691,7 +2689,7 @@ static void stmmac_safety_feat_configura /** * stmmac_hw_setup - setup mac in a usable state. * @dev : pointer to the device structure. - * @init_ptp: initialize PTP if set + * @ptp_register: register PTP if set * Description: * this is the main function to setup the HW in a usable state because the * dma engine is reset, the core registers are configured (e.g. AXI, @@ -2701,7 +2699,7 @@ static void stmmac_safety_feat_configura * 0 on success and an appropriate (-)ve integer as defined in errno.h * file on failure. */ -static int stmmac_hw_setup(struct net_device *dev, bool init_ptp) +static int stmmac_hw_setup(struct net_device *dev, bool ptp_register) { struct stmmac_priv *priv =3D netdev_priv(dev); u32 rx_cnt =3D priv->plat->rx_queues_to_use; @@ -2757,13 +2755,13 @@ static int stmmac_hw_setup(struct net_de =20 stmmac_mmc_setup(priv); =20 - if (init_ptp) { - ret =3D stmmac_init_ptp(priv); - if (ret =3D=3D -EOPNOTSUPP) - netdev_warn(priv->dev, "PTP not supported by HW\n"); - else if (ret) - netdev_warn(priv->dev, "PTP init failed\n"); - } + ret =3D stmmac_init_ptp(priv); + if (ret =3D=3D -EOPNOTSUPP) + netdev_warn(priv->dev, "PTP not supported by HW\n"); + else if (ret) + netdev_warn(priv->dev, "PTP init failed\n"); + else if (ptp_register) + stmmac_ptp_register(priv); =20 priv->eee_tw_timer =3D STMMAC_DEFAULT_TWT_LS; =20 From nobody Tue Jun 30 03:34:06 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 E602CC433EF for ; Mon, 31 Jan 2022 11:06:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359644AbiAaLGW (ORCPT ); Mon, 31 Jan 2022 06:06:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348548AbiAaLDm (ORCPT ); Mon, 31 Jan 2022 06:03:42 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7540C06173B; Mon, 31 Jan 2022 03:03:00 -0800 (PST) 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 AEA6FB82A5C; Mon, 31 Jan 2022 11:02:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4936C340E8; Mon, 31 Jan 2022 11:02:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626978; bh=GFs5AD3kbV7jUjxKWt3YsXYhtRdrhv5dMPqDW+UM2eI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VIVsvyAYzt30wW2nXZ+B+gd8aXozuVDtMlFErRYfEFhtbMOuNpRVcw099rkYbxcZR M27SoFOgqeGn9dihbbxswDl323F+W0HcvNhbbi8pJBWZiMyOekFjQYKWbVN3ELewES ZyTaB08LDKpBHxwW2qvh7oP5+lxjFOoBeLRnJk5g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrea Righi , Ilya Leoshkevich , Heiko Carstens , Vasily Gorbik , Christian Borntraeger Subject: [PATCH 5.10 005/100] s390/module: fix loading modules with a lot of relocations Date: Mon, 31 Jan 2022 11:55:26 +0100 Message-Id: <20220131105220.617304665@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Ilya Leoshkevich commit f3b7e73b2c6619884351a3a0a7468642f852b8a2 upstream. If the size of the PLT entries generated by apply_rela() exceeds 64KiB, the first ones can no longer reach __jump_r1 with brc. Fix by using brcl. An alternative solution is to add a __jump_r1 copy after every 64KiB, however, the space savings are quite small and do not justify the additional complexity. Fixes: f19fbd5ed642 ("s390: introduce execute-trampolines for branches") Cc: stable@vger.kernel.org Reported-by: Andrea Righi Signed-off-by: Ilya Leoshkevich Reviewed-by: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/kernel/module.c | 37 ++++++++++++++++++------------------- 1 file changed, 18 insertions(+), 19 deletions(-) --- a/arch/s390/kernel/module.c +++ b/arch/s390/kernel/module.c @@ -30,7 +30,7 @@ #define DEBUGP(fmt , ...) #endif =20 -#define PLT_ENTRY_SIZE 20 +#define PLT_ENTRY_SIZE 22 =20 void *module_alloc(unsigned long size) { @@ -330,27 +330,26 @@ static int apply_rela(Elf_Rela *rela, El case R_390_PLTOFF32: /* 32 bit offset from GOT to PLT. */ case R_390_PLTOFF64: /* 16 bit offset from GOT to PLT. */ if (info->plt_initialized =3D=3D 0) { - unsigned int insn[5]; - unsigned int *ip =3D me->core_layout.base + - me->arch.plt_offset + - info->plt_offset; - - insn[0] =3D 0x0d10e310; /* basr 1,0 */ - insn[1] =3D 0x100a0004; /* lg 1,10(1) */ + unsigned char insn[PLT_ENTRY_SIZE]; + char *plt_base; + char *ip; + + plt_base =3D me->core_layout.base + me->arch.plt_offset; + ip =3D plt_base + info->plt_offset; + *(int *)insn =3D 0x0d10e310; /* basr 1,0 */ + *(int *)&insn[4] =3D 0x100c0004; /* lg 1,12(1) */ if (IS_ENABLED(CONFIG_EXPOLINE) && !nospec_disable) { - unsigned int *ij; - ij =3D me->core_layout.base + - me->arch.plt_offset + - me->arch.plt_size - PLT_ENTRY_SIZE; - insn[2] =3D 0xa7f40000 + /* j __jump_r1 */ - (unsigned int)(u16) - (((unsigned long) ij - 8 - - (unsigned long) ip) / 2); + char *jump_r1; + + jump_r1 =3D plt_base + me->arch.plt_size - + PLT_ENTRY_SIZE; + /* brcl 0xf,__jump_r1 */ + *(short *)&insn[8] =3D 0xc0f4; + *(int *)&insn[10] =3D (jump_r1 - (ip + 8)) / 2; } else { - insn[2] =3D 0x07f10000; /* br %r1 */ + *(int *)&insn[8] =3D 0x07f10000; /* br %r1 */ } - insn[3] =3D (unsigned int) (val >> 32); - insn[4] =3D (unsigned int) val; + *(long *)&insn[14] =3D val; =20 write(ip, insn, sizeof(insn)); info->plt_initialized =3D 1; From nobody Tue Jun 30 03:34:06 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 22D6EC433F5 for ; Mon, 31 Jan 2022 11:06:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359665AbiAaLG2 (ORCPT ); Mon, 31 Jan 2022 06:06:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348709AbiAaLDn (ORCPT ); Mon, 31 Jan 2022 06:03:43 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AA5DC06173D; Mon, 31 Jan 2022 03:03:02 -0800 (PST) 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 1A47A60AE3; Mon, 31 Jan 2022 11:03:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE9ADC340E8; Mon, 31 Jan 2022 11:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626981; bh=kvmeKDKq4ruE2gAqLGR7+eCTMNUXOvT8e/qFwT9YNBE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LnJE4lAdPX4O+iMt/jVVme2MFOaDVNMU7nVaza3zlj3GrWPymu9nZ+YAawqmNcMEu x4ovotd8qL4jvqCf6KSodVimdPHWs1k6EVc0qIYzVsCPmBcV7FKJ8RlSbrNXDJlw0+ EFVBCgShCEZEr/GscXEp7pNowe4Gb4y8FZvy195w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Gerald Schaefer , Vasily Gorbik Subject: [PATCH 5.10 006/100] s390/hypfs: include z/VM guests with access control group set Date: Mon, 31 Jan 2022 11:55:27 +0100 Message-Id: <20220131105220.651044036@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Vasily Gorbik commit 663d34c8df98740f1e90241e78e456d00b3c6cad upstream. Currently if z/VM guest is allowed to retrieve hypervisor performance data globally for all guests (privilege class B) the query is formed in a way to include all guests but the group name is left empty. This leads to that z/VM guests which have access control group set not being included in the results (even local vm). Change the query group identifier from empty to "any" to retrieve information about all guests from any groups (or without a group set). Cc: stable@vger.kernel.org Fixes: 31cb4bd31a48 ("[S390] Hypervisor filesystem (s390_hypfs) for z/VM") Reviewed-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/hypfs/hypfs_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/arch/s390/hypfs/hypfs_vm.c +++ b/arch/s390/hypfs/hypfs_vm.c @@ -20,6 +20,7 @@ =20 static char local_guest[] =3D " "; static char all_guests[] =3D "* "; +static char *all_groups =3D all_guests; static char *guest_query; =20 struct diag2fc_data { @@ -62,10 +63,11 @@ static int diag2fc(int size, char* query =20 memcpy(parm_list.userid, query, NAME_LEN); ASCEBC(parm_list.userid, NAME_LEN); - parm_list.addr =3D (unsigned long) addr ; + memcpy(parm_list.aci_grp, all_groups, NAME_LEN); + ASCEBC(parm_list.aci_grp, NAME_LEN); + parm_list.addr =3D (unsigned long)addr; parm_list.size =3D size; parm_list.fmt =3D 0x02; - memset(parm_list.aci_grp, 0x40, NAME_LEN); rc =3D -1; =20 diag_stat_inc(DIAG_STAT_X2FC); From nobody Tue Jun 30 03:34:06 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 7805AC433F5 for ; Mon, 31 Jan 2022 11:06:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359188AbiAaLGo (ORCPT ); Mon, 31 Jan 2022 06:06:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358325AbiAaLDn (ORCPT ); Mon, 31 Jan 2022 06:03:43 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86F37C06173E; Mon, 31 Jan 2022 03:03:05 -0800 (PST) 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 249AA604F5; Mon, 31 Jan 2022 11:03:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED652C340E8; Mon, 31 Jan 2022 11:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626984; bh=6eerhe6GybZvHheLPKe41Qbtj3MPhuJL4PFcSgB4LXA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2jd52qGaPbJLm8q6z+l7rvBtO7NAG9xL9whBdgxmtviehfFlDVHG2b28jeBfICuwz jCxFS+Y4gu28OLgViSnah9rJuCQH3+us4Js6MJx/OD/SRoInbE9nfNZ0eFdZfMAIah Ew0/iwnvZ+4fSbu9ebSl/TWqQH62/Ut+6IaofjLk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Naveen N. Rao" , Daniel Borkmann , Michael Ellerman Subject: [PATCH 5.10 007/100] bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack() Date: Mon, 31 Jan 2022 11:55:28 +0100 Message-Id: <20220131105220.683243480@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Naveen N. Rao commit b992f01e66150fc5e90be4a96f5eb8e634c8249e upstream. task_pt_regs() can return NULL on powerpc for kernel threads. This is then used in __bpf_get_stack() to check for user mode, resulting in a kernel oops. Guard against this by checking return value of task_pt_regs() before trying to obtain the call chain. Fixes: fa28dcb82a38f8 ("bpf: Introduce helper bpf_get_task_stack()") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Naveen N. Rao Acked-by: Daniel Borkmann Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/d5ef83c361cc255494afd15ff1b4fb02a36e1dcf.16= 41468127.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/bpf/stackmap.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -664,13 +664,14 @@ BPF_CALL_4(bpf_get_task_stack, struct ta u32, size, u64, flags) { struct pt_regs *regs; - long res; + long res =3D -EINVAL; =20 if (!try_get_task_stack(task)) return -EFAULT; =20 regs =3D task_pt_regs(task); - res =3D __bpf_get_stack(regs, task, NULL, buf, size, flags); + if (regs) + res =3D __bpf_get_stack(regs, task, NULL, buf, size, flags); put_task_stack(task); =20 return res; From nobody Tue Jun 30 03:34:06 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 3C727C433F5 for ; Mon, 31 Jan 2022 11:06:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359682AbiAaLGd (ORCPT ); Mon, 31 Jan 2022 06:06:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348444AbiAaLDn (ORCPT ); Mon, 31 Jan 2022 06:03:43 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A30A8C061401; Mon, 31 Jan 2022 03:03:08 -0800 (PST) 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 40F0560B28; Mon, 31 Jan 2022 11:03:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A044C340E8; Mon, 31 Jan 2022 11:03:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626987; bh=73BdNz4Hg5qLRQTfuS4+6Pt09s5QMlox2v1WqQLxkag=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zy2u5b1BUPVBNVvq7xexlVE+DC34AKBS0zDWqnGBQsQgLpunfRwAiw7k6xWX4J6+N am7AUl1sRey+a4TpAV0yiMolN63lN033B4mEeUBKJP+99ef6owcVw3oHOfYDg04nNi QoH5EUELDCWmVEhDcJJ0nTonEkkj4InpsUinaHzA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Benjamin Block , Steffen Maier , "Martin K. Petersen" Subject: [PATCH 5.10 008/100] scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices Date: Mon, 31 Jan 2022 11:55:29 +0100 Message-Id: <20220131105220.724050290@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Steffen Maier commit 8c9db6679be4348b8aae108e11d4be2f83976e30 upstream. Suppose we have an environment with a number of non-NPIV FCP devices (virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical FCP channel (HBA port) and its I_T nexus. Plus a number of storage target ports zoned to such shared channel. Now one target port logs out of the fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port recovery depending on the ADISC result. This happens on all such FCP devices (in different Linux images) concurrently as they all receive a copy of this RSCN. In the following we look at one of those FCP devices. Requests other than FSF_QTCB_FCP_CMND can be slow until they get a response. Depending on which requests are affected by slow responses, there are different recovery outcomes. Here we want to fix failed recoveries on port or adapter level by avoiding recovery requests that can be slow. We need the cached N_Port_ID for the remote port "link" test with ADISC. Just before sending the ADISC, we now intentionally forget the old cached N_Port_ID. The idea is that on receiving an RSCN for a port, we have to assume that any cached information about this port is stale. This forces a fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for the same port. Since we typically can still communicate with the nameserver efficiently, we now reach steady state quicker: Either the nameserver still does not know about the port so we stop recovery, or the nameserver already knows the port potentially with a new N_Port_ID and we can successfully and quickly perform open port recovery. For the one case, where ADISC returns successfully, we re-initialize port->d_id because that case does not involve any port recovery. This also solves a problem if the storage WWPN quickly logs into the fabric again but with a different N_Port_ID. Such as on virtual WWPN takeover during target NPIV failover. [https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the RSCN from the storage FDISC was ignored by zfcp and we could not successfully recover the failover. On some later failback on the storage, we could have been lucky if the virtual WWPN got the same old N_Port_ID from the SAN switch as we still had cached. Then the related RSCN triggered a successful port reopen recovery. However, there is no guarantee to get the same N_Port_ID on NPIV FDISC. Even though NPIV-enabled FCP devices are not affected by this problem, this code change optimizes recovery time for gone remote ports as a side effect. The timely drop of cached N_Port_IDs prevents unnecessary slow open port attempts. While the problem might have been in code before v2.6.32 commit 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix depends on the gid_pn_work introduced with that commit, so we mark it as culprit to satisfy fix dependencies. Note: Point-to-point remote port is already handled separately and gets its N_Port_ID from the cached peer_d_id. So resetting port->d_id in general does not affect PtP. Link: https://lore.kernel.org/r/20220118165803.3667947-1-maier@linux.ibm.com Fixes: 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") Cc: #2.6.32+ Suggested-by: Benjamin Block Reviewed-by: Benjamin Block Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/s390/scsi/zfcp_fc.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) --- a/drivers/s390/scsi/zfcp_fc.c +++ b/drivers/s390/scsi/zfcp_fc.c @@ -521,6 +521,8 @@ static void zfcp_fc_adisc_handler(void * goto out; } =20 + /* re-init to undo drop from zfcp_fc_adisc() */ + port->d_id =3D ntoh24(adisc_resp->adisc_port_id); /* port is good, unblock rport without going through erp */ zfcp_scsi_schedule_rport_register(port); out: @@ -534,6 +536,7 @@ static int zfcp_fc_adisc(struct zfcp_por struct zfcp_fc_req *fc_req; struct zfcp_adapter *adapter =3D port->adapter; struct Scsi_Host *shost =3D adapter->scsi_host; + u32 d_id; int ret; =20 fc_req =3D kmem_cache_zalloc(zfcp_fc_req_cache, GFP_ATOMIC); @@ -558,7 +561,15 @@ static int zfcp_fc_adisc(struct zfcp_por fc_req->u.adisc.req.adisc_cmd =3D ELS_ADISC; hton24(fc_req->u.adisc.req.adisc_port_id, fc_host_port_id(shost)); =20 - ret =3D zfcp_fsf_send_els(adapter, port->d_id, &fc_req->ct_els, + d_id =3D port->d_id; /* remember as destination for send els below */ + /* + * Force fresh GID_PN lookup on next port recovery. + * Must happen after request setup and before sending request, + * to prevent race with port->d_id re-init in zfcp_fc_adisc_handler(). + */ + port->d_id =3D 0; + + ret =3D zfcp_fsf_send_els(adapter, d_id, &fc_req->ct_els, ZFCP_FC_CTELS_TMO); if (ret) kmem_cache_free(zfcp_fc_req_cache, fc_req); From nobody Tue Jun 30 03:34:06 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 8F43FC433FE for ; Mon, 31 Jan 2022 11:05:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358853AbiAaLFC (ORCPT ); Mon, 31 Jan 2022 06:05:02 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:37340 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359210AbiAaLDL (ORCPT ); Mon, 31 Jan 2022 06:03:11 -0500 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 68FFE60ED2; Mon, 31 Jan 2022 11:03:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C8C3C340E8; Mon, 31 Jan 2022 11:03:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626990; bh=Jz/VWJwJXNIuMiQxshtAuSrAvUEwDJp0BSUVu+W4eaE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gc/KhZYAHkp6PSWSpELiRvZuAprJfAvskuS+6zsy1hZ33mlpjKI0cimmSN25RDzTr 850MZbNz2nZlnm64Gxc7H4RtCcdg6f5l7ya7vzG9NmoAgcKfVlkXqD0p/tVefCiwJ6 tJriIhH9U879rx9aqAI9E6K8WSvFfQydwj85O+vI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, butt3rflyh4ck , Christoph Hellwig , Jan Kara Subject: [PATCH 5.10 009/100] udf: Restore i_lenAlloc when inode expansion fails Date: Mon, 31 Jan 2022 11:55:30 +0100 Message-Id: <20220131105220.764168894@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jan Kara commit ea8569194b43f0f01f0a84c689388542c7254a1f upstream. When we fail to expand inode from inline format to a normal format, we restore inode to contain the original inline formatting but we forgot to set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then causing further problems such as warnings and lost data down the line. Reported-by: butt3rflyh4ck CC: stable@vger.kernel.org Fixes: 7e49b6f2480c ("udf: Convert UDF to new truncate calling sequence") Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/udf/inode.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -316,6 +316,7 @@ int udf_expand_file_adinicb(struct inode unlock_page(page); iinfo->i_alloc_type =3D ICBTAG_FLAG_AD_IN_ICB; inode->i_data.a_ops =3D &udf_adinicb_aops; + iinfo->i_lenAlloc =3D inode->i_size; up_write(&iinfo->i_data_sem); } put_page(page); From nobody Tue Jun 30 03:34:06 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 EF40CC433EF for ; Mon, 31 Jan 2022 11:04:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358473AbiAaLEU (ORCPT ); Mon, 31 Jan 2022 06:04:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359156AbiAaLDC (ORCPT ); Mon, 31 Jan 2022 06:03:02 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04FDDC0612FD; Mon, 31 Jan 2022 03:01:37 -0800 (PST) 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 98FEF60B2C; Mon, 31 Jan 2022 11:01:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FADBC340E8; Mon, 31 Jan 2022 11:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626896; bh=fYSbzGiZZ+SKixvbaWp+OzSqY+xqh5FdmGkaZVvd178=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q2oVb/WGuQyNRrpG059oS46NIbogxCZCTXOhsthS7QRhKP6d1Db1UPHUvpMpt6/5S fUoPT3t/bzpPqZv5ZFGPalJy+SBbDP9M5WpXJiIQEETU/5C/X0B2EfXrVILJctpBmX UkGt0YyjwqVAQhhaKTPe6YN2mqdvvQT1SQ9OOTS0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, butt3rflyh4ck , Christoph Hellwig , Jan Kara Subject: [PATCH 5.10 010/100] udf: Fix NULL ptr deref when converting from inline format Date: Mon, 31 Jan 2022 11:55:31 +0100 Message-Id: <20220131105220.804921515@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jan Kara commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream. udf_expand_file_adinicb() calls directly ->writepage to write data expanded into a page. This however misses to setup inode for writeback properly and so we can crash on inode->i_wb dereference when submitting page for IO like: BUG: kernel NULL pointer dereference, address: 0000000000000158 #PF: supervisor read access in kernel mode ... __folio_start_writeback+0x2ac/0x350 __block_write_full_page+0x37d/0x490 udf_expand_file_adinicb+0x255/0x400 [udf] udf_file_write_iter+0xbe/0x1b0 [udf] new_sync_write+0x125/0x1c0 vfs_write+0x28e/0x400 Fix the problem by marking the page dirty and going through the standard writeback path to write the page. Strictly speaking we would not even have to write the page but we want to catch e.g. ENOSPC errors early. Reported-by: butt3rflyh4ck CC: stable@vger.kernel.org Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific= bdi_writebacks") Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/udf/inode.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -257,10 +257,6 @@ int udf_expand_file_adinicb(struct inode char *kaddr; struct udf_inode_info *iinfo =3D UDF_I(inode); int err; - struct writeback_control udf_wbc =3D { - .sync_mode =3D WB_SYNC_NONE, - .nr_to_write =3D 1, - }; =20 WARN_ON_ONCE(!inode_is_locked(inode)); if (!iinfo->i_lenAlloc) { @@ -304,8 +300,10 @@ int udf_expand_file_adinicb(struct inode iinfo->i_alloc_type =3D ICBTAG_FLAG_AD_LONG; /* from now on we have normal address_space methods */ inode->i_data.a_ops =3D &udf_aops; + set_page_dirty(page); + unlock_page(page); up_write(&iinfo->i_data_sem); - err =3D inode->i_data.a_ops->writepage(page, &udf_wbc); + err =3D filemap_fdatawrite(inode->i_mapping); if (err) { /* Restore everything back so that we don't lose data... */ lock_page(page); From nobody Tue Jun 30 03:34:06 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 BC879C4321E for ; Mon, 31 Jan 2022 11:03:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348648AbiAaLDV (ORCPT ); Mon, 31 Jan 2022 06:03:21 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:34528 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358809AbiAaLBj (ORCPT ); Mon, 31 Jan 2022 06:01:39 -0500 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 A454A60B2C; Mon, 31 Jan 2022 11:01:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79602C340E8; Mon, 31 Jan 2022 11:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626899; bh=RlAyw1yro2XvdUgx7Zcqs3E/pvyLS4SrAYRZUEphfIw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z/1Y/TocN0gRZ7ZmNoPJ0tzJvajHC7UFfuUQkAiS3uMcew3N88PN45xBTLC/uGOFS olbD8l8pO3rFiVV05aRVxgHl2f+0itQEnN21284Ds+DA6yv+JbI/20Iol6ICF5sJyh /f5QeTymU3qG0nhBH8mDCmzlH7xnct5U4rJ5m6eY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeremy Kerr , Matthew Garrett , Aditya Garg , Orlando Chamberlain , Ard Biesheuvel Subject: [PATCH 5.10 011/100] efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Date: Mon, 31 Jan 2022 11:55:32 +0100 Message-Id: <20220131105220.835281614@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Ard Biesheuvel commit f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 upstream. Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.c= om/ Cc: Cc: Jeremy Kerr Cc: Matthew Garrett Reported-by: Aditya Garg Tested-by: Orlando Chamberlain Signed-off-by: Ard Biesheuvel Tested-by: Aditya Garg Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D215277 Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/firmware/efi/efi.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -719,6 +719,13 @@ void __init efi_systab_report_header(con systab_hdr->revision >> 16, systab_hdr->revision & 0xffff, vendor); + + if (IS_ENABLED(CONFIG_X86_64) && + systab_hdr->revision > EFI_1_10_SYSTEM_TABLE_REVISION && + !strcmp(vendor, "Apple")) { + pr_info("Apple Mac detected, using EFI v1.10 runtime services only\n"); + efi.runtime_version =3D EFI_1_10_SYSTEM_TABLE_REVISION; + } } =20 static __initdata char memory_type_name[][13] =3D { From nobody Tue Jun 30 03:34:06 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 2A331C433F5 for ; Mon, 31 Jan 2022 11:03:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358497AbiAaLDX (ORCPT ); Mon, 31 Jan 2022 06:03:23 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48454 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244628AbiAaLBo (ORCPT ); Mon, 31 Jan 2022 06:01:44 -0500 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 8912EB82A5F; Mon, 31 Jan 2022 11:01:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95AC2C340E8; Mon, 31 Jan 2022 11:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626902; bh=y8gnLAmebI/LsWI7Qf1t1rVMg1fjqFljK3zoLhrq18I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DKGj8WpwVyM976ouBf6FOBXAwp9zugjCeXYYXHEhnunveJrfXzU6GjeVXP7fPoxiq J6Uv70DGwSNwq7Is/BfGx7ckvZfmUg0U8x2rgdcsJvydQtcDOdOiGVh3NEjlOSP0ES VvS/3ZXq/RzaNnlafnJxHU13XtheJrzxepsyCyPc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lee Jones , "Rafael J. Wysocki" Subject: [PATCH 5.10 012/100] PM: wakeup: simplify the output logic of pm_show_wakelocks() Date: Mon, 31 Jan 2022 11:55:33 +0100 Message-Id: <20220131105220.865219539@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Greg Kroah-Hartman commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream. The buffer handling in pm_show_wakelocks() is tricky, and hopefully correct. Ensure it really is correct by using sysfs_emit_at() which handles all of the tricky string handling logic in a PAGE_SIZE buffer for us automatically as this is a sysfs file being read from. Reviewed-by: Lee Jones Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/power/wakelock.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) --- a/kernel/power/wakelock.c +++ b/kernel/power/wakelock.c @@ -39,23 +39,20 @@ ssize_t pm_show_wakelocks(char *buf, boo { struct rb_node *node; struct wakelock *wl; - char *str =3D buf; - char *end =3D buf + PAGE_SIZE; + int len =3D 0; =20 mutex_lock(&wakelocks_lock); =20 for (node =3D rb_first(&wakelocks_tree); node; node =3D rb_next(node)) { wl =3D rb_entry(node, struct wakelock, node); if (wl->ws->active =3D=3D show_active) - str +=3D scnprintf(str, end - str, "%s ", wl->name); + len +=3D sysfs_emit_at(buf, len, "%s ", wl->name); } - if (str > buf) - str--; =20 - str +=3D scnprintf(str, end - str, "\n"); + len +=3D sysfs_emit_at(buf, len, "\n"); =20 mutex_unlock(&wakelocks_lock); - return (str - buf); + return len; } =20 #if CONFIG_PM_WAKELOCKS_LIMIT > 0 From nobody Tue Jun 30 03:34:06 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 0F91DC3526E for ; Mon, 31 Jan 2022 11:03:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358680AbiAaLD0 (ORCPT ); Mon, 31 Jan 2022 06:03:26 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48590 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358627AbiAaLBr (ORCPT ); Mon, 31 Jan 2022 06:01:47 -0500 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 75149B82A5C; Mon, 31 Jan 2022 11:01:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E7DBC340EF; Mon, 31 Jan 2022 11:01:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626905; bh=caX1vW/N9Bbrw08pMT4bebAquw6LqUYjL5fAXaW2NgY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uVy0VqyoPqrUujGZ8+Kx3DtAsyXtgB5UOyBnVkh62E5Mncsd+2hdyUSkKPviP3uHK Z2oTV7uHDGLf78JwIoOcGezyNcbFary0zTSMOQIG0TG4/6B1ECStWNVgEevzkTg7MG 7JaIXnqYcp89zXDQrWWv+nuZlyA2lXMNOcJI/bFU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiaoke Wang , "Steven Rostedt (Google)" Subject: [PATCH 5.10 013/100] tracing/histogram: Fix a potential memory leak for kstrdup() Date: Mon, 31 Jan 2022 11:55:34 +0100 Message-Id: <20220131105220.901115801@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Xiaoke Wang commit e629e7b525a179e29d53463d992bdee759c950fb upstream. kfree() is missing on an error path to free the memory allocated by kstrdup(): p =3D param =3D kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). Link: https://lkml.kernel.org/r/tencent_C52895FD37802832A3E5B272D05008866F0= A@qq.com Cc: stable@vger.kernel.org Fixes: d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in = trace action") Signed-off-by: Xiaoke Wang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/trace/trace_events_hist.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -3506,6 +3506,7 @@ static int trace_action_create(struct hi =20 var_ref_idx =3D find_var_ref_idx(hist_data, var_ref); if (WARN_ON(var_ref_idx < 0)) { + kfree(p); ret =3D var_ref_idx; goto err; } From nobody Tue Jun 30 03:34:06 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 A333DC4332F for ; Mon, 31 Jan 2022 11:05:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358827AbiAaLFA (ORCPT ); Mon, 31 Jan 2022 06:05:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359170AbiAaLDD (ORCPT ); Mon, 31 Jan 2022 06:03:03 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63B33C0611FD; Mon, 31 Jan 2022 03:01:49 -0800 (PST) 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 0104060B97; Mon, 31 Jan 2022 11:01:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5F0DC340EF; Mon, 31 Jan 2022 11:01:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626908; bh=B+DGogsOqwiM6Xx+ENWP5n9rreXCJBnXxgJac87LzaU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AEHUdn4HjY926h5pxvOCvTojq2jbJCR5dA/cjyVOXTxNSyThJbUwLXJXAfEo4yota +XkF2npv13h6ZN8IV6YP+ofcsytNhuJmXF+5XibJuHbf3bK1rYRD/tfnhhm+QGUcnl /IvEgTa5rsVWeF7DzMB6LmJzYgwHqRxE4ZEeV81w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tom Zanussi , "Steven Rostedt (Google)" Subject: [PATCH 5.10 014/100] tracing: Dont inc err_log entry count if entry allocation fails Date: Mon, 31 Jan 2022 11:55:35 +0100 Message-Id: <20220131105220.941454664@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Tom Zanussi commit 67ab5eb71b37b55f7c5522d080a1b42823351776 upstream. tr->n_err_log_entries should only be increased if entry allocation succeeds. Doing it when it fails won't cause any problems other than wasting an entry, but should be fixed anyway. Link: https://lkml.kernel.org/r/cad1ab28f75968db0f466925e7cba5970cec6c29.16= 43319703.git.zanussi@kernel.org Cc: stable@vger.kernel.org Fixes: 2f754e771b1a6 ("tracing: Don't inc err_log entry count if entry allo= cation fails") Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/trace/trace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -7257,7 +7257,8 @@ static struct tracing_log_err *get_traci err =3D kzalloc(sizeof(*err), GFP_KERNEL); if (!err) err =3D ERR_PTR(-ENOMEM); - tr->n_err_log_entries++; + else + tr->n_err_log_entries++; =20 return err; } From nobody Tue Jun 30 03:34:06 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 A8E75C433EF for ; Mon, 31 Jan 2022 11:03:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358833AbiAaLDb (ORCPT ); Mon, 31 Jan 2022 06:03:31 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:49522 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358835AbiAaLBx (ORCPT ); Mon, 31 Jan 2022 06:01:53 -0500 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 A04C0B82A57; Mon, 31 Jan 2022 11:01:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E09FAC340E8; Mon, 31 Jan 2022 11:01:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626911; bh=/sgwyjPGk2ekIOjkWWWkrHy58bJWv7F+ny5Cg039Gyo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mo4sX6JV2TyPTm0hz14WHbsdFOj4JZhaX6NtgPUMVHSIv1pGuaA+TnyUFrzGuuXih M+qmGyv77iFLzo5TdjHguCt1dX3ESEIb0imx8HdRfXN5Pq8sJ89btoxlG+pYEbzfk6 mMchDUOMV2U7UD020Lh1gPzkCAYx932Zc9DyNiBs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jeff Layton , Ilya Dryomov Subject: [PATCH 5.10 015/100] ceph: properly put ceph_string reference after async create attempt Date: Mon, 31 Jan 2022 11:55:36 +0100 Message-Id: <20220131105220.973722937@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jeff Layton commit 932a9b5870d38b87ba0a9923c804b1af7d3605b9 upstream. The reference acquired by try_prep_async_create is currently leaked. Ensure we put it. Cc: stable@vger.kernel.org Fixes: 9a8d03ca2e2c ("ceph: attempt to do async create when possible") Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/ceph/file.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -743,8 +743,10 @@ retry: restore_deleg_ino(dir, req->r_deleg_ino); ceph_mdsc_put_request(req); try_async =3D false; + ceph_put_string(rcu_dereference_raw(lo.pool_ns)); goto retry; } + ceph_put_string(rcu_dereference_raw(lo.pool_ns)); goto out_req; } } From nobody Tue Jun 30 03:34:06 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 24BB7C433EF for ; Mon, 31 Jan 2022 11:03:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358950AbiAaLDi (ORCPT ); Mon, 31 Jan 2022 06:03:38 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:49566 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358412AbiAaLB5 (ORCPT ); Mon, 31 Jan 2022 06:01:57 -0500 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 E1F7DB82A62; Mon, 31 Jan 2022 11:01:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1708AC340EF; Mon, 31 Jan 2022 11:01:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626914; bh=GRxFcrspBDZRFlASEt8oRRx66DaP085lVTs5yNE/Bvk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PhA5rpgAwzh1tJMjto3IYP3sdWkmiDknoy8TLtgRG2Ajb8mteGHRI6dLuB35PFmjt Px/SHpm4smH7eZ62uMiH6zcBiKR1fI/sQUCRPdK/UEfQm935RUeR1b62wYIoT6nuTQ 02UIBdCVJzEEJd+1SBOjyJXfMpU3ImwYgu7eJOyw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan van der Ster , Jeff Layton , Ilya Dryomov Subject: [PATCH 5.10 016/100] ceph: set pool_ns in new inode layout for async creates Date: Mon, 31 Jan 2022 11:55:37 +0100 Message-Id: <20220131105221.005308257@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jeff Layton commit 4584a768f22b7669cdebabc911543621ac661341 upstream. Dan reported that he was unable to write to files that had been asynchronously created when the client's OSD caps are restricted to a particular namespace. The issue is that the layout for the new inode is only partially being filled. Ensure that we populate the pool_ns_data and pool_ns_len in the iinfo before calling ceph_fill_inode. Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/54013 Fixes: 9a8d03ca2e2c ("ceph: attempt to do async create when possible") Reported-by: Dan van der Ster Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/ceph/file.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -577,6 +577,7 @@ static int ceph_finish_async_create(stru struct ceph_inode_info *ci =3D ceph_inode(dir); struct inode *inode; struct timespec64 now; + struct ceph_string *pool_ns; struct ceph_mds_client *mdsc =3D ceph_sb_to_mdsc(dir->i_sb); struct ceph_vino vino =3D { .ino =3D req->r_deleg_ino, .snap =3D CEPH_NOSNAP }; @@ -626,6 +627,12 @@ static int ceph_finish_async_create(stru in.max_size =3D cpu_to_le64(lo->stripe_unit); =20 ceph_file_layout_to_legacy(lo, &in.layout); + /* lo is private, so pool_ns can't change */ + pool_ns =3D rcu_dereference_raw(lo->pool_ns); + if (pool_ns) { + iinfo.pool_ns_len =3D pool_ns->len; + iinfo.pool_ns_data =3D pool_ns->str; + } =20 down_read(&mdsc->snap_rwsem); ret =3D ceph_fill_inode(inode, NULL, &iinfo, NULL, req->r_session, From nobody Tue Jun 30 03:34:06 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 8D0A6C433EF for ; Mon, 31 Jan 2022 11:05:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359028AbiAaLFd (ORCPT ); Mon, 31 Jan 2022 06:05:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348689AbiAaLDX (ORCPT ); Mon, 31 Jan 2022 06:03:23 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A42DC061796; Mon, 31 Jan 2022 03:02:00 -0800 (PST) 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 64DC7B82A66; Mon, 31 Jan 2022 11:01:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87596C36AF5; Mon, 31 Jan 2022 11:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626918; bh=5RpfSYlB+m4DKtd8y+OsIMz88vwvd7QTSuwCX00payI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GnJvt/bQ7MeF5+3GFFdrD9pvoQtKZZDzBPLIXiqhcqkZzNU+qZCev7Qetp2No3fHG +VgtkG10qAFTAP4oAgUii/IG+5OAe+0KT9bQlSLLoCnpjzEd2QfR8qimYIt266IHEx pCUCX4pawI7hEWJ1Ppkr5WF9vLFRBx2PmpN48Azs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ivan Delalande , Amir Goldstein , Jan Kara Subject: [PATCH 5.10 017/100] fsnotify: fix fsnotify hooks in pseudo filesystems Date: Mon, 31 Jan 2022 11:55:38 +0100 Message-Id: <20220131105221.037533531@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Amir Goldstein commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream. Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify will have access to a positive dentry. This allowed a race where opening the deleted file via cached dentry is now possible after receiving the IN_DELETE event. To fix the regression in pseudo filesystems, convert d_delete() calls to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother with d_delete()") and move the fsnotify hook after d_drop(). Add a missing fsnotify_unlink() hook in nfsdfs that was found during the audit of fsnotify hooks in pseudo filesystems. Note that the fsnotify hooks in simple_recursive_removal() follow d_invalidate(), so they require no change. Link: https://lore.kernel.org/r/20220120215305.282577-2-amir73il@gmail.com Reported-by: Ivan Delalande Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_de= lete()") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/configfs/dir.c | 6 +++--- fs/devpts/inode.c | 2 +- fs/nfsd/nfsctl.c | 5 +++-- net/sunrpc/rpc_pipe.c | 4 ++-- 4 files changed, 9 insertions(+), 8 deletions(-) --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -1805,8 +1805,8 @@ void configfs_unregister_group(struct co configfs_detach_group(&group->cg_item); d_inode(dentry)->i_flags |=3D S_DEAD; dont_mount(dentry); + d_drop(dentry); fsnotify_rmdir(d_inode(parent), dentry); - d_delete(dentry); inode_unlock(d_inode(parent)); =20 dput(dentry); @@ -1947,10 +1947,10 @@ void configfs_unregister_subsystem(struc configfs_detach_group(&group->cg_item); d_inode(dentry)->i_flags |=3D S_DEAD; dont_mount(dentry); - fsnotify_rmdir(d_inode(root), dentry); inode_unlock(d_inode(dentry)); =20 - d_delete(dentry); + d_drop(dentry); + fsnotify_rmdir(d_inode(root), dentry); =20 inode_unlock(d_inode(root)); =20 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@ -621,8 +621,8 @@ void devpts_pty_kill(struct dentry *dent =20 dentry->d_fsdata =3D NULL; drop_nlink(dentry->d_inode); - fsnotify_unlink(d_inode(dentry->d_parent), dentry); d_drop(dentry); + fsnotify_unlink(d_inode(dentry->d_parent), dentry); dput(dentry); /* d_alloc_name() in devpts_pty_new() */ } =20 --- a/fs/nfsd/nfsctl.c +++ b/fs/nfsd/nfsctl.c @@ -1247,7 +1247,8 @@ static void nfsdfs_remove_file(struct in clear_ncl(d_inode(dentry)); dget(dentry); ret =3D simple_unlink(dir, dentry); - d_delete(dentry); + d_drop(dentry); + fsnotify_unlink(dir, dentry); dput(dentry); WARN_ON_ONCE(ret); } @@ -1336,8 +1337,8 @@ void nfsd_client_rmdir(struct dentry *de dget(dentry); ret =3D simple_rmdir(dir, dentry); WARN_ON_ONCE(ret); + d_drop(dentry); fsnotify_rmdir(dir, dentry); - d_delete(dentry); dput(dentry); inode_unlock(dir); } --- a/net/sunrpc/rpc_pipe.c +++ b/net/sunrpc/rpc_pipe.c @@ -599,9 +599,9 @@ static int __rpc_rmdir(struct inode *dir =20 dget(dentry); ret =3D simple_rmdir(dir, dentry); + d_drop(dentry); if (!ret) fsnotify_rmdir(dir, dentry); - d_delete(dentry); dput(dentry); return ret; } @@ -612,9 +612,9 @@ static int __rpc_unlink(struct inode *di =20 dget(dentry); ret =3D simple_unlink(dir, dentry); + d_drop(dentry); if (!ret) fsnotify_unlink(dir, dentry); - d_delete(dentry); dput(dentry); return ret; } From nobody Tue Jun 30 03:34:06 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 7AB11C433EF for ; Mon, 31 Jan 2022 11:05:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358981AbiAaLF3 (ORCPT ); Mon, 31 Jan 2022 06:05:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358487AbiAaLDX (ORCPT ); Mon, 31 Jan 2022 06:03:23 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F344BC061798; Mon, 31 Jan 2022 03:02:02 -0800 (PST) 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 98F51B82A65; Mon, 31 Jan 2022 11:02:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4BD1C340E8; Mon, 31 Jan 2022 11:02:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626921; bh=WJAyjRlIq6yYjRUW4AIyL7je5n2DEvtWV5A4PMP9ps0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=deT2zEYNn17cKGdLAml8ktNL+7+SI8VE7PSXV0SJNovI9uytAOPjAH9w9qd2rtm2I KeriN+Fq3Mhslz5tZdRzd/tcj8ZIoFMZPpZ3u08lKtJsFA6pRfkVZU34tvWTV9461c z2rNrBNHOPxmC26l+h9iVfNmesewk7Eu+FQheqto= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Liam Merwick , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.10 018/100] Revert "KVM: SVM: avoid infinite loop on NPF from bad address" Date: Mon, 31 Jan 2022 11:55:39 +0100 Message-Id: <20220131105221.075834982@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 31c25585695abdf03d6160aa6d829e855b256329 upstream. Revert a completely broken check on an "invalid" RIP in SVM's workaround for the DecodeAssists SMAP errata. kvm_vcpu_gfn_to_memslot() obviously expects a gfn, i.e. operates in the guest physical address space, whereas RIP is a virtual (not even linear) address. The "fix" worked for the problematic KVM selftest because the test identity mapped RIP. Fully revert the hack instead of trying to translate RIP to a GPA, as the non-SEV case is now handled earlier, and KVM cannot access guest page tables to translate RIP. This reverts commit e72436bc3a5206f95bb384e741154166ddb3202e. Fixes: e72436bc3a52 ("KVM: SVM: avoid infinite loop on NPF from bad address= ") Reported-by: Liam Merwick Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Liam Merwick Message-Id: <20220120010719.711476-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kvm/svm/svm.c | 7 ------- virt/kvm/kvm_main.c | 1 - 2 files changed, 8 deletions(-) --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4146,13 +4146,6 @@ static bool svm_can_emulate_instruction( if (likely(!insn || insn_len)) return true; =20 - /* - * If RIP is invalid, go ahead with emulation which will cause an - * internal error exit. - */ - if (!kvm_vcpu_gfn_to_memslot(vcpu, kvm_rip_read(vcpu) >> PAGE_SHIFT)) - return true; - cr4 =3D kvm_read_cr4(vcpu); smep =3D cr4 & X86_CR4_SMEP; smap =3D cr4 & X86_CR4_SMAP; --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1691,7 +1691,6 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_ { return __gfn_to_memslot(kvm_vcpu_memslots(vcpu), gfn); } -EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot); =20 bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn) { From nobody Tue Jun 30 03:34:06 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 79D74C433EF for ; Mon, 31 Jan 2022 11:05:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359453AbiAaLFg (ORCPT ); Mon, 31 Jan 2022 06:05:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358512AbiAaLDY (ORCPT ); Mon, 31 Jan 2022 06:03:24 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13118C0619CC; Mon, 31 Jan 2022 03:02:07 -0800 (PST) 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 C2193B82A66; Mon, 31 Jan 2022 11:02:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA6C8C340E8; Mon, 31 Jan 2022 11:02:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626924; bh=dxQw60n77OEynovuV/S7B/dmYWPvOU52gwf9v7TvMTM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SWZZj5qf/TowbMqnB3dF4LJRJXukaSM5fjExNRHbiY+ssv7xOSTiHN2koaoIF/rE4 IN62pM9l5ocyF+rzkss9lMhkE0XEqmxTJPYsUC/Q/wn2+wh0Gpr5mClHmAp1zXjpjP QAB16dlqTfYgkbhLs7l3iz/sJ2mwqVkq7RDkOQBI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhengjun Xing , "Peter Zijlstra (Intel)" , Adrian Hunter , Kan Liang Subject: [PATCH 5.10 019/100] perf/x86/intel/uncore: Fix CAS_COUNT_WRITE issue for ICX Date: Mon, 31 Jan 2022 11:55:40 +0100 Message-Id: <20220131105221.112453688@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Zhengjun Xing commit 96fd2e89fba1aaada6f4b1e5d25a9d9ecbe1943d upstream. The user recently report a perf issue in the ICX platform, when test by perf event =E2=80=9Cuncore_imc_x/cas_count_write=E2=80=9D,the write bandwid= th is always very small (only 0.38MB/s), it is caused by the wrong "umask" for the "cas_count_write" event. When double-checking, find "cas_count_read" also is wrong. The public document for ICX uncore: 3rd Gen Intel=C2=AE Xeon=C2=AE Processor Scalable Family, Codename Ice Lake= ,Uncore Performance Monitoring Reference Manual, Revision 1.00, May 2021 On 2.4.7, it defines Unit Masks for CAS_COUNT: RD b00001111 WR b00110000 So corrected both "cas_count_read" and "cas_count_write" for ICX. Old settings: hswep_uncore_imc_events INTEL_UNCORE_EVENT_DESC(cas_count_read, "event=3D0x04,umask=3D0x03") INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=3D0x04,umask=3D0x0c") New settings: snr_uncore_imc_events INTEL_UNCORE_EVENT_DESC(cas_count_read, "event=3D0x04,umask=3D0x0f") INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=3D0x04,umask=3D0x30") Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore sup= port") Signed-off-by: Zhengjun Xing Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Adrian Hunter Reviewed-by: Kan Liang Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20211223144826.841267-1-zhengjun.xing@linux= .intel.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/events/intel/uncore_snbep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -5239,7 +5239,7 @@ static struct intel_uncore_type icx_unco .fixed_ctr_bits =3D 48, .fixed_ctr =3D SNR_IMC_MMIO_PMON_FIXED_CTR, .fixed_ctl =3D SNR_IMC_MMIO_PMON_FIXED_CTL, - .event_descs =3D hswep_uncore_imc_events, + .event_descs =3D snr_uncore_imc_events, .perf_ctr =3D SNR_IMC_MMIO_PMON_CTR0, .event_ctl =3D SNR_IMC_MMIO_PMON_CTL0, .event_mask =3D SNBEP_PMON_RAW_EVENT_MASK, From nobody Tue Jun 30 03:34:06 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 5E27DC433F5 for ; Mon, 31 Jan 2022 11:05:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359480AbiAaLFk (ORCPT ); Mon, 31 Jan 2022 06:05:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358557AbiAaLDY (ORCPT ); Mon, 31 Jan 2022 06:03:24 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 892A4C0619D0; Mon, 31 Jan 2022 03:02:13 -0800 (PST) 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 4436AB82A61; Mon, 31 Jan 2022 11:02:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4278AC340E8; Mon, 31 Jan 2022 11:02:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626930; bh=hIkFO2I3lmGEmGDltcRJMnRhfcQ7QQuEO3j2VNgMPQg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YYvFV7HD06/c+kAaHtseodRTWMqNsGF1luZqNWW3w7dXJrdvL/XS7rLfND3Ijl4kU NVH+M2AXhsIZ+8S9R7UtmPhgg3kYJ15n18eMLubKsmc1W6FA886LiYSSIF5pvjrrr+ W5YsHmIsxuXGr40xs+lN6/J2pN9vIvSGhqJ9HwdY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lucas Stach , Christian Gmeiner Subject: [PATCH 5.10 020/100] drm/etnaviv: relax submit size limits Date: Mon, 31 Jan 2022 11:55:41 +0100 Message-Id: <20220131105221.144240536@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Lucas Stach commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream. While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -469,8 +469,8 @@ int etnaviv_ioctl_gem_submit(struct drm_ return -EINVAL; } =20 - if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K || - args->nr_bos > SZ_64K || args->nr_pmrs > 128) { + if (args->stream_size > SZ_128K || args->nr_relocs > SZ_128K || + args->nr_bos > SZ_128K || args->nr_pmrs > 128) { DRM_ERROR("submit arguments out of size limits\n"); return -EINVAL; } From nobody Tue Jun 30 03:34:06 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 D8335C433EF for ; Mon, 31 Jan 2022 11:05:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359517AbiAaLFp (ORCPT ); Mon, 31 Jan 2022 06:05:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358594AbiAaLDZ (ORCPT ); Mon, 31 Jan 2022 06:03:25 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 184C0C06174A; Mon, 31 Jan 2022 03:02:15 -0800 (PST) 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 A9FAE60BA1; Mon, 31 Jan 2022 11:02:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E11AC340E8; Mon, 31 Jan 2022 11:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626934; bh=Df7srRIny91wfHefzruMmZfr2afVsQg7wEVJd0IxqL4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lk/WdaT+wSxCjI0CjsXKGPFm85WrmS6XEu5VHWJfkLBxd4IZvEiHa/MB8bLBk2qkD BmEGSelIN8JGcePyVsY6g0iULrKAvfJUqMz8YRVTEl6O0iNlWljjNggAL8ZgA+kbv8 jMdv/kDz8qyDVM259i/IOS1qigAh3vfzS+Tn2FSI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Like Xu , Sean Christopherson , Paolo Bonzini Subject: [PATCH 5.10 021/100] KVM: x86: Update vCPUs runtime CPUID on write to MSR_IA32_XSS Date: Mon, 31 Jan 2022 11:55:42 +0100 Message-Id: <20220131105221.174993972@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Like Xu commit 4c282e51e4450b94680d6ca3b10f830483b1f243 upstream. Do a runtime CPUID update for a vCPU if MSR_IA32_XSS is written, as the size in bytes of the XSAVE area is affected by the states enabled in XSS. Fixes: 203000993de5 ("kvm: vmx: add MSR logic for XSAVES") Cc: stable@vger.kernel.org Signed-off-by: Like Xu [sean: split out as a separate patch, adjust Fixes tag] Signed-off-by: Sean Christopherson Message-Id: <20220126172226.2298529-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kvm/x86.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3171,6 +3171,7 @@ int kvm_set_msr_common(struct kvm_vcpu * if (data & ~supported_xss) return 1; vcpu->arch.ia32_xss =3D data; + kvm_update_cpuid_runtime(vcpu); break; case MSR_SMI_COUNT: if (!msr_info->host_initiated) From nobody Tue Jun 30 03:34:06 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 0F528C4332F for ; Mon, 31 Jan 2022 11:05:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358996AbiAaLFx (ORCPT ); Mon, 31 Jan 2022 06:05:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358655AbiAaLDZ (ORCPT ); Mon, 31 Jan 2022 06:03:25 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE6B8C0617A8; Mon, 31 Jan 2022 03:02:19 -0800 (PST) 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 6F730B82A5B; Mon, 31 Jan 2022 11:02:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97F02C340E8; Mon, 31 Jan 2022 11:02:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626937; bh=NfBsyqXd511sI1aYr59BUHBTMSiOCuEVCxZncdw9ims=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1uqlrZCMOKRl+zSsoog6aj1+PYYkiU30Y0nUbN3xtBxhCMo956YFcvxakx0ZXx5I+ lEsSA0S/akHzdU9jaGhHBEEjWEvgwPYBzEakc10R1vAILy9n6rwTRdFFdOhmlJkSuw LC6SBvl555w34E9vYnficEa1d2SvUfGRNVGFBUdM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, D Scott Phillips , Marc Zyngier , Catalin Marinas Subject: [PATCH 5.10 022/100] arm64: errata: Fix exec handling in erratum 1418040 workaround Date: Mon, 31 Jan 2022 11:55:43 +0100 Message-Id: <20220131105221.204911375@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: D Scott Phillips commit 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c upstream. The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0 when executing compat threads. The workaround is applied when switching between tasks, but the need for the workaround could also change at an exec(), when a non-compat task execs a compat binary or vice versa. Apply the workaround in arch_setup_new_exec(). This leaves a small window of time between SET_PERSONALITY and arch_setup_new_exec where preemption could occur and confuse the old workaround logic that compares TIF_32BIT between prev and next. Instead, we can just read cntkctl to make sure it's in the state that the next task needs. I measured cntkctl read time to be about the same as a mov from a general-purpose register on N1. Update the workaround logic to examine the current value of cntkctl instead of the previous task's compat state. Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code") Cc: # 5.9.x Signed-off-by: D Scott Phillips Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomput= ing.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/arm64/kernel/process.c | 39 ++++++++++++++++----------------------- 1 file changed, 16 insertions(+), 23 deletions(-) --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -511,34 +511,26 @@ static void entry_task_switch(struct tas =20 /* * ARM erratum 1418040 handling, affecting the 32bit view of CNTVCT. - * Assuming the virtual counter is enabled at the beginning of times: - * - * - disable access when switching from a 64bit task to a 32bit task - * - enable access when switching from a 32bit task to a 64bit task + * Ensure access is disabled when switching to a 32bit task, ensure + * access is enabled when switching to a 64bit task. */ -static void erratum_1418040_thread_switch(struct task_struct *prev, - struct task_struct *next) +static void erratum_1418040_thread_switch(struct task_struct *next) { - bool prev32, next32; - u64 val; - - if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040)) - return; - - prev32 =3D is_compat_thread(task_thread_info(prev)); - next32 =3D is_compat_thread(task_thread_info(next)); - - if (prev32 =3D=3D next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040)) + if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) || + !this_cpu_has_cap(ARM64_WORKAROUND_1418040)) return; =20 - val =3D read_sysreg(cntkctl_el1); - - if (!next32) - val |=3D ARCH_TIMER_USR_VCT_ACCESS_EN; + if (is_compat_thread(task_thread_info(next))) + sysreg_clear_set(cntkctl_el1, ARCH_TIMER_USR_VCT_ACCESS_EN, 0); else - val &=3D ~ARCH_TIMER_USR_VCT_ACCESS_EN; + sysreg_clear_set(cntkctl_el1, 0, ARCH_TIMER_USR_VCT_ACCESS_EN); +} =20 - write_sysreg(val, cntkctl_el1); +static void erratum_1418040_new_exec(void) +{ + preempt_disable(); + erratum_1418040_thread_switch(current); + preempt_enable(); } =20 /* @@ -556,7 +548,7 @@ __notrace_funcgraph struct task_struct * entry_task_switch(next); uao_thread_switch(next); ssbs_thread_switch(next); - erratum_1418040_thread_switch(prev, next); + erratum_1418040_thread_switch(next); =20 /* * Complete any pending TLB or cache maintenance on this CPU in case @@ -622,6 +614,7 @@ void arch_setup_new_exec(void) current->mm->context.flags =3D is_compat_task() ? MMCF_AARCH32 : 0; =20 ptrauth_thread_init_user(current); + erratum_1418040_new_exec(); =20 if (task_spec_ssb_noexec(current)) { arch_prctl_spec_ctrl_set(current, PR_SPEC_STORE_BYPASS, From nobody Tue Jun 30 03:34:06 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 81D20C433FE for ; Mon, 31 Jan 2022 11:04:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359230AbiAaLEr (ORCPT ); Mon, 31 Jan 2022 06:04:47 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:35926 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358435AbiAaLCV (ORCPT ); Mon, 31 Jan 2022 06:02:21 -0500 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 09D3060B28; Mon, 31 Jan 2022 11:02:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C27B3C340E8; Mon, 31 Jan 2022 11:02:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626940; bh=FdwPPk2gvLjIFkl3+JgjvyKrpdqDALAn+JhXfZlZT9I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uVOqhDUTD67ga+CnNODF1ce83f/l0G+77SxIOx/nUWYwNWt0lyJn52Bx5/wK86VEp bdXGdSjPCFh3G/j31q0toSmRQH30nda6H86JxA1mnjLO2OE6Jm7U+eFM2X2MlkkEVo LHoYv5wme+azyrNhKtnsKo0+wtozw1I30qb/s/Rk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Florian Westphal , Steffen Weinreich Subject: [PATCH 5.10 023/100] netfilter: nft_payload: do not update layer 4 checksum when mangling fragments Date: Mon, 31 Jan 2022 11:55:44 +0100 Message-Id: <20220131105221.236589643@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 4e1860a3863707e8177329c006d10f9e37e097a8 upstream. IP fragments do not come with the transport header, hence skip bogus layer 4 checksum updates. Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment f= or pseudoheader fields") Reported-and-tested-by: Steffen Weinreich Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/nft_payload.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/netfilter/nft_payload.c +++ b/net/netfilter/nft_payload.c @@ -502,6 +502,9 @@ static int nft_payload_l4csum_offset(con struct sk_buff *skb, unsigned int *l4csum_offset) { + if (pkt->xt.fragoff) + return -1; + switch (pkt->tprot) { case IPPROTO_TCP: *l4csum_offset =3D offsetof(struct tcphdr, check); From nobody Tue Jun 30 03:34:06 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 5F1FBC433F5 for ; Mon, 31 Jan 2022 11:04:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348956AbiAaLEC (ORCPT ); Mon, 31 Jan 2022 06:04:02 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:34148 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358754AbiAaLCY (ORCPT ); Mon, 31 Jan 2022 06:02:24 -0500 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 4D97960ED2; Mon, 31 Jan 2022 11:02:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1170CC340E8; Mon, 31 Jan 2022 11:02:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626943; bh=5tY0CAlJUzcoaiWnUY4WMVkJA9mAYKR3uGYW2xPE+5s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w52s5dTlfY1qzVGUgsb/POxhGNNWep5QOEDBC28vDU64OLUeT8YZDnUEX8gdwABqY AoQucmbTkITKamnwriEnE5GeU8ShYiEoPzPwEVYQsTK8K3wNyaohs7f4q2CmUbquk6 VtA+lFhltZ5nG4IISiBa8f+FhDSghS1czrEy0CUA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Hancock Subject: [PATCH 5.10 024/100] serial: 8250: of: Fix mapped region size when using reg-offset property Date: Mon, 31 Jan 2022 11:55:45 +0100 Message-Id: <20220131105221.278180857@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Robert Hancock commit d06b1cf28297e27127d3da54753a3a01a2fa2f28 upstream. 8250_of supports a reg-offset property which is intended to handle cases where the device registers start at an offset inside the region of memory allocated to the device. The Xilinx 16550 UART, for which this support was initially added, requires this. However, the code did not adjust the overall size of the mapped region accordingly, causing the driver to request an area of memory past the end of the device's allocation. For example, if the UART was allocated an address of 0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device tree, the region of memory reserved was b0131000-b0140fff, which caused the driver for the region starting at b0140000 to fail to probe. Fix this by subtracting reg-offset from the mapped region size. Fixes: b912b5e2cfb3 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16= 550.) Cc: stable Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20220112194214.881844-1-robert.hancock@cali= an.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/tty/serial/8250/8250_of.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/drivers/tty/serial/8250/8250_of.c +++ b/drivers/tty/serial/8250/8250_of.c @@ -83,8 +83,17 @@ static int of_platform_serial_setup(stru port->mapsize =3D resource_size(&resource); =20 /* Check for shifted address mapping */ - if (of_property_read_u32(np, "reg-offset", &prop) =3D=3D 0) + if (of_property_read_u32(np, "reg-offset", &prop) =3D=3D 0) { + if (prop >=3D port->mapsize) { + dev_warn(&ofdev->dev, "reg-offset %u exceeds region size %pa\n", + prop, &port->mapsize); + ret =3D -EINVAL; + goto err_unprepare; + } + port->mapbase +=3D prop; + port->mapsize -=3D prop; + } =20 port->iotype =3D UPIO_MEM; if (of_property_read_u32(np, "reg-io-width", &prop) =3D=3D 0) { From nobody Tue Jun 30 03:34:06 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 88963C433EF for ; Mon, 31 Jan 2022 11:04:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358913AbiAaLEt (ORCPT ); Mon, 31 Jan 2022 06:04:49 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:50434 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348665AbiAaLC3 (ORCPT ); Mon, 31 Jan 2022 06:02:29 -0500 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 1118AB82A5D; Mon, 31 Jan 2022 11:02:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C9ADC340E8; Mon, 31 Jan 2022 11:02:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626946; bh=6NHEPOCdbLajHTXCT6/7QGmrW1avCiXJhoiMG0d+svg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xd44LJJEONGHcpaeVLse/MqoFeWjLtUMcz4mIj7jrZCIVgR4gVqzgHISO8hIoO9/q xFrP4ym/4gxrQvhCvKBQnKp98lCSt5ENXAJZ2aaLoTpvo+3dIcoKODpQeNvA5Vz3Ce VHNmoeaXiyfyBkBhbRvqDDc9gKf3jF/V4tUsKw4w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Erwan Le Ray , Valentin Caron Subject: [PATCH 5.10 025/100] serial: stm32: fix software flow control transfer Date: Mon, 31 Jan 2022 11:55:46 +0100 Message-Id: <20220131105221.310598828@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Valentin Caron commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream. x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty. Fix start_tx condition to allow x_char to be sent. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Cc: stable Signed-off-by: Erwan Le Ray Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.s= t.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/tty/serial/stm32-usart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/stm32-usart.c +++ b/drivers/tty/serial/stm32-usart.c @@ -574,7 +574,7 @@ static void stm32_usart_start_tx(struct struct serial_rs485 *rs485conf =3D &port->rs485; struct circ_buf *xmit =3D &port->state->xmit; =20 - if (uart_circ_empty(xmit)) + if (uart_circ_empty(xmit) && !port->x_char) return; =20 if (rs485conf->flags & SER_RS485_ENABLED) { From nobody Tue Jun 30 03:34:06 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 2DEE5C433F5 for ; Mon, 31 Jan 2022 11:06:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359579AbiAaLGG (ORCPT ); Mon, 31 Jan 2022 06:06:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358799AbiAaLDb (ORCPT ); Mon, 31 Jan 2022 06:03:31 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10453C0617BA; Mon, 31 Jan 2022 03:02:31 -0800 (PST) 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 A20F760ECE; Mon, 31 Jan 2022 11:02:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62C57C340E8; Mon, 31 Jan 2022 11:02:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626950; bh=E79E0lKCQV1oboAUSdeW3yn4oz2jqkP+d4CnVeC9Gmc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wiMRXmnhXre5xuJ3ibg1cMiQz/p4sQm7HaU3P30AHappJ63eJksqkNh8kH20120jc MwR0vA8OUEE6+9BFQmWdTj9iw8Y7hKgKPsuKRszNdtK81vu78r1T5IhNFHqP7GTLXO sv08F+i7erMctt3h44m4CHN39Baw+ivYFwAAp3+I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Starke Subject: [PATCH 5.10 026/100] tty: n_gsm: fix SW flow control encoding/handling Date: Mon, 31 Jan 2022 11:55:47 +0100 Message-Id: <20220131105221.341392054@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: daniel.starke@siemens.com commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDeta= ils.aspx?specificationId=3D1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF) are the control characters defined in ISO/IEC 646. These shall be quoted if seen in the data stream to avoid interpretation as flow control characters. ISO/IEC 646 refers to the set of ISO standards described as the ISO 7-bit coded character set for information interchange. Its final version is also known as ITU T.50. See https://www.itu.int/rec/T-REC-T.50-199209-I/en To abide the standard it is needed to quote DC1 and DC3 correctly if these are seen as data bytes and not as control characters. The current implementation already tries to enforce this but fails to catch all defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most significant bit shall be ignored for DC1 and DC3 handling. The current implementation handles only the case with the most significant bit set 0. Cases in which DC1 and DC3 have the most significant bit set 1 are left unhandled. This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only the 7 least significant bits set 1) before comparing them with XON (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need quotation via byte stuffing. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220120101857.2509-1-daniel.starke@siemens= .com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/tty/n_gsm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -317,6 +317,7 @@ static struct tty_driver *gsm_tty_driver #define GSM1_ESCAPE_BITS 0x20 #define XON 0x11 #define XOFF 0x13 +#define ISO_IEC_646_MASK 0x7F =20 static const struct tty_port_operations gsm_port_ops; =20 @@ -526,7 +527,8 @@ static int gsm_stuff_frame(const u8 *inp int olen =3D 0; while (len--) { if (*input =3D=3D GSM1_SOF || *input =3D=3D GSM1_ESCAPE - || *input =3D=3D XON || *input =3D=3D XOFF) { + || (*input & ISO_IEC_646_MASK) =3D=3D XON + || (*input & ISO_IEC_646_MASK) =3D=3D XOFF) { *output++ =3D GSM1_ESCAPE; *output++ =3D *input++ ^ GSM1_ESCAPE_BITS; olen++; From nobody Tue Jun 30 03:34:06 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 6B8D4C433F5 for ; Mon, 31 Jan 2022 11:04:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358989AbiAaLEK (ORCPT ); Mon, 31 Jan 2022 06:04:10 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:50604 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358794AbiAaLCf (ORCPT ); Mon, 31 Jan 2022 06:02:35 -0500 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 65051B82A5E; Mon, 31 Jan 2022 11:02:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA549C340E8; Mon, 31 Jan 2022 11:02:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626953; bh=mQi7DC2Yo64qtEoxmuPaLsxo1LFKVrA26LL9w8rrprQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PmKdRUuUaHG4wvzelbOEMZ3dWPK5e6f0rmIutVkkEIjtZOsZQJ7JLLjUmyzkvzoO7 RCzqzoaSoIVGN4IhKZm27lkxk6iJnSRMZsUC0sXR5PlU6PLPUdXRtTHj0t1N5fxg2w MWfBeNrh7ybeupCeBjQIUBBPbyM3mfTrhrmcmwY8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Cameron Williams Subject: [PATCH 5.10 027/100] tty: Add support for Brainboxes UC cards. Date: Mon, 31 Jan 2022 11:55:48 +0100 Message-Id: <20220131105221.373197521@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Cameron Williams commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream. This commit adds support for the some of the Brainboxes PCI range of cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 and UC-420/431. Signed-off-by: Cameron Williams Cc: stable Link: https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM= 5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/tty/serial/8250/8250_pci.c | 100 ++++++++++++++++++++++++++++++++= ++++- 1 file changed, 98 insertions(+), 2 deletions(-) --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -5171,8 +5171,30 @@ static const struct pci_device_id serial { PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400, PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */ pbn_b2_4_115200 }, + /* Brainboxes Devices */ /* - * BrainBoxes UC-260 + * Brainboxes UC-101 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0BA1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-235/246 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0AA1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_1_115200 }, + /* + * Brainboxes UC-257 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0861, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-260/271/701/756 */ { PCI_VENDOR_ID_INTASHIELD, 0x0D21, PCI_ANY_ID, PCI_ANY_ID, @@ -5180,7 +5202,81 @@ static const struct pci_device_id serial pbn_b2_4_115200 }, { PCI_VENDOR_ID_INTASHIELD, 0x0E34, PCI_ANY_ID, PCI_ANY_ID, - PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, + PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-268 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0841, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-275/279 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0881, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_8_115200 }, + /* + * Brainboxes UC-302 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x08E1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-310 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x08C1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-313 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x08A3, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-320/324 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0A61, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_1_115200 }, + /* + * Brainboxes UC-346 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0B02, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-357 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0A81, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + { PCI_VENDOR_ID_INTASHIELD, 0x0A83, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-368 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0C41, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-420/431 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0921, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, pbn_b2_4_115200 }, /* * Perle PCI-RAS cards From nobody Tue Jun 30 03:34:06 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 ED155C433F5 for ; Mon, 31 Jan 2022 11:04:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240153AbiAaLEN (ORCPT ); Mon, 31 Jan 2022 06:04:13 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:50688 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358981AbiAaLCi (ORCPT ); Mon, 31 Jan 2022 06:02:38 -0500 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 8F64BB82A66; Mon, 31 Jan 2022 11:02:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC42EC340EE; Mon, 31 Jan 2022 11:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626956; bh=p9gzYhntkEFFU0kZCVkx2X3WS7L38CrCbtyOn9AY4Z0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=btusDWGH9m2g+conM9hL9mJ5ES/M1rwiP+r1kaEPNB9uhkQqz6B5xc6cT7LLyqNjT 0Yph1ME1jbZJ+ymaE6h8YiTf5I79XXdZY6tJwIfiWR13oFA7dmTfEFIg4hMZBDHpJq FjfqZSc4b8ZxuEQnAuhZlZbZ8PKi80ElWRm7SazU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, DocMAX , Alan Stern , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= Subject: [PATCH 5.10 028/100] usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge Date: Mon, 31 Jan 2022 11:55:49 +0100 Message-Id: <20220131105221.403298633@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Alan Stern commit 5b67b315037250a61861119683e7fcb509deea25 upstream. Two people have reported (and mentioned numerous other reports on the web) that VIA's VL817 USB-SATA bridge does not work with the uas driver. Typical log messages are: [ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 infligh= t: CMD [ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18= 0c c9 80 00 00 00 80 00 00 [ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 1= 1 using xhci_hcd [ 3606.328584] scsi host14: uas_eh_device_reset_handler success Surprisingly, the devices do seem to work okay for some other people. The cause of the differing behaviors is not known. In the hope of getting the devices to work for the most users, even at the possible cost of degraded performance for some, this patch adds an unusual_devs entry for the VL817 to block it from binding to the uas driver by default. Users will be able to override this entry by means of a module parameter, if they want. CC: Reported-by: DocMAX Reported-and-tested-by: Thomas Wei=C3=9Fschuh Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Ye8IsK2sjlEv1rqU@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/storage/unusual_devs.h | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -2301,6 +2301,16 @@ UNUSUAL_DEV( 0x2027, 0xa001, 0x0000, 0x USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, US_FL_SCM_MULT_TARG ), =20 +/* + * Reported by DocMAX + * and Thomas Wei=C3=9Fschuh + */ +UNUSUAL_DEV( 0x2109, 0x0715, 0x9999, 0x9999, + "VIA Labs, Inc.", + "VL817 SATA Bridge", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_IGNORE_UAS), + UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001, "ST", "2A", From nobody Tue Jun 30 03:34:06 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 2513AC433EF for ; Mon, 31 Jan 2022 11:06:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359622AbiAaLGO (ORCPT ); Mon, 31 Jan 2022 06:06:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358926AbiAaLDf (ORCPT ); Mon, 31 Jan 2022 06:03:35 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D32B4C061394; Mon, 31 Jan 2022 03:02:41 -0800 (PST) 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 9CB24B82A68; Mon, 31 Jan 2022 11:02:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC78EC340E8; Mon, 31 Jan 2022 11:02:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626959; bh=YP3uc33jwRUfDk9XScnitxmKQ9R/hWEnLuZ4nu+AswA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OntN2VS0S8l1thtwgixES/QoOJv2EPi0/KXmRG0C8qGt67GuuLUDw3wBoFEm63tIN cpMj7nZpLV8NU5j/2UG4IRbvLmacUlQp9sSfotSKXCgick80D5vDIgnFI0pYYaVg2/ BRDhvhECbcgVG0eQrpBWxFKuen1DfMQCjy5KPYWM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Peter Chen , Frank Li , Abel Vesa Subject: [PATCH 5.10 029/100] usb: xhci-plat: fix crash when suspend if remote wake enable Date: Mon, 31 Jan 2022 11:55:50 +0100 Message-Id: <20220131105221.436623527@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Frank Li commit 9df478463d9feb90dae24f183383961cf123a0ec upstream. Crashed at i.mx8qm platform when suspend if enable remote wakeup Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12 Hardware name: Freescale i.MX8QM MEK (DT) Workqueue: events_unbound async_run_entry_fn pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=3D--) pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8 lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8 sp : ffff80001394bbf0 x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578 x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000 x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001 x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0 x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453 x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620 Call trace: xhci_disable_hub_port_wake.isra.62+0x60/0xf8 xhci_suspend+0x58/0x510 xhci_plat_suspend+0x50/0x78 platform_pm_suspend+0x2c/0x78 dpm_run_callback.isra.25+0x50/0xe8 __device_suspend+0x108/0x3c0 The basic flow: 1. run time suspend call xhci_suspend, xhci parent devices gate the clock. 2. echo mem >/sys/power/state, system _device_suspend call xhci_sus= pend 3. xhci_suspend call xhci_disable_hub_port_wake, which access regis= ter, but clock already gated by run time suspend. This problem was hidden by power domain driver, which call run time resume = before it. But the below commit remove it and make this issue happen. commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_= prepare()") This patch call run time resume before suspend to make sure clock is on before access register. Reviewed-by: Peter Chen Cc: stable Signed-off-by: Frank Li Testeb-by: Abel Vesa Link: https://lore.kernel.org/r/20220110172738.31686-1-Frank.Li@nxp.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/host/xhci-plat.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -437,6 +437,9 @@ static int __maybe_unused xhci_plat_susp struct xhci_hcd *xhci =3D hcd_to_xhci(hcd); int ret; =20 + if (pm_runtime_suspended(dev)) + pm_runtime_resume(dev); + ret =3D xhci_priv_suspend_quirk(hcd); if (ret) return ret; From nobody Tue Jun 30 03:34:06 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 5F277C433EF for ; Mon, 31 Jan 2022 11:05:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358975AbiAaLFX (ORCPT ); Mon, 31 Jan 2022 06:05:23 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:36816 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359005AbiAaLCq (ORCPT ); Mon, 31 Jan 2022 06:02:46 -0500 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 6C24A60E83; Mon, 31 Jan 2022 11:02:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2ECD0C340E8; Mon, 31 Jan 2022 11:02:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626965; bh=41Bn7dpcwKdRVGJAeUT3KkBCidaikRKvL17gJkZ77QY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SQIfzgZ3rsCp8PcEzdR7sWL0ts67NtxpafoVVBM0X0/d8N+hgB2Qs4Rqgndxh/QqU 4dyMGS9sMks061sM7MWr5FXQxYRNAAICTRUqI1v3B+EaEXBAw9b16sqnPX2Yz0/+QX RzFJ5jOsNvY5AMUAMxE1z8hWU1ZNUyMx7N6RdTZE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter Subject: [PATCH 5.10 030/100] usb: common: ulpi: Fix crash in ulpi_match() Date: Mon, 31 Jan 2022 11:55:51 +0100 Message-Id: <20220131105221.467057676@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jon Hunter commit 2e3dd4a6246945bf84ea6f478365d116e661554c upstream. Commit 7495af930835 ("ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash on the Tegra20 Ventana platform in the ulpi_match() function. The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS, registers a ulpi_driver but this driver does not provide an 'id_table', so when ulpi_match() is called on the Tegra20 Ventana platform, it crashes when attempting to deference the id_table pointer which is not valid. The Qualcomm USB HS PHY driver uses device-tree for matching the ULPI driver with the device and so fix this crash by using device-tree for matching if the id_table is not valid. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable Signed-off-by: Jon Hunter Link: https://lore.kernel.org/r/20220117150039.44058-1-jonathanh@nvidia.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/common/ulpi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/common/ulpi.c +++ b/drivers/usb/common/ulpi.c @@ -39,8 +39,11 @@ static int ulpi_match(struct device *dev struct ulpi *ulpi =3D to_ulpi_dev(dev); const struct ulpi_device_id *id; =20 - /* Some ULPI devices don't have a vendor id so rely on OF match */ - if (ulpi->id.vendor =3D=3D 0) + /* + * Some ULPI devices don't have a vendor id + * or provide an id_table so rely on OF match. + */ + if (ulpi->id.vendor =3D=3D 0 || !drv->id_table) return of_driver_match_device(dev, driver); =20 for (id =3D drv->id_table; id->vendor; id++) From nobody Tue Jun 30 03:34:06 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 9707FC433EF for ; Mon, 31 Jan 2022 11:05:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359347AbiAaLFO (ORCPT ); Mon, 31 Jan 2022 06:05:14 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:36880 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359034AbiAaLCt (ORCPT ); Mon, 31 Jan 2022 06:02:49 -0500 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 7600E60ABE; Mon, 31 Jan 2022 11:02:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5ABB5C340E8; Mon, 31 Jan 2022 11:02:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626968; bh=ENdP0HiCeo/ou9suAY2/M17r/tqT17x+t6XVJsAoOcM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vceD5xWbcfbF5JmURmU9Vex1oKScoQm2YG4OkbY228ruAVzbg9CGNiK2W80hTQFrU hkFzXNgmzDOY2EoDmp/Cefucym4qDd9o/0tZ0a9glKpYDzTPzJ+hK3Dz+0SLCT0cJV Lo1xkgEt0ND9f0NDC/k5+SVlLhklndM6ize09O8I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavankumar Kondeti Subject: [PATCH 5.10 031/100] usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS Date: Mon, 31 Jan 2022 11:55:52 +0100 Message-Id: <20220131105221.498803465@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Pavankumar Kondeti commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream. Currently when gadget enumerates in super speed plus, the isoc endpoint request buffer size is not calculated correctly. Fix this by checking the gadget speed against USB_SPEED_SUPER_PLUS and update the request buffer size. Fixes: 90c4d05780d4 ("usb: fix various gadgets null ptr deref on 10gbps cab= ling.") Cc: stable Signed-off-by: Pavankumar Kondeti Link: https://lore.kernel.org/r/1642820602-20619-1-git-send-email-quic_pkon= deti@quicinc.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/gadget/function/f_sourcesink.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/function/f_sourcesink.c +++ b/drivers/usb/gadget/function/f_sourcesink.c @@ -583,6 +583,7 @@ static int source_sink_start_ep(struct f =20 if (is_iso) { switch (speed) { + case USB_SPEED_SUPER_PLUS: case USB_SPEED_SUPER: size =3D ss->isoc_maxpacket * (ss->isoc_mult + 1) * From nobody Tue Jun 30 03:34:06 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 50593C433EF for ; Mon, 31 Jan 2022 11:06:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358927AbiAaLGx (ORCPT ); Mon, 31 Jan 2022 06:06:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348388AbiAaLDm (ORCPT ); Mon, 31 Jan 2022 06:03:42 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5AE7C061396; Mon, 31 Jan 2022 03:02:52 -0800 (PST) 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 A789D604F5; Mon, 31 Jan 2022 11:02:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67901C340F0; Mon, 31 Jan 2022 11:02:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626972; bh=1LgKzmcCvHoFy00WUIz8e+Yegma2rlfciCa4tSevxHw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=njjlDf83VyHaD95v0UbO7TqLG5D1Wi/8dqTOOCC0JiCCpRyuywDSM4ZZNB7f+rCfn V7IWrD7zwDvJu6ELMAfYiUxmQKEeeRkxyRuzYRkXEtDwRSQi29ak1v3d/HNBVGBcau CRv3fozvOky2QM8H9+twz8hXEJ8hVDot0QOItIjM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.com Subject: [PATCH 5.10 032/100] USB: core: Fix hang in usb_kill_urb by adding memory barriers Date: Mon, 31 Jan 2022 11:55:53 +0100 Message-Id: <20220131105221.529476021@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Alan Stern commit 26fbe9772b8c459687930511444ce443011f86bf upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) =3D=3D 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: Reported-and-tested-by: syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.c= om Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+) --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1562,6 +1562,13 @@ int usb_hcd_submit_urb (struct urb *urb, urb->hcpriv =3D NULL; INIT_LIST_HEAD(&urb->urb_list); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + atomic_dec(&urb->dev->urbnum); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); @@ -1666,6 +1673,13 @@ static void __usb_hcd_giveback_urb(struc =20 usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + if (unlikely(atomic_read(&urb->reject))) wake_up(&usb_kill_urb_queue); usb_put_urb(urb); --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -706,6 +706,12 @@ void usb_kill_urb(struct urb *urb) if (!(urb && urb->dev && urb->ep)) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); =20 usb_hcd_unlink_urb(urb, -ENOENT); wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) =3D=3D 0); @@ -747,6 +753,12 @@ void usb_poison_urb(struct urb *urb) if (!urb) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); =20 if (!urb->dev || !urb->ep) return; From nobody Tue Jun 30 03:34:06 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 C00ACC433EF for ; Mon, 31 Jan 2022 11:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376431AbiAaLI0 (ORCPT ); Mon, 31 Jan 2022 06:08:26 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52000 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358897AbiAaLFJ (ORCPT ); Mon, 31 Jan 2022 06:05:09 -0500 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 80E6FB82A4D; Mon, 31 Jan 2022 11:05:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2BC1C340E8; Mon, 31 Jan 2022 11:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627105; bh=OUhEJvXOgBhzU0u44Xd5EN8/jjiRO3tNqHcCjxWqQWY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KDXdrTsZUAOC81xYn7YHII6954FFocynvZ7Bt8w0badzGoh6hMhrxjUx3jqev8Zio PhXb9xD6+uSgWjVYC6Jp8qIm3kPFNJnZS6sYcVH6aelz6UHrGps9mShXzrWn1sCvKF QbjKHr7+U4mWnchpu4hlseX9Ag0D0y+uuW4vdqhA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heikki Krogerus , Badhri Jagan Sridharan Subject: [PATCH 5.10 033/100] usb: typec: tcpm: Do not disconnect while receiving VBUS off Date: Mon, 31 Jan 2022 11:55:54 +0100 Message-Id: <20220131105221.560972591@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Badhri Jagan Sridharan commit 90b8aa9f5b09edae6928c0561f933fec9f7a9987 upstream. With some chargers, vbus might momentarily raise above VSAFE5V and fall back to 0V before tcpm gets to read port->tcpc->get_vbus. This will will report a VBUS off event causing TCPM to transition to SNK_UNATTACHED where it should be waiting in either SNK_ATTACH_WAIT or SNK_DEBOUNCED state. This patch makes TCPM avoid vbus off events while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state. Stub from the spec: "4.5.2.2.4.2 Exiting from AttachWait.SNK State A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce." [23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, con= nected] [23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms = [rev3 NONE_AMS] [23.300579] VBUS off [23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS] [23.301014] VBUS VSAFE0V [23.301111] Start toggling Fixes: f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20220122015520.332507-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/typec/tcpm/tcpm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -4164,7 +4164,8 @@ static void _tcpm_pd_vbus_off(struct tcp case SNK_TRYWAIT_DEBOUNCE: break; case SNK_ATTACH_WAIT: - tcpm_set_state(port, SNK_UNATTACHED, 0); + case SNK_DEBOUNCED: + /* Do nothing, as TCPM is still waiting for vbus to reaach VSAFE5V to co= nnect */ break; =20 case SNK_NEGOTIATE_CAPABILITIES: From nobody Tue Jun 30 03:34:06 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 35149C433F5 for ; Mon, 31 Jan 2022 11:06:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359679AbiAaLGb (ORCPT ); Mon, 31 Jan 2022 06:06:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358328AbiAaLDn (ORCPT ); Mon, 31 Jan 2022 06:03:43 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFF36C061758; Mon, 31 Jan 2022 03:03:17 -0800 (PST) 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 4FA5C60B28; Mon, 31 Jan 2022 11:03:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 328EFC340E8; Mon, 31 Jan 2022 11:03:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626996; bh=1Q6eTWeiWtR6LSvwQnJSzAWZZD9k4gQvDPMrLqZSTwg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cF0Dy9NKoOeyL7RpIm1GXTnScWt9s2hgD0qdoBejEeAV1+qaZH75FE16i+vq7y8EK Zilk7Q+mLYzXF0BFig8f6VuT8XTsBceSWDEKxBxzYTzPpGqjs+e6mu3Kju1P4qWQof zyT0EyEGqx8AptHr3vjXNRyt2p0w2uKxo8YfDC/0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heikki Krogerus , Sing-Han Chen , Wayne Chang Subject: [PATCH 5.10 034/100] ucsi_ccg: Check DEV_INT bit only when starting CCG4 Date: Mon, 31 Jan 2022 11:55:55 +0100 Message-Id: <20220131105221.599194183@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Sing-Han Chen commit 825911492eb15bf8bb7fb94bc0c0421fe7a6327d upstream. CCGx clears Bit 0:Device Interrupt in the INTR_REG if CCGx is reset successfully. However, there might be a chance that other bits in INTR_REG are not cleared due to internal data queued in PPM. This case misleads the driver that CCGx reset failed. The commit checks bit 0 in INTR_REG and ignores other bits. The ucsi driver would reset PPM later. Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Signed-off-by: Sing-Han Chen Signed-off-by: Wayne Chang Link: https://lore.kernel.org/r/20220112094143.628610-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/usb/typec/ucsi/ucsi_ccg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/typec/ucsi/ucsi_ccg.c +++ b/drivers/usb/typec/ucsi/ucsi_ccg.c @@ -325,7 +325,7 @@ static int ucsi_ccg_init(struct ucsi_ccg if (status < 0) return status; =20 - if (!data) + if (!(data & DEV_INT)) return 0; =20 status =3D ccg_write(uc, CCGX_RAB_INTR_REG, &data, sizeof(data)); From nobody Tue Jun 30 03:34:06 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 37D53C43217 for ; Mon, 31 Jan 2022 11:07:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358551AbiAaLHM (ORCPT ); Mon, 31 Jan 2022 06:07:12 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38394 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358733AbiAaLDu (ORCPT ); Mon, 31 Jan 2022 06:03:50 -0500 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 4E61B60F15; Mon, 31 Jan 2022 11:03:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FB7FC340E8; Mon, 31 Jan 2022 11:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627029; bh=Ws3K9zlRqrXyHD/WFYrifz5ik5TGQzIrwTz7hDSe72A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TcC63E+Pr6DC4P6x8zjtDtvKpawZW5M/M6pODsOF8SJ3k2vS8421O3fsByT2+cM0y nqzRwrvC/9876k4fYLivhu+YP25oh5QXsg7LN2zJtmzbhM0x4yXwzqeG7Cm6pwq5GZ ycWuRxpklwkIVgrONtH90sTtLRS1CGr23ig1iqV0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joseph Qi , Mark Fasheh , Joel Becker , Junxiao Bi , Changwei Ge , Gang He , Jun Piao , Andreas Dilger , Gautham Ananthakrishna , Saeed Mirzamohammadi , "Theodore Tso" , Andrew Morton , Linus Torvalds Subject: [PATCH 5.10 035/100] jbd2: export jbd2_journal_[grab|put]_journal_head Date: Mon, 31 Jan 2022 11:55:56 +0100 Message-Id: <20220131105221.631074510@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Joseph Qi commit 4cd1103d8c66b2cdb7e64385c274edb0ac5e8887 upstream. Patch series "ocfs2: fix a deadlock case". This fixes a deadlock case in ocfs2. We firstly export jbd2 symbols jbd2_journal_[grab|put]_journal_head as preparation and later use them in ocfs2 insread of jbd_[lock|unlock]_bh_journal_head to fix the deadlock. This patch (of 2): This exports symbols jbd2_journal_[grab|put]_journal_head, which will be used outside modules, e.g. ocfs2. Link: https://lkml.kernel.org/r/20220121071205.100648-2-joseph.qi@linux.ali= baba.com Signed-off-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Andreas Dilger Cc: Gautham Ananthakrishna Cc: Saeed Mirzamohammadi Cc: "Theodore Ts'o" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/jbd2/journal.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -2795,6 +2795,7 @@ struct journal_head *jbd2_journal_grab_j jbd_unlock_bh_journal_head(bh); return jh; } +EXPORT_SYMBOL(jbd2_journal_grab_journal_head); =20 static void __journal_remove_journal_head(struct buffer_head *bh) { @@ -2847,6 +2848,7 @@ void jbd2_journal_put_journal_head(struc jbd_unlock_bh_journal_head(bh); } } +EXPORT_SYMBOL(jbd2_journal_put_journal_head); =20 /* * Initialize jbd inode head From nobody Tue Jun 30 03:34:06 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 427B7C433FE for ; Mon, 31 Jan 2022 11:10:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359798AbiAaLH5 (ORCPT ); Mon, 31 Jan 2022 06:07:57 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52344 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359139AbiAaLE0 (ORCPT ); Mon, 31 Jan 2022 06:04:26 -0500 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 0C64CB82A66; Mon, 31 Jan 2022 11:04:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3DB6C340E8; Mon, 31 Jan 2022 11:04:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627063; bh=vyg+4TvZoYeDggdG1JwpcL5LTHe6BlggCSP8GiUcu2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yZ1iW3TZw1Xzic6TNXsGXRMMhQogk6YsekQyG9NOgAxbrj3G6mOkoAUAdITsWXVD4 Ia/4Ux/7Zv6SOJZV00Cia8v4CgGK8odAdSjsnMhh8IXpaqvE2fI6cv+wn67cpLQUQL bkdyBy6QGSaStv4uaoArMQQZWvNPzTNQyGEh3d3E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joseph Qi , Gautham Ananthakrishna , Saeed Mirzamohammadi , "Theodore Tso" , Andreas Dilger , Changwei Ge , Gang He , Joel Becker , Jun Piao , Junxiao Bi , Mark Fasheh , Andrew Morton , Linus Torvalds Subject: [PATCH 5.10 036/100] ocfs2: fix a deadlock when commit trans Date: Mon, 31 Jan 2022 11:55:57 +0100 Message-Id: <20220131105221.661935365@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Joseph Qi commit ddf4b773aa40790dfa936bd845c18e735a49c61c upstream. commit 6f1b228529ae introduces a regression which can deadlock as follows: Task1: Task2: jbd2_journal_commit_transaction ocfs2_test_bg_bit_allocatable spin_lock(&jh->b_state_lock) jbd_lock_bh_journal_head __jbd2_journal_remove_checkpoint spin_lock(&jh->b_state_lock) jbd2_journal_put_journal_head jbd_lock_bh_journal_head Task1 and Task2 lock bh->b_state and jh->b_state_lock in different order, which finally result in a deadlock. So use jbd2_journal_[grab|put]_journal_head instead in ocfs2_test_bg_bit_allocatable() to fix it. Link: https://lkml.kernel.org/r/20220121071205.100648-3-joseph.qi@linux.ali= baba.com Fixes: 6f1b228529ae ("ocfs2: fix race between searching chunks and release = journal_head from buffer_head") Signed-off-by: Joseph Qi Reported-by: Gautham Ananthakrishna Tested-by: Gautham Ananthakrishna Reported-by: Saeed Mirzamohammadi Cc: "Theodore Ts'o" Cc: Andreas Dilger Cc: Changwei Ge Cc: Gang He Cc: Joel Becker Cc: Jun Piao Cc: Junxiao Bi Cc: Mark Fasheh Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/ocfs2/suballoc.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1253,26 +1253,23 @@ static int ocfs2_test_bg_bit_allocatable { struct ocfs2_group_desc *bg =3D (struct ocfs2_group_desc *) bg_bh->b_data; struct journal_head *jh; - int ret =3D 1; + int ret; =20 if (ocfs2_test_bit(nr, (unsigned long *)bg->bg_bitmap)) return 0; =20 - if (!buffer_jbd(bg_bh)) + jh =3D jbd2_journal_grab_journal_head(bg_bh); + if (!jh) return 1; =20 - jbd_lock_bh_journal_head(bg_bh); - if (buffer_jbd(bg_bh)) { - jh =3D bh2jh(bg_bh); - spin_lock(&jh->b_state_lock); - bg =3D (struct ocfs2_group_desc *) jh->b_committed_data; - if (bg) - ret =3D !ocfs2_test_bit(nr, (unsigned long *)bg->bg_bitmap); - else - ret =3D 1; - spin_unlock(&jh->b_state_lock); - } - jbd_unlock_bh_journal_head(bg_bh); + spin_lock(&jh->b_state_lock); + bg =3D (struct ocfs2_group_desc *) jh->b_committed_data; + if (bg) + ret =3D !ocfs2_test_bit(nr, (unsigned long *)bg->bg_bitmap); + else + ret =3D 1; + spin_unlock(&jh->b_state_lock); + jbd2_journal_put_journal_head(jh); =20 return ret; } From nobody Tue Jun 30 03:34:06 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 F422BC433EF for ; Mon, 31 Jan 2022 11:15:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358907AbiAaLO5 (ORCPT ); Mon, 31 Jan 2022 06:14:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349210AbiAaLGv (ORCPT ); Mon, 31 Jan 2022 06:06:51 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 334DBC061394; Mon, 31 Jan 2022 03:04:49 -0800 (PST) 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 E2D22B82A59; Mon, 31 Jan 2022 11:04:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3979FC340E8; Mon, 31 Jan 2022 11:04:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627086; bh=A87i1zJgpgfpgVNLS/bYqudetWowmmB8GJRnlDrhw9M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qzvc0p+oQf2nZqzS5n6jfCvaioZK6f0IDsX+/uyRehccWYf+s+Nb4iNphDVlcb0Un 3ysgIzOJfmliAxEMgR5c0q6LbmXN5eAjGS0rmhn8/LN6YWht2Qq728U7P3V50T6kBU Hnyxc0ZoHrtUSulKriZPH8YjxTZIuydrpFVOc0h4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mathieu Desnoyers , "Peter Zijlstra (Intel)" Subject: [PATCH 5.10 037/100] sched/membarrier: Fix membarrier-rseq fence command missing from query bitmask Date: Mon, 31 Jan 2022 11:55:58 +0100 Message-Id: <20220131105221.694727913@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Mathieu Desnoyers commit 809232619f5b15e31fb3563985e705454f32621f upstream. The membarrier command MEMBARRIER_CMD_QUERY allows querying the available membarrier commands. When the membarrier-rseq fence commands were added, a new MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK was introduced with the intent to expose them with the MEMBARRIER_CMD_QUERY command, the but it was never added to MEMBARRIER_CMD_BITMASK. The membarrier-rseq fence commands are therefore not wired up with the query command. Rename MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK to MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK (the bitmask is not a command per-se), and change the erroneous MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ_BITMASK (which does not actually exist) to MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ. Wire up MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK in MEMBARRIER_CMD_BITMASK. Fixing this allows discovering availability of the membarrier-rseq fence feature. Fixes: 2a36ab717e8f ("rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED= _RSEQ") Signed-off-by: Mathieu Desnoyers Signed-off-by: Peter Zijlstra (Intel) Cc: # 5.10+ Link: https://lkml.kernel.org/r/20220117203010.30129-1-mathieu.desnoyers@ef= ficios.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/sched/membarrier.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -19,11 +19,11 @@ #endif =20 #ifdef CONFIG_RSEQ -#define MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK \ +#define MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK \ (MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ \ - | MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ_BITMASK) + | MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ) #else -#define MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK 0 +#define MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK 0 #endif =20 #define MEMBARRIER_CMD_BITMASK \ @@ -31,7 +31,8 @@ | MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED \ | MEMBARRIER_CMD_PRIVATE_EXPEDITED \ | MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED \ - | MEMBARRIER_PRIVATE_EXPEDITED_SYNC_CORE_BITMASK) + | MEMBARRIER_PRIVATE_EXPEDITED_SYNC_CORE_BITMASK \ + | MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK) =20 static void ipi_mb(void *info) { From nobody Tue Jun 30 03:34:06 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 EEBE9C4321E for ; Mon, 31 Jan 2022 11:10:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376350AbiAaLIQ (ORCPT ); Mon, 31 Jan 2022 06:08:16 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52684 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348750AbiAaLEw (ORCPT ); Mon, 31 Jan 2022 06:04:52 -0500 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 7740DB82A59; Mon, 31 Jan 2022 11:04:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31BE8C340E8; Mon, 31 Jan 2022 11:04:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627090; bh=Zy/7wJoEBkcy3hAg4JIzp40lgboP5C93DThdpp8EI0w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kkdL/Y8C5n7J3f3adbd701pSXWzzW0OqG87RxEyciiw3ftpriWcHn1sJ7vzve+p3y V3JTx5KdOUjyH1CMJtBcNC3VZ+WWmNEV2DxiSO/00HsBUwh+1M72TcGcmNQbu3DkKp NoAiQST1UGOYDjYNf/mZEl4txK2KgdhgViAHsiNg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yazen Ghannam , Borislav Petkov Subject: [PATCH 5.10 038/100] x86/MCE/AMD: Allow thresholding interface updates after init Date: Mon, 31 Jan 2022 11:55:59 +0100 Message-Id: <20220131105221.726260203@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Yazen Ghannam commit 1f52b0aba6fd37653416375cb8a1ca673acf8d5f upstream. Changes to the AMD Thresholding sysfs code prevents sysfs writes from updating the underlying registers once CPU init is completed, i.e. "threshold_banks" is set. Allow the registers to be updated if the thresholding interface is already initialized or if in the init path. Use the "set_lvt_off" value to indicate if running in the init path, since this value is only set during init. Fixes: a037f3ca0ea0 ("x86/mce/amd: Make threshold bank setting hotplug robu= st") Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Cc: Link: https://lore.kernel.org/r/20220117161328.19148-1-yazen.ghannam@amd.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kernel/cpu/mce/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -387,7 +387,7 @@ static void threshold_restart_bank(void u32 hi, lo; =20 /* sysfs write might race against an offline operation */ - if (this_cpu_read(threshold_banks)) + if (!this_cpu_read(threshold_banks) && !tr->set_lvt_off) return; =20 rdmsr(tr->b->address, lo, hi); From nobody Tue Jun 30 03:34:06 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 0B2B8C4167E for ; Mon, 31 Jan 2022 11:10:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376373AbiAaLIU (ORCPT ); Mon, 31 Jan 2022 06:08:20 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:39418 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359278AbiAaLEy (ORCPT ); Mon, 31 Jan 2022 06:04:54 -0500 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 C413E60EFE; Mon, 31 Jan 2022 11:04:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BDBEC36AE7; Mon, 31 Jan 2022 11:04:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627093; bh=bh57M7kPGJHMCFswNDB0rtNduQxQs1+ujCn7yAjpzDo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i4bIEQcZxiU+WeYUkqEOFVCW+TeNaWC4IxvR0T6yGaZRZfEMWJJrpzXOo2ez+xpM6 T74tK1wElVGR2hCoJh8JqUOn6oBF3YQMnduAxXEbKIL6rMxtLGQjwXN70SpPcpiY5m ClI5rw6hAJGPn6xpOzuhyCEO9bmONk1t5PmQcgyI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christophe Leroy , Michael Ellerman Subject: [PATCH 5.10 039/100] powerpc/32s: Allocate one 256k IBAT instead of two consecutives 128k IBATs Date: Mon, 31 Jan 2022 11:56:00 +0100 Message-Id: <20220131105221.758203839@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Christophe Leroy commit 37eb7ca91b692e8e49e7dd50158349a6c8fb5b09 upstream. Today we have the following IBATs allocated: ---[ Instruction Block Address Translation ]--- 0: 0xc0000000-0xc03fffff 0x00000000 4M Kernel x m 1: 0xc0400000-0xc05fffff 0x00400000 2M Kernel x m 2: 0xc0600000-0xc06fffff 0x00600000 1M Kernel x m 3: 0xc0700000-0xc077ffff 0x00700000 512K Kernel x m 4: 0xc0780000-0xc079ffff 0x00780000 128K Kernel x m 5: 0xc07a0000-0xc07bffff 0x007a0000 128K Kernel x m 6: - 7: - The two 128K should be a single 256K instead. When _etext is not aligned to 128Kbytes, the system will allocate all necessary BATs to the lower 128Kbytes boundary, then allocate an additional 128Kbytes BAT for the remaining block. Instead, align the top to 128Kbytes so that the function directly allocates a 256Kbytes last block: ---[ Instruction Block Address Translation ]--- 0: 0xc0000000-0xc03fffff 0x00000000 4M Kernel x m 1: 0xc0400000-0xc05fffff 0x00400000 2M Kernel x m 2: 0xc0600000-0xc06fffff 0x00600000 1M Kernel x m 3: 0xc0700000-0xc077ffff 0x00700000 512K Kernel x m 4: 0xc0780000-0xc07bffff 0x00780000 256K Kernel x m 5: - 6: - 7: - Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/ab58b296832b0ec650e2203200e060adbcb2677d.16= 37930421.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/powerpc/mm/book3s32/mmu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/arch/powerpc/mm/book3s32/mmu.c +++ b/arch/powerpc/mm/book3s32/mmu.c @@ -201,18 +201,17 @@ void mmu_mark_initmem_nx(void) int nb =3D mmu_has_feature(MMU_FTR_USE_HIGH_BATS) ? 8 : 4; int i; unsigned long base =3D (unsigned long)_stext - PAGE_OFFSET; - unsigned long top =3D (unsigned long)_etext - PAGE_OFFSET; + unsigned long top =3D ALIGN((unsigned long)_etext - PAGE_OFFSET, SZ_128K); unsigned long border =3D (unsigned long)__init_begin - PAGE_OFFSET; unsigned long size; =20 - for (i =3D 0; i < nb - 1 && base < top && top - base > (128 << 10);) { + for (i =3D 0; i < nb - 1 && base < top;) { size =3D block_size(base, top); setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); base +=3D size; } if (base < top) { size =3D block_size(base, top); - size =3D max(size, 128UL << 10); if ((top - base) > size) { size <<=3D 1; if (strict_kernel_rwx_enabled() && base + size > border) From nobody Tue Jun 30 03:34:06 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 C19DFC43217 for ; Mon, 31 Jan 2022 11:11:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349336AbiAaLLq (ORCPT ); Mon, 31 Jan 2022 06:11:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359809AbiAaLH6 (ORCPT ); Mon, 31 Jan 2022 06:07:58 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7BCAC061367; Mon, 31 Jan 2022 03:04:58 -0800 (PST) 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 75AEAB82A4D; Mon, 31 Jan 2022 11:04:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7307C340EE; Mon, 31 Jan 2022 11:04:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627096; bh=CteQb1qQvAZdJIx0midhc1gCQV+tj85w1m+T+Aatu+U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RIEWYeDyM5pBhipxG+nr8Ki716q6ZPTCh2MCrCJu6/DmC/5bKF4/CBpRu6FSycKHU 7vcwTItPg0AU+olW5PH9zt0UmMQWiyqn8R8SZKk2+nS0ZDpTgjKzvIJHzSX0Gm1sOx pKD9QaGMIyGVnZjKkftYLfsP1VQBs+NOmXzRKKGg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxime Bizon , Christophe Leroy , Michael Ellerman Subject: [PATCH 5.10 040/100] powerpc/32s: Fix kasan_init_region() for KASAN Date: Mon, 31 Jan 2022 11:56:01 +0100 Message-Id: <20220131105221.789775518@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Christophe Leroy commit d37823c3528e5e0705fc7746bcbc2afffb619259 upstream. It has been reported some configuration where the kernel doesn't boot with KASAN enabled. This is due to wrong BAT allocation for the KASAN area: ---[ Data Block Address Translation ]--- 0: 0xc0000000-0xcfffffff 0x00000000 256M Kernel rw m 1: 0xd0000000-0xdfffffff 0x10000000 256M Kernel rw m 2: 0xe0000000-0xefffffff 0x20000000 256M Kernel rw m 3: 0xf8000000-0xf9ffffff 0x2a000000 32M Kernel rw m 4: 0xfa000000-0xfdffffff 0x2c000000 64M Kernel rw m A BAT must have both virtual and physical addresses alignment matching the size of the BAT. This is not the case for BAT 4 above. Fix kasan_init_region() by using block_size() function that is in book3s32/mmu.c. To be able to reuse it here, make it non static and change its name to bat_block_size() in order to avoid name conflict with block_size() defined in Also reuse find_free_bat() to avoid an error message from setbat() when no BAT is available. And allocate memory outside of linear memory mapping to avoid wasting that precious space. With this change we get correct alignment for BATs and KASAN shadow memory is allocated outside the linear memory space. ---[ Data Block Address Translation ]--- 0: 0xc0000000-0xcfffffff 0x00000000 256M Kernel rw 1: 0xd0000000-0xdfffffff 0x10000000 256M Kernel rw 2: 0xe0000000-0xefffffff 0x20000000 256M Kernel rw 3: 0xf8000000-0xfbffffff 0x7c000000 64M Kernel rw 4: 0xfc000000-0xfdffffff 0x7a000000 32M Kernel rw Fixes: 7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()") Cc: stable@vger.kernel.org Reported-by: Maxime Bizon Signed-off-by: Christophe Leroy Tested-by: Maxime Bizon Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/7a50ef902494d1325227d47d33dada01e52e5518.16= 41818726.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2=20 arch/powerpc/mm/book3s32/mmu.c | 10 ++-- arch/powerpc/mm/kasan/book3s_32.c | 57 +++++++++++++--------= ----- 3 files changed, 37 insertions(+), 32 deletions(-) --- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h +++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h @@ -102,6 +102,8 @@ extern s32 patch__hash_page_B, patch__ha extern s32 patch__flush_hash_A0, patch__flush_hash_A1, patch__flush_hash_A= 2; extern s32 patch__flush_hash_B; =20 +int __init find_free_bat(void); +unsigned int bat_block_size(unsigned long base, unsigned long top); #endif /* !__ASSEMBLY__ */ =20 /* We happily ignore the smaller BATs on 601, we don't actually use --- a/arch/powerpc/mm/book3s32/mmu.c +++ b/arch/powerpc/mm/book3s32/mmu.c @@ -72,7 +72,7 @@ unsigned long p_block_mapped(phys_addr_t return 0; } =20 -static int find_free_bat(void) +int __init find_free_bat(void) { int b; int n =3D mmu_has_feature(MMU_FTR_USE_HIGH_BATS) ? 8 : 4; @@ -96,7 +96,7 @@ static int find_free_bat(void) * - block size has to be a power of two. This is calculated by finding the * highest bit set to 1. */ -static unsigned int block_size(unsigned long base, unsigned long top) +unsigned int bat_block_size(unsigned long base, unsigned long top) { unsigned int max_size =3D SZ_256M; unsigned int base_shift =3D (ffs(base) - 1) & 31; @@ -141,7 +141,7 @@ static unsigned long __init __mmu_mapin_ int idx; =20 while ((idx =3D find_free_bat()) !=3D -1 && base !=3D top) { - unsigned int size =3D block_size(base, top); + unsigned int size =3D bat_block_size(base, top); =20 if (size < 128 << 10) break; @@ -206,12 +206,12 @@ void mmu_mark_initmem_nx(void) unsigned long size; =20 for (i =3D 0; i < nb - 1 && base < top;) { - size =3D block_size(base, top); + size =3D bat_block_size(base, top); setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); base +=3D size; } if (base < top) { - size =3D block_size(base, top); + size =3D bat_block_size(base, top); if ((top - base) > size) { size <<=3D 1; if (strict_kernel_rwx_enabled() && base + size > border) --- a/arch/powerpc/mm/kasan/book3s_32.c +++ b/arch/powerpc/mm/kasan/book3s_32.c @@ -10,48 +10,51 @@ int __init kasan_init_region(void *start { unsigned long k_start =3D (unsigned long)kasan_mem_to_shadow(start); unsigned long k_end =3D (unsigned long)kasan_mem_to_shadow(start + size); - unsigned long k_cur =3D k_start; - int k_size =3D k_end - k_start; - int k_size_base =3D 1 << (ffs(k_size) - 1); + unsigned long k_nobat =3D k_start; + unsigned long k_cur; + phys_addr_t phys; int ret; - void *block; =20 - block =3D memblock_alloc(k_size, k_size_base); + while (k_nobat < k_end) { + unsigned int k_size =3D bat_block_size(k_nobat, k_end); + int idx =3D find_free_bat(); + + if (idx =3D=3D -1) + break; + if (k_size < SZ_128K) + break; + phys =3D memblock_phys_alloc_range(k_size, k_size, 0, + MEMBLOCK_ALLOC_ANYWHERE); + if (!phys) + break; =20 - if (block && k_size_base >=3D SZ_128K && k_start =3D=3D ALIGN(k_start, k_= size_base)) { - int shift =3D ffs(k_size - k_size_base); - int k_size_more =3D shift ? 1 << (shift - 1) : 0; - - setbat(-1, k_start, __pa(block), k_size_base, PAGE_KERNEL); - if (k_size_more >=3D SZ_128K) - setbat(-1, k_start + k_size_base, __pa(block) + k_size_base, - k_size_more, PAGE_KERNEL); - if (v_block_mapped(k_start)) - k_cur =3D k_start + k_size_base; - if (v_block_mapped(k_start + k_size_base)) - k_cur =3D k_start + k_size_base + k_size_more; - - update_bats(); + setbat(idx, k_nobat, phys, k_size, PAGE_KERNEL); + k_nobat +=3D k_size; } + if (k_nobat !=3D k_start) + update_bats(); =20 - if (!block) - block =3D memblock_alloc(k_size, PAGE_SIZE); - if (!block) - return -ENOMEM; + if (k_nobat < k_end) { + phys =3D memblock_phys_alloc_range(k_end - k_nobat, PAGE_SIZE, 0, + MEMBLOCK_ALLOC_ANYWHERE); + if (!phys) + return -ENOMEM; + } =20 ret =3D kasan_init_shadow_page_tables(k_start, k_end); if (ret) return ret; =20 - kasan_update_early_region(k_start, k_cur, __pte(0)); + kasan_update_early_region(k_start, k_nobat, __pte(0)); =20 - for (; k_cur < k_end; k_cur +=3D PAGE_SIZE) { + for (k_cur =3D k_nobat; k_cur < k_end; k_cur +=3D PAGE_SIZE) { pmd_t *pmd =3D pmd_off_k(k_cur); - void *va =3D block + k_cur - k_start; - pte_t pte =3D pfn_pte(PHYS_PFN(__pa(va)), PAGE_KERNEL); + pte_t pte =3D pfn_pte(PHYS_PFN(phys + k_cur - k_nobat), PAGE_KERNEL); =20 __set_pte_at(&init_mm, k_cur, pte_offset_kernel(pmd, k_cur), pte, 0); } flush_tlb_kernel_range(k_start, k_end); + memset(kasan_mem_to_shadow(start), 0, k_end - k_start); + return 0; } From nobody Tue Jun 30 03:34:06 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 CBAFAC43217 for ; Mon, 31 Jan 2022 11:11:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344870AbiAaLLu (ORCPT ); Mon, 31 Jan 2022 06:11:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359814AbiAaLH6 (ORCPT ); Mon, 31 Jan 2022 06:07:58 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7265C06175E; Mon, 31 Jan 2022 03:05:00 -0800 (PST) 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 8B4E3B82A6B; Mon, 31 Jan 2022 11:05:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA6B3C340E8; Mon, 31 Jan 2022 11:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627099; bh=Wqg69i/kAkE8iQFF0uMwAU4zMNRtto1xKrShNqHzgBo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B9ER44311phoooudJnqb55xQ5n4MXayNcd6j5QB91qDkM3wip08NFyD/QzE1TpOqA krEaR6svqgM6P3vcUpRDMudeqZa0SHqBy881VkT4RaEMb5COMcjqdgtOkCnN6FV/iM d/9dy3vt8Qm71ZqALZB4DeryKREn0MUet6NHDblQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Erhard Furtner , Christophe Leroy , Michael Ellerman Subject: [PATCH 5.10 041/100] powerpc/32: Fix boot failure with GCC latent entropy plugin Date: Mon, 31 Jan 2022 11:56:02 +0100 Message-Id: <20220131105221.820340276@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Christophe Leroy commit bba496656a73fc1d1330b49c7f82843836e9feb1 upstream. Boot fails with GCC latent entropy plugin enabled. This is due to early boot functions trying to access 'latent_entropy' global data while the kernel is not relocated at its final destination yet. As there is no way to tell GCC to use PTRRELOC() to access it, disable latent entropy plugin in early_32.o and feature-fixups.o and code-patching.o Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Cc: stable@vger.kernel.org # v4.9+ Reported-by: Erhard Furtner Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D215217 Link: https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.16= 40178426.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/lib/Makefile | 3 +++ 2 files changed, 4 insertions(+) --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -11,6 +11,7 @@ CFLAGS_prom_init.o +=3D -fPIC CFLAGS_btext.o +=3D -fPIC endif =20 +CFLAGS_early_32.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_cputable.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_prom_init.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_btext.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -19,6 +19,9 @@ CFLAGS_code-patching.o +=3D -DDISABLE_BRAN CFLAGS_feature-fixups.o +=3D -DDISABLE_BRANCH_PROFILING endif =20 +CFLAGS_code-patching.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) +CFLAGS_feature-fixups.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) + obj-y +=3D alloc.o code-patching.o feature-fixups.o pmem.o inst.o test_cod= e-patching.o =20 ifndef CONFIG_KASAN From nobody Tue Jun 30 03:34:06 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 7DE67C43217 for ; Mon, 31 Jan 2022 11:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376393AbiAaLIX (ORCPT ); Mon, 31 Jan 2022 06:08:23 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51960 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359210AbiAaLFE (ORCPT ); Mon, 31 Jan 2022 06:05:04 -0500 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 6AE20B82A31; Mon, 31 Jan 2022 11:05:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFD11C340E8; Mon, 31 Jan 2022 11:05:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627102; bh=qPmn2951N6S0rKBmkYyFf7WnPt8+8/bb8blm2+jhRxw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rq4JaleEY6Rh9AwcviYa7bBg8cSaBNCErPiHOnQkkhAPxCsEmJiKGIC7XxvyFur2w LQDuMxJZRWqUFEjffM+Uxke8OYGwxijylBCRIczEqzJYJFdcs63ZB0Yc9R8Je6u9mO 9isNDtCiIANc9pt8G8vh3e8J89WSUgbqaiW/eLsA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arkadiusz Kubalewski , Jedrzej Jagielski , Gurucharan G , Tony Nguyen Subject: [PATCH 5.10 042/100] i40e: Increase delay to 1 s after global EMP reset Date: Mon, 31 Jan 2022 11:56:03 +0100 Message-Id: <20220131105221.852233473@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jedrzej Jagielski commit 9b13bd53134c9ddd544a790125199fdbdb505e67 upstream. Recently simplified i40e_rebuild causes that FW sometimes is not ready after NVM update, the ping does not return. Increase the delay in case of EMP reset. Old delay of 300 ms was introduced for specific cards for 710 series. Now it works for all the cards and delay was increased. Fixes: 1fa51a650e1d ("i40e: Add delay after EMP reset for firmware to recov= er") Signed-off-by: Arkadiusz Kubalewski Signed-off-by: Jedrzej Jagielski Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/intel/i40e/i40e_main.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -10130,15 +10130,9 @@ static void i40e_rebuild(struct i40e_pf } i40e_get_oem_version(&pf->hw); =20 - if (test_bit(__I40E_EMP_RESET_INTR_RECEIVED, pf->state) && - ((hw->aq.fw_maj_ver =3D=3D 4 && hw->aq.fw_min_ver <=3D 33) || - hw->aq.fw_maj_ver < 4) && hw->mac.type =3D=3D I40E_MAC_XL710) { - /* The following delay is necessary for 4.33 firmware and older - * to recover after EMP reset. 200 ms should suffice but we - * put here 300 ms to be sure that FW is ready to operate - * after reset. - */ - mdelay(300); + if (test_and_clear_bit(__I40E_EMP_RESET_INTR_RECEIVED, pf->state)) { + /* The following delay is necessary for firmware update. */ + mdelay(1000); } =20 /* re-verify the eeprom if we just had an EMP reset */ From nobody Tue Jun 30 03:34:06 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 A39E0C433FE for ; Mon, 31 Jan 2022 11:07:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358754AbiAaLHH (ORCPT ); Mon, 31 Jan 2022 06:07:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358544AbiAaLDr (ORCPT ); Mon, 31 Jan 2022 06:03:47 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8551FC06175A; Mon, 31 Jan 2022 03:03:20 -0800 (PST) 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 25C8060EFC; Mon, 31 Jan 2022 11:03:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 105AFC340E8; Mon, 31 Jan 2022 11:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626999; bh=amGVSO9RPBdgzcrLD4x0rtA3gTc2dl8NhNyx3VF3Dzg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m+OA2pYT2rUprnSt2ABtLi2vfyIhoFKXq57WHm8z/dL0fXAgHjQCVzFQWApZpG5fj kn2Y3IHFwHN6vEX0cZHQgVW8BgyujfIdA2UIpmfd5YS7aY97gjzDFLIRRTjNlLTCsX 9VFIiOZ/g+MKg0EwEdQF2owE1qHapc1T6VKZTEtc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jaroslaw Gawin , Slawomir Laba , Jedrzej Jagielski , Konrad Jankowski , Tony Nguyen Subject: [PATCH 5.10 043/100] i40e: Fix issue when maximum queues is exceeded Date: Mon, 31 Jan 2022 11:56:04 +0100 Message-Id: <20220131105221.882253685@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jedrzej Jagielski commit d701658a50a471591094b3eb3961b4926cc8f104 upstream. Before this patch VF interface vanished when maximum queue number was exceeded. Driver tried to add next queues even if there was not enough space. PF sent incorrect number of queues to the VF when there were not enough of them. Add an additional condition introduced to check available space in 'qp_pile' before proceeding. This condition makes it impossible to add queues if they number is greater than the number resulting from available space. Also add the search for free space in PF queue pair piles. Without this patch VF interfaces are not seen when available space for queues has been exceeded and following logs appears permanently in dmesg: "Unable to get VF config (-32)". "VF 62 failed opcode 3, retval: -5" "Unable to get VF config due to PF error condition, not retrying" Fixes: 7daa6bf3294e ("i40e: driver core headers") Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Jaroslaw Gawin Signed-off-by: Slawomir Laba Signed-off-by: Jedrzej Jagielski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/intel/i40e/i40e.h | 1=20 drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ---- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 59 ++++++++++++++++= +++++ 3 files changed, 61 insertions(+), 13 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -172,7 +172,6 @@ enum i40e_interrupt_policy { =20 struct i40e_lump_tracking { u16 num_entries; - u16 search_hint; u16 list[0]; #define I40E_PILE_VALID_BIT 0x8000 #define I40E_IWARP_IRQ_PILE_ID (I40E_PILE_VALID_BIT - 2) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -195,10 +195,6 @@ int i40e_free_virt_mem_d(struct i40e_hw * @id: an owner id to stick on the items assigned * * Returns the base item index of the lump, or negative for error - * - * The search_hint trick and lack of advanced fit-finding only work - * because we're highly likely to have all the same size lump requests. - * Linear search time and any fragmentation should be minimal. **/ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pi= le, u16 needed, u16 id) @@ -213,8 +209,7 @@ static int i40e_get_lump(struct i40e_pf return -EINVAL; } =20 - /* start the linear search with an imperfect hint */ - i =3D pile->search_hint; + i =3D 0; while (i < pile->num_entries) { /* skip already allocated entries */ if (pile->list[i] & I40E_PILE_VALID_BIT) { @@ -233,7 +228,6 @@ static int i40e_get_lump(struct i40e_pf for (j =3D 0; j < needed; j++) pile->list[i+j] =3D id | I40E_PILE_VALID_BIT; ret =3D i; - pile->search_hint =3D i + j; break; } =20 @@ -256,7 +250,7 @@ static int i40e_put_lump(struct i40e_lum { int valid_id =3D (id | I40E_PILE_VALID_BIT); int count =3D 0; - int i; + u16 i; =20 if (!pile || index >=3D pile->num_entries) return -EINVAL; @@ -268,8 +262,6 @@ static int i40e_put_lump(struct i40e_lum count++; } =20 - if (count && index < pile->search_hint) - pile->search_hint =3D index; =20 return count; } @@ -11321,7 +11313,6 @@ static int i40e_init_interrupt_scheme(st return -ENOMEM; =20 pf->irq_pile->num_entries =3D vectors; - pf->irq_pile->search_hint =3D 0; =20 /* track first vector for misc interrupts, ignore return */ (void)i40e_get_lump(pf, pf->irq_pile, 1, I40E_PILE_VALID_BIT - 1); @@ -12124,7 +12115,6 @@ static int i40e_sw_init(struct i40e_pf * goto sw_init_done; } pf->qp_pile->num_entries =3D pf->hw.func_caps.num_tx_qp; - pf->qp_pile->search_hint =3D 0; =20 pf->tx_timeout_recovery_level =3D 1; =20 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -2564,6 +2564,59 @@ error_param: } =20 /** + * i40e_check_enough_queue - find big enough queue number + * @vf: pointer to the VF info + * @needed: the number of items needed + * + * Returns the base item index of the queue, or negative for error + **/ +static int i40e_check_enough_queue(struct i40e_vf *vf, u16 needed) +{ + unsigned int i, cur_queues, more, pool_size; + struct i40e_lump_tracking *pile; + struct i40e_pf *pf =3D vf->pf; + struct i40e_vsi *vsi; + + vsi =3D pf->vsi[vf->lan_vsi_idx]; + cur_queues =3D vsi->alloc_queue_pairs; + + /* if current allocated queues are enough for need */ + if (cur_queues >=3D needed) + return vsi->base_queue; + + pile =3D pf->qp_pile; + if (cur_queues > 0) { + /* if the allocated queues are not zero + * just check if there are enough queues for more + * behind the allocated queues. + */ + more =3D needed - cur_queues; + for (i =3D vsi->base_queue + cur_queues; + i < pile->num_entries; i++) { + if (pile->list[i] & I40E_PILE_VALID_BIT) + break; + + if (more-- =3D=3D 1) + /* there is enough */ + return vsi->base_queue; + } + } + + pool_size =3D 0; + for (i =3D 0; i < pile->num_entries; i++) { + if (pile->list[i] & I40E_PILE_VALID_BIT) { + pool_size =3D 0; + continue; + } + if (needed <=3D ++pool_size) + /* there is enough */ + return i; + } + + return -ENOMEM; +} + +/** * i40e_vc_request_queues_msg * @vf: pointer to the VF info * @msg: pointer to the msg buffer @@ -2597,6 +2650,12 @@ static int i40e_vc_request_queues_msg(st req_pairs - cur_pairs, pf->queues_left); vfres->num_queue_pairs =3D pf->queues_left + cur_pairs; + } else if (i40e_check_enough_queue(vf, req_pairs) < 0) { + dev_warn(&pf->pdev->dev, + "VF %d requested %d more queues, but there is not enough for it.\n", + vf->vf_id, + req_pairs - cur_pairs); + vfres->num_queue_pairs =3D cur_pairs; } else { /* successful request */ vf->num_req_queues =3D req_pairs; From nobody Tue Jun 30 03:34:06 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 CCE20C433EF for ; Mon, 31 Jan 2022 11:05:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359495AbiAaLFn (ORCPT ); Mon, 31 Jan 2022 06:05:43 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51356 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358534AbiAaLDY (ORCPT ); Mon, 31 Jan 2022 06:03:24 -0500 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 98124B82A59; Mon, 31 Jan 2022 11:03:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD647C340F3; Mon, 31 Jan 2022 11:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627002; bh=/XUiWIQai6L56J/l4Q8HMbWzlCJaHrOsjheH+Cti7XA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BwaQEfchULiD8cE3RT9mvBsmPTFn8Ot9E3KotTBQTlj2P0/AXGbd1Om/BRKxxfufm UCeF9DP748q80rpbi6fDcTatu2jMt3j9sLQFInmaHxxXs7tYQxAJafzJNgWaZuJuuP b8kpn+8U99jqXSOPL7lMMYpMHfXsoqyTWZ2VXRek= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sylwester Dziedziuch , Mateusz Palczewski , Maciej Fijalkowski , Kiran Bhandare , Tony Nguyen Subject: [PATCH 5.10 044/100] i40e: Fix queues reservation for XDP Date: Mon, 31 Jan 2022 11:56:05 +0100 Message-Id: <20220131105221.914432799@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Sylwester Dziedziuch commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream. When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI. Fixes: 41c445ff0f48 ("i40e: main driver core") Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action") Signed-off-by: Sylwester Dziedziuch Signed-off-by: Mateusz Palczewski Reviewed-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -209,6 +209,20 @@ static int i40e_get_lump(struct i40e_pf return -EINVAL; } =20 + /* Allocate last queue in the pile for FDIR VSI queue + * so it doesn't fragment the qp_pile + */ + if (pile =3D=3D pf->qp_pile && pf->vsi[id]->type =3D=3D I40E_VSI_FDIR) { + if (pile->list[pile->num_entries - 1] & I40E_PILE_VALID_BIT) { + dev_err(&pf->pdev->dev, + "Cannot allocate queue %d for I40E_VSI_FDIR\n", + pile->num_entries - 1); + return -ENOMEM; + } + pile->list[pile->num_entries - 1] =3D id | I40E_PILE_VALID_BIT; + return pile->num_entries - 1; + } + i =3D 0; while (i < pile->num_entries) { /* skip already allocated entries */ From nobody Tue Jun 30 03:34:06 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 5FAE5C433EF for ; Mon, 31 Jan 2022 11:05:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359556AbiAaLF4 (ORCPT ); Mon, 31 Jan 2022 06:05:56 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51434 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358711AbiAaLD2 (ORCPT ); Mon, 31 Jan 2022 06:03:28 -0500 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 D2D12B82A5E; Mon, 31 Jan 2022 11:03:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5368C340E8; Mon, 31 Jan 2022 11:03:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627005; bh=RfohiMaJGLb6M+sTWyHIxh/F9JRrZ2rOThUjK4zLoHk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=b2DQVEsdVv3Jx74ZLfvORpaSldTO/NbOmEyvz7ZXjW/cYiEjW3sB9M5wIgq/1hrDh zrWIBGdN/TmNaXQdOK3DjUBZUYCG4MaIocshjCUoEIdM8OCRrHdY9B2GpHd+mM3CMo R7bOC3lfHPvY0or3SjaeZNGPee4a34vJQxjitkoA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Grzegorz Szczurek , Karen Sornek , Konrad Jankowski , Tony Nguyen Subject: [PATCH 5.10 045/100] i40e: Fix for failed to init adminq while VF reset Date: Mon, 31 Jan 2022 11:56:06 +0100 Message-Id: <20220131105221.957317332@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Karen Sornek commit 0f344c8129a5337dae50e31b817dd50a60ff238c upstream. Fix for failed to init adminq: -53 while VF is resetting via MAC address changing procedure. Added sync module to avoid reading deadbeef value in reinit adminq during software reset. Without this patch it is possible to trigger VF reset procedure during reinit adminq. This resulted in an incorrect reading of value from the AQP registers and generated the -53 error. Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface") Signed-off-by: Grzegorz Szczurek Signed-off-by: Karen Sornek Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/intel/i40e/i40e_register.h | 3 + drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 44 ++++++++++++++++= ++++- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 1=20 3 files changed, 46 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_register.h +++ b/drivers/net/ethernet/intel/i40e/i40e_register.h @@ -279,6 +279,9 @@ #define I40E_VFINT_DYN_CTLN(_INTVF) (0x00024800 + ((_INTVF) * 4)) /* _i=3D= 0...511 */ /* Reset: VFR */ #define I40E_VFINT_DYN_CTLN_CLEARPBA_SHIFT 1 #define I40E_VFINT_DYN_CTLN_CLEARPBA_MASK I40E_MASK(0x1, I40E_VFINT_DYN_CT= LN_CLEARPBA_SHIFT) +#define I40E_VFINT_ICR0_ADMINQ_SHIFT 30 +#define I40E_VFINT_ICR0_ADMINQ_MASK I40E_MASK(0x1, I40E_VFINT_ICR0_ADMINQ_= SHIFT) +#define I40E_VFINT_ICR0_ENA(_VF) (0x0002C000 + ((_VF) * 4)) /* _i=3D0...12= 7 */ /* Reset: CORER */ #define I40E_VPINT_AEQCTL(_VF) (0x0002B800 + ((_VF) * 4)) /* _i=3D0...127 = */ /* Reset: CORER */ #define I40E_VPINT_AEQCTL_MSIX_INDX_SHIFT 0 #define I40E_VPINT_AEQCTL_ITR_INDX_SHIFT 11 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -1324,6 +1324,32 @@ static i40e_status i40e_config_vf_promis } =20 /** + * i40e_sync_vfr_reset + * @hw: pointer to hw struct + * @vf_id: VF identifier + * + * Before trigger hardware reset, we need to know if no other process has + * reserved the hardware for any reset operations. This check is done by + * examining the status of the RSTAT1 register used to signal the reset. + **/ +static int i40e_sync_vfr_reset(struct i40e_hw *hw, int vf_id) +{ + u32 reg; + int i; + + for (i =3D 0; i < I40E_VFR_WAIT_COUNT; i++) { + reg =3D rd32(hw, I40E_VFINT_ICR0_ENA(vf_id)) & + I40E_VFINT_ICR0_ADMINQ_MASK; + if (reg) + return 0; + + usleep_range(100, 200); + } + + return -EAGAIN; +} + +/** * i40e_trigger_vf_reset * @vf: pointer to the VF structure * @flr: VFLR was issued or not @@ -1337,9 +1363,11 @@ static void i40e_trigger_vf_reset(struct struct i40e_pf *pf =3D vf->pf; struct i40e_hw *hw =3D &pf->hw; u32 reg, reg_idx, bit_idx; + bool vf_active; + u32 radq; =20 /* warn the VF */ - clear_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states); + vf_active =3D test_and_clear_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states); =20 /* Disable VF's configuration API during reset. The flag is re-enabled * in i40e_alloc_vf_res(), when it's safe again to access VF's VSI. @@ -1353,7 +1381,19 @@ static void i40e_trigger_vf_reset(struct * just need to clean up, so don't hit the VFRTRIG register. */ if (!flr) { - /* reset VF using VPGEN_VFRTRIG reg */ + /* Sync VFR reset before trigger next one */ + radq =3D rd32(hw, I40E_VFINT_ICR0_ENA(vf->vf_id)) & + I40E_VFINT_ICR0_ADMINQ_MASK; + if (vf_active && !radq) + /* waiting for finish reset by virtual driver */ + if (i40e_sync_vfr_reset(hw, vf->vf_id)) + dev_info(&pf->pdev->dev, + "Reset VF %d never finished\n", + vf->vf_id); + + /* Reset VF using VPGEN_VFRTRIG reg. It is also setting + * in progress state in rstat1 register. + */ reg =3D rd32(hw, I40E_VPGEN_VFRTRIG(vf->vf_id)); reg |=3D I40E_VPGEN_VFRTRIG_VFSWR_MASK; wr32(hw, I40E_VPGEN_VFRTRIG(vf->vf_id), reg); --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h @@ -19,6 +19,7 @@ #define I40E_MAX_VF_PROMISC_FLAGS 3 =20 #define I40E_VF_STATE_WAIT_COUNT 20 +#define I40E_VFR_WAIT_COUNT 100 =20 /* Various queue ctrls */ enum i40e_queue_ctrl { From nobody Tue Jun 30 03:34:06 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 F2BEEC433FE for ; Mon, 31 Jan 2022 11:06:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359565AbiAaLGC (ORCPT ); Mon, 31 Jan 2022 06:06:02 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:37790 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358746AbiAaLD3 (ORCPT ); Mon, 31 Jan 2022 06:03:29 -0500 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 CAE3860B28; Mon, 31 Jan 2022 11:03:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCFE0C36AE7; Mon, 31 Jan 2022 11:03:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627008; bh=LBjMIYSFdfwWonFoziv0O80iq9570hobhBy3lRFZDNg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g2EqypvJR+YTcPlLyAjYlpGGJcnJuwIr/XtkjJhFnXHNxIzYTf5oM3s/gelPmdcIF PQd+v9EtIfqK63jScW1+veTC3Cy+jbONAfhC/FZ09p/yc0TICXWELQpO5zveMUnmUW gh6KjezWh781V9VllokiwGRwfWA9TzEaZJOWAylc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joe Damato , kernel test robot , Gurucharan G , Tony Nguyen Subject: [PATCH 5.10 046/100] i40e: fix unsigned stat widths Date: Mon, 31 Jan 2022 11:56:07 +0100 Message-Id: <20220131105221.988803752@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Joe Damato commit 3b8428b84539c78fdc8006c17ebd25afd4722d51 upstream. Change i40e_update_vsi_stats and struct i40e_vsi to use u64 fields to match the width of the stats counters in struct i40e_rx_queue_stats. Update debugfs code to use the correct format specifier for u64. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Joe Damato Reported-by: kernel test robot Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/intel/i40e/i40e.h | 8 ++++---- drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -754,12 +754,12 @@ struct i40e_vsi { struct rtnl_link_stats64 net_stats_offsets; struct i40e_eth_stats eth_stats; struct i40e_eth_stats eth_stats_offsets; - u32 tx_restart; - u32 tx_busy; + u64 tx_restart; + u64 tx_busy; u64 tx_linearize; u64 tx_force_wb; - u32 rx_buf_failed; - u32 rx_page_failed; + u64 rx_buf_failed; + u64 rx_page_failed; =20 /* These are containers of ring pointers, allocated at run-time */ struct i40e_ring **rx_rings; --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c @@ -240,7 +240,7 @@ static void i40e_dbg_dump_vsi_seid(struc (unsigned long int)vsi->net_stats_offsets.rx_compressed, (unsigned long int)vsi->net_stats_offsets.tx_compressed); dev_info(&pf->pdev->dev, - " tx_restart =3D %d, tx_busy =3D %d, rx_buf_failed =3D %d, rx_page_f= ailed =3D %d\n", + " tx_restart =3D %llu, tx_busy =3D %llu, rx_buf_failed =3D %llu, rx_= page_failed =3D %llu\n", vsi->tx_restart, vsi->tx_busy, vsi->rx_buf_failed, vsi->rx_page_failed); rcu_read_lock(); --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -777,9 +777,9 @@ static void i40e_update_vsi_stats(struct struct rtnl_link_stats64 *ns; /* netdev stats */ struct i40e_eth_stats *oes; struct i40e_eth_stats *es; /* device's eth stats */ - u32 tx_restart, tx_busy; + u64 tx_restart, tx_busy; struct i40e_ring *p; - u32 rx_page, rx_buf; + u64 rx_page, rx_buf; u64 bytes, packets; unsigned int start; u64 tx_linearize; From nobody Tue Jun 30 03:34:06 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 38E91C4332F for ; Mon, 31 Jan 2022 11:06:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359130AbiAaLGQ (ORCPT ); Mon, 31 Jan 2022 06:06:16 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51578 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358874AbiAaLDd (ORCPT ); Mon, 31 Jan 2022 06:03:33 -0500 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 74B89B82A63; Mon, 31 Jan 2022 11:03:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2EC2C340E8; Mon, 31 Jan 2022 11:03:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627011; bh=TU0p7qkeeXgylcewjx6eQ6XV10JW5uxp5Lh3IIbzWWM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rFSVR5CNBgu6YCrVA/RHuYh4rwwQC4ou85D5SQYbD0c841tSU3jjq8sIJJf2Cn2/C +ZvW6Ap1Q2XLailHvMuUhlMdhzfhaWNj/cENN7hUUe48YLQ9oQRVHHyDFRyabBH2x5 6aMRcJZxjkM6Vp9nDJ+GWJAGkMu7CmjcHGlGpgKg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linyu Yuan Subject: [PATCH 5.10 047/100] usb: roles: fix include/linux/usb/role.h compile issue Date: Mon, 31 Jan 2022 11:56:08 +0100 Message-Id: <20220131105222.023753472@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Linyu Yuan commit 945c37ed564770c78dfe6b9f08bed57a1b4e60ef upstream. when CONFIG_USB_ROLE_SWITCH is not defined, add usb_role_switch_find_by_fwnode() definition which return NULL. Fixes: c6919d5e0cd1 ("usb: roles: Add usb_role_switch_find_by_fwnode()") Signed-off-by: Linyu Yuan Link: https://lore.kernel.org/r/1641818608-25039-1-git-send-email-quic_liny= yuan@quicinc.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/usb/role.h | 6 ++++++ 1 file changed, 6 insertions(+) --- a/include/linux/usb/role.h +++ b/include/linux/usb/role.h @@ -91,6 +91,12 @@ fwnode_usb_role_switch_get(struct fwnode static inline void usb_role_switch_put(struct usb_role_switch *sw) { } =20 static inline struct usb_role_switch * +usb_role_switch_find_by_fwnode(const struct fwnode_handle *fwnode) +{ + return NULL; +} + +static inline struct usb_role_switch * usb_role_switch_register(struct device *parent, const struct usb_role_switch_desc *desc) { From nobody Tue Jun 30 03:34:06 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 AFF36C433F5 for ; Mon, 31 Jan 2022 11:07:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359200AbiAaLHl (ORCPT ); Mon, 31 Jan 2022 06:07:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359083AbiAaLET (ORCPT ); Mon, 31 Jan 2022 06:04:19 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B858C061741; Mon, 31 Jan 2022 03:03:35 -0800 (PST) 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 D1A9860B98; Mon, 31 Jan 2022 11:03:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF4B4C340EE; Mon, 31 Jan 2022 11:03:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627014; bh=MU457nlaBzqUkUiehB3MbrbuxJNSlNvVyeoL3/f57qM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dQ1M0W6ykEpC8cGMHUeD4b+myn5Npg3lFveKgJStan3VgITN0Zk6UqoIY8eF7jpwZ HE87ySZKH0/aY6+K/ODU7TLvfsXi1+rr+p1YjsZJ1rOqCGf2wNwAUfoyvsgCkMv7+n yte5mkx0OTcs5uk6b9q5p4sU8omzcF0Rq/+JN4bE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sujit Kautkar , Matthias Kaehlcke , Mathieu Poirier , Bjorn Andersson , Stephen Boyd Subject: [PATCH 5.10 048/100] rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev Date: Mon, 31 Jan 2022 11:56:09 +0100 Message-Id: <20220131105222.056104924@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Sujit Kautkar commit b7fb2dad571d1e21173c06cef0bced77b323990a upstream. struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below. [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list= hint: delayed_work_timer_fn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_prin= t_object+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif= _hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vma= lloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_= soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B = 5.4.163-lockdep #26 [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobject_delayed_cleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc : debug_print_object+0x13c/0x1b0 [ 93.744890] lr : debug_print_object+0x13c/0x1b0 [ 93.749555] sp : ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [ 93.835104] Call trace: [ 93.837644] debug_print_object+0x13c/0x1b0 [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0 [ 93.846987] debug_check_no_obj_freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.876948] process_one_work+0x578/0x92c [ 93.881086] worker_thread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [ 93.888303] ret_from_fork+0x10/0x18 The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Signed-off-by: Sujit Kautkar Signed-off-by: Matthias Kaehlcke Reviewed-by: Mathieu Poirier Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220110104706.v6.1.Iaac908f3e3149a89190ce0= 06ba166e2d3fd247a3@changeid Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/rpmsg/rpmsg_char.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/drivers/rpmsg/rpmsg_char.c +++ b/drivers/rpmsg/rpmsg_char.c @@ -458,7 +458,6 @@ static void rpmsg_ctrldev_release_device =20 ida_simple_remove(&rpmsg_ctrl_ida, dev->id); ida_simple_remove(&rpmsg_minor_ida, MINOR(dev->devt)); - cdev_del(&ctrldev->cdev); kfree(ctrldev); } =20 @@ -493,19 +492,13 @@ static int rpmsg_chrdev_probe(struct rpm dev->id =3D ret; dev_set_name(&ctrldev->dev, "rpmsg_ctrl%d", ret); =20 - ret =3D cdev_add(&ctrldev->cdev, dev->devt, 1); + ret =3D cdev_device_add(&ctrldev->cdev, &ctrldev->dev); if (ret) goto free_ctrl_ida; =20 /* We can now rely on the release function for cleanup */ dev->release =3D rpmsg_ctrldev_release_device; =20 - ret =3D device_add(dev); - if (ret) { - dev_err(&rpdev->dev, "device_add failed: %d\n", ret); - put_device(dev); - } - dev_set_drvdata(&rpdev->dev, ctrldev); =20 return ret; @@ -531,7 +524,7 @@ static void rpmsg_chrdev_remove(struct r if (ret) dev_warn(&rpdev->dev, "failed to nuke endpoints: %d\n", ret); =20 - device_del(&ctrldev->dev); + cdev_device_del(&ctrldev->cdev, &ctrldev->dev); put_device(&ctrldev->dev); } =20 From nobody Tue Jun 30 03:34:06 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 59BC3C4332F for ; Mon, 31 Jan 2022 11:06:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359639AbiAaLGV (ORCPT ); Mon, 31 Jan 2022 06:06:21 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38048 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358952AbiAaLDl (ORCPT ); Mon, 31 Jan 2022 06:03:41 -0500 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 212F860ECF; Mon, 31 Jan 2022 11:03:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCC8EC340E8; Mon, 31 Jan 2022 11:03:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627017; bh=KjW/7eKgfTS+OsuhUUQ7UNW+mmchzEGxbUf13qm8IFo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EHbROLfR+m3Y7UA6lMDd4/nr46dtUDa+Q7+DZFlhQU6hVy0S3fLPUImTq60OBPg5C BVNqqqLGAqeuo7t8py5MXtFlhsWgRwmU85LRDS3c9H8kFdbn66ligVkGH1lGmfqR/P bQrtvZs7WPsxq6CftKA6Jx3gz9i5lvvtKVr09DJA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bjorn Andersson , Matthias Kaehlcke , Mathieu Poirier , Stephen Boyd Subject: [PATCH 5.10 049/100] rpmsg: char: Fix race between the release of rpmsg_eptdev and cdev Date: Mon, 31 Jan 2022 11:56:10 +0100 Message-Id: <20220131105222.090505239@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Matthias Kaehlcke commit 7a534ae89e34e9b51acb5a63dd0f88308178b46a upstream. struct rpmsg_eptdev contains a struct cdev. The current code frees the rpmsg_eptdev struct in rpmsg_eptdev_destroy(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_eptdev could be freed before the cdev is entirely released. The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Suggested-by: Bjorn Andersson Signed-off-by: Matthias Kaehlcke Reviewed-by: Mathieu Poirier Reviewed-by: Stephen Boyd Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220110104706.v6.2.Idde68b05b88d4a2e6e5476= 6c653f3a6d9e419ce6@changeid Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/rpmsg/rpmsg_char.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/drivers/rpmsg/rpmsg_char.c +++ b/drivers/rpmsg/rpmsg_char.c @@ -92,7 +92,7 @@ static int rpmsg_eptdev_destroy(struct d /* wake up any blocked readers */ wake_up_interruptible(&eptdev->readq); =20 - device_del(&eptdev->dev); + cdev_device_del(&eptdev->cdev, &eptdev->dev); put_device(&eptdev->dev); =20 return 0; @@ -332,7 +332,6 @@ static void rpmsg_eptdev_release_device( =20 ida_simple_remove(&rpmsg_ept_ida, dev->id); ida_simple_remove(&rpmsg_minor_ida, MINOR(eptdev->dev.devt)); - cdev_del(&eptdev->cdev); kfree(eptdev); } =20 @@ -377,19 +376,13 @@ static int rpmsg_eptdev_create(struct rp dev->id =3D ret; dev_set_name(dev, "rpmsg%d", ret); =20 - ret =3D cdev_add(&eptdev->cdev, dev->devt, 1); + ret =3D cdev_device_add(&eptdev->cdev, &eptdev->dev); if (ret) goto free_ept_ida; =20 /* We can now rely on the release function for cleanup */ dev->release =3D rpmsg_eptdev_release_device; =20 - ret =3D device_add(dev); - if (ret) { - dev_err(dev, "device_add failed: %d\n", ret); - put_device(dev); - } - return ret; =20 free_ept_ida: From nobody Tue Jun 30 03:34:06 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 419C9C433EF for ; Mon, 31 Jan 2022 11:10:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359768AbiAaLHx (ORCPT ); Mon, 31 Jan 2022 06:07:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359102AbiAaLEW (ORCPT ); Mon, 31 Jan 2022 06:04:22 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B917C06177B; Mon, 31 Jan 2022 03:03:43 -0800 (PST) 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 EBB33B82A31; Mon, 31 Jan 2022 11:03:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 133D0C340E8; Mon, 31 Jan 2022 11:03:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627020; bh=GVA7Ng45PZAYfYgqxoXRx2UGssnU9LrYy6Y6QmtM/x8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R7yfnwFjfMUB9TlvIol4dkFaYpAy+VW96xU9ck2jSJNUVf82lSE1OTflaY4DnAxDw TcG/yBi6GPp8fR3jH2yKoBWCpCFbEA0Co1JebG5kVM6uAwlrYhHSZNrFjPJDlk23fT hbELPFKWVkUXiLN/V+0kCyvm0JA6G0brn7V1krbM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guangwu Zhang , Maurizio Lombardi , John Meneghini , "Martin K. Petersen" Subject: [PATCH 5.10 050/100] scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put() Date: Mon, 31 Jan 2022 11:56:11 +0100 Message-Id: <20220131105222.122696253@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: John Meneghini commit 847f9ea4c5186fdb7b84297e3eeed9e340e83fce upstream. The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early. Replace the fcoe_port's destroy_work queue. It's not needed. The problem is easily reproducible with the following steps. Example: $ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_rem= ove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc = bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainte= d 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_f= c] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f= 6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 000000000= 0000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c158= 6cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c= 15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c148= 6326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 000000000= 0000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlG= S:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 000000000= 00606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? set_kthread_struct+0x40/0x40 [ 584.662909] ret_from_fork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]--- Link: https://lore.kernel.org/r/20220115040044.1013475-1-jmeneghi@redhat.com Fixes: 0cbf32e1681d ("[SCSI] bnx2fc: Avoid calling bnx2fc_if_destroy with u= nnecessary locks") Tested-by: Guangwu Zhang Co-developed-by: Maurizio Lombardi Signed-off-by: Maurizio Lombardi Signed-off-by: John Meneghini Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c @@ -80,7 +80,7 @@ static int bnx2fc_bind_pcidev(struct bnx static void bnx2fc_unbind_pcidev(struct bnx2fc_hba *hba); static struct fc_lport *bnx2fc_if_create(struct bnx2fc_interface *interfac= e, struct device *parent, int npiv); -static void bnx2fc_destroy_work(struct work_struct *work); +static void bnx2fc_port_destroy(struct fcoe_port *port); =20 static struct bnx2fc_hba *bnx2fc_hba_lookup(struct net_device *phys_dev); static struct bnx2fc_interface *bnx2fc_interface_lookup(struct net_device @@ -905,9 +905,6 @@ static void bnx2fc_indicate_netevent(voi __bnx2fc_destroy(interface); } mutex_unlock(&bnx2fc_dev_lock); - - /* Ensure ALL destroy work has been completed before return */ - flush_workqueue(bnx2fc_wq); return; =20 default: @@ -1213,8 +1210,8 @@ static int bnx2fc_vport_destroy(struct f mutex_unlock(&n_port->lp_mutex); bnx2fc_free_vport(interface->hba, port->lport); bnx2fc_port_shutdown(port->lport); + bnx2fc_port_destroy(port); bnx2fc_interface_put(interface); - queue_work(bnx2fc_wq, &port->destroy_work); return 0; } =20 @@ -1523,7 +1520,6 @@ static struct fc_lport *bnx2fc_if_create port->lport =3D lport; port->priv =3D interface; port->get_netdev =3D bnx2fc_netdev; - INIT_WORK(&port->destroy_work, bnx2fc_destroy_work); =20 /* Configure fcoe_port */ rc =3D bnx2fc_lport_config(lport); @@ -1651,8 +1647,8 @@ static void __bnx2fc_destroy(struct bnx2 bnx2fc_interface_cleanup(interface); bnx2fc_stop(interface); list_del(&interface->list); + bnx2fc_port_destroy(port); bnx2fc_interface_put(interface); - queue_work(bnx2fc_wq, &port->destroy_work); } =20 /** @@ -1692,15 +1688,12 @@ netdev_err: return rc; } =20 -static void bnx2fc_destroy_work(struct work_struct *work) +static void bnx2fc_port_destroy(struct fcoe_port *port) { - struct fcoe_port *port; struct fc_lport *lport; =20 - port =3D container_of(work, struct fcoe_port, destroy_work); lport =3D port->lport; - - BNX2FC_HBA_DBG(lport, "Entered bnx2fc_destroy_work\n"); + BNX2FC_HBA_DBG(lport, "Entered %s, destroying lport %p\n", __func__, lpor= t); =20 bnx2fc_if_destroy(lport); } @@ -2554,9 +2547,6 @@ static void bnx2fc_ulp_exit(struct cnic_ __bnx2fc_destroy(interface); mutex_unlock(&bnx2fc_dev_lock); =20 - /* Ensure ALL destroy work has been completed before return */ - flush_workqueue(bnx2fc_wq); - bnx2fc_ulp_stop(hba); /* unregister cnic device */ if (test_and_clear_bit(BNX2FC_CNIC_REGISTERED, &hba->reg_with_cnic)) From nobody Tue Jun 30 03:34:06 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 06CD8C433F5 for ; Mon, 31 Jan 2022 11:07:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359258AbiAaLG4 (ORCPT ); Mon, 31 Jan 2022 06:06:56 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38196 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358345AbiAaLDo (ORCPT ); Mon, 31 Jan 2022 06:03:44 -0500 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 29C9E60EDB; Mon, 31 Jan 2022 11:03:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BA59C340E8; Mon, 31 Jan 2022 11:03:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627023; bh=8kwQ4IlCL4lt3evFQMydDkoqm2Wx6KwGPAVive888gE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eLUnr8Z981yUUJiRFgfEuve5y9mbv3d41+TyT6L4JMQXhe5ghtpxjVdT6mMnjyWty AEElYYdY3HmB/fpk71Rpni+LKePYQa3l4hj2abMa6w2BTnhEgQ4/JHGXdkaCCNeuIn 1+arZfQjafGIz0k7FX+PFJgGOiy+pbfHrMLwxr2k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maksym Yaremchuk , Ido Schimmel , Amit Cohen , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 051/100] ipv6_tunnel: Rate limit warning messages Date: Mon, 31 Jan 2022 11:56:12 +0100 Message-Id: <20220131105222.155835649@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Ido Schimmel commit 6cee105e7f2ced596373951d9ea08dacc3883c68 upstream. The warning messages can be invoked from the data path for every packet transmitted through an ip6gre netdev, leading to high CPU utilization. Fix that by rate limiting the messages. Fixes: 09c6bbf090ec ("[IPV6]: Do mandatory IPv6 tunnel endpoint checks in r= ealtime") Reported-by: Maksym Yaremchuk Tested-by: Maksym Yaremchuk Signed-off-by: Ido Schimmel Reviewed-by: Amit Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv6/ip6_tunnel.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1066,14 +1066,14 @@ int ip6_tnl_xmit_ctl(struct ip6_tnl *t, =20 if (unlikely(!ipv6_chk_addr_and_flags(net, laddr, ldev, false, 0, IFA_F_TENTATIVE))) - pr_warn("%s xmit: Local address not yet configured!\n", - p->name); + pr_warn_ratelimited("%s xmit: Local address not yet configured!\n", + p->name); else if (!(p->flags & IP6_TNL_F_ALLOW_LOCAL_REMOTE) && !ipv6_addr_is_multicast(raddr) && unlikely(ipv6_chk_addr_and_flags(net, raddr, ldev, true, 0, IFA_F_TENTATIVE))) - pr_warn("%s xmit: Routing loop! Remote address found on this node!\n", - p->name); + pr_warn_ratelimited("%s xmit: Routing loop! Remote address found on thi= s node!\n", + p->name); else ret =3D 1; rcu_read_unlock(); From nobody Tue Jun 30 03:34:06 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 A5EAEC433F5 for ; Mon, 31 Jan 2022 11:07:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348732AbiAaLHD (ORCPT ); Mon, 31 Jan 2022 06:07:03 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38286 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348380AbiAaLDr (ORCPT ); Mon, 31 Jan 2022 06:03:47 -0500 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 097CE60B2D; Mon, 31 Jan 2022 11:03:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2003C340EE; Mon, 31 Jan 2022 11:03:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627026; bh=K8uS/L0iTWLq7FlRCD2DFohHBclcjVpDwfvTy1cfNPY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ulj/1LH0OJZtY0skTAb9+c3y8cPQkhGSOHFddoKSU5ORTDE5jzjkyB3J2mLBmqIlN GV/V7AzI51DL8C+p/X+tDCbPhrtnRLsqtpEEK/K00NsJ9TUdlqLeqQcCZkidB8crPr cAN0E4t8BVOiGSIjkZHoalNtc4H7cgyCTMzbX4qw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, huangshaobo , Ard Biesheuvel , "Russell King (Oracle)" Subject: [PATCH 5.10 052/100] ARM: 9170/1: fix panic when kasan and kprobe are enabled Date: Mon, 31 Jan 2022 11:56:13 +0100 Message-Id: <20220131105222.189561789@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: sparkhuang commit 8b59b0a53c840921b625378f137e88adfa87647e upstream. arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd =3D ecb46400 [00000090] *pgd=3D2e0fa003, *pmd=3D00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit =3D 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: huangshaobo Acked-by: Ard Biesheuvel Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/arm/probes/kprobes/Makefile | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/arm/probes/kprobes/Makefile +++ b/arch/arm/probes/kprobes/Makefile @@ -1,4 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 +KASAN_SANITIZE_actions-common.o :=3D n +KASAN_SANITIZE_actions-arm.o :=3D n +KASAN_SANITIZE_actions-thumb.o :=3D n obj-$(CONFIG_KPROBES) +=3D core.o actions-common.o checkers-common.o obj-$(CONFIG_ARM_KPROBES_TEST) +=3D test-kprobes.o test-kprobes-objs :=3D test-core.o From nobody Tue Jun 30 03:34:06 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 626A7C433F5 for ; Mon, 31 Jan 2022 11:07:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358905AbiAaLHR (ORCPT ); Mon, 31 Jan 2022 06:07:17 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51878 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358846AbiAaLD4 (ORCPT ); Mon, 31 Jan 2022 06:03:56 -0500 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 A2B9EB82A31; Mon, 31 Jan 2022 11:03:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2780AC340E8; Mon, 31 Jan 2022 11:03:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627032; bh=kz2Lt6zhXS8sxBsfLdzg8w/oWhJ3AggNaq9bxEXj+Cw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vkyi+OQa5agEqtFxYK6408gzreHIzC2Xt4RcZO46+UDaG7ZaGibl4wFAP00dKVnNg 7hspbhmG/HLS7EzGkjjDs7QDj5Y+XtQ6XYQqBA54x33GtQmGhQvb/6X0RcfLSZqCID WrEtXTZM7MCw2S1NEp0FjP2NmHctOZ8cIFJr5jtI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Congyu Liu , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 053/100] net: fix information leakage in /proc/net/ptype Date: Mon, 31 Jan 2022 11:56:14 +0100 Message-Id: <20220131105222.221575774@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Congyu Liu commit 47934e06b65637c88a762d9c98329ae6e3238888 upstream. In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL. Fixes: 2feb27dbe00c ("[NETNS]: Minor information leak via /proc/net/ptype f= ile.") Signed-off-by: Congyu Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/netdevice.h | 1 + net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-) --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -2543,6 +2543,7 @@ struct packet_type { struct net_device *); bool (*id_match)(struct packet_type *ptype, struct sock *sk); + struct net *af_packet_net; void *af_packet_priv; struct list_head list; }; --- a/net/core/net-procfs.c +++ b/net/core/net-procfs.c @@ -263,7 +263,8 @@ static int ptype_seq_show(struct seq_fil =20 if (v =3D=3D SEQ_START_TOKEN) seq_puts(seq, "Type Device Function\n"); - else if (pt->dev =3D=3D NULL || dev_net(pt->dev) =3D=3D seq_file_net(seq)= ) { + else if ((!pt->af_packet_net || net_eq(pt->af_packet_net, seq_file_net(se= q))) && + (!pt->dev || net_eq(dev_net(pt->dev), seq_file_net(seq)))) { if (pt->type =3D=3D htons(ETH_P_ALL)) seq_puts(seq, "ALL "); else --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -1735,6 +1735,7 @@ static int fanout_add(struct sock *sk, s match->prot_hook.dev =3D po->prot_hook.dev; match->prot_hook.func =3D packet_rcv_fanout; match->prot_hook.af_packet_priv =3D match; + match->prot_hook.af_packet_net =3D read_pnet(&match->net); match->prot_hook.id_match =3D match_fanout_group; match->max_num_members =3D args->max_num_members; list_add(&match->list, &fanout_list); @@ -3323,6 +3324,7 @@ static int packet_create(struct net *net po->prot_hook.func =3D packet_rcv_spkt; =20 po->prot_hook.af_packet_priv =3D sk; + po->prot_hook.af_packet_net =3D sock_net(sk); =20 if (proto) { po->prot_hook.type =3D proto; From nobody Tue Jun 30 03:34:06 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 9F1B5C43219 for ; Mon, 31 Jan 2022 11:10:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376305AbiAaLIK (ORCPT ); Mon, 31 Jan 2022 06:08:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359118AbiAaLEh (ORCPT ); Mon, 31 Jan 2022 06:04:37 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B41EC0613A4; Mon, 31 Jan 2022 03:03:58 -0800 (PST) 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 ECC0AB82A69; Mon, 31 Jan 2022 11:03:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0809AC340E8; Mon, 31 Jan 2022 11:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627035; bh=7E9ERDVZttx1BEkbi9cB6zU2U3oaHnyBYoXJvVBibGo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iPNCP81vSuCz/XLEFU5+4FtLI3B9Qtl6NTO/RthxvP9HovuogNZ/Lv6Hb4hP5KtEg Rxursf1dPB2FjT9X87pUP/QX7T1pytUjlAszfUm1VMIaF6YtJPflj16DKTr8Eo0iyN qFNfK40YGVjnt77sXbuU60Bpt2IhneY7861TD5MI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck Subject: [PATCH 5.10 054/100] hwmon: (lm90) Mark alert as broken for MAX6646/6647/6649 Date: Mon, 31 Jan 2022 11:56:15 +0100 Message-Id: <20220131105222.254828909@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Guenter Roeck commit f614629f9c1080dcc844a8430e3fb4c37ebbf05d upstream. Experiments with MAX6646 and MAX6648 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -394,7 +394,7 @@ static const struct lm90_params lm90_par .max_convrate =3D 9, }, [max6646] =3D { - .flags =3D LM90_HAVE_CRIT, + .flags =3D LM90_HAVE_CRIT | LM90_HAVE_BROKEN_ALERT, .alert_alarms =3D 0x7c, .max_convrate =3D 6, .reg_local_ext =3D MAX6657_REG_R_LOCAL_TEMPL, From nobody Tue Jun 30 03:34:06 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 09C24C433F5 for ; Mon, 31 Jan 2022 11:07:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358987AbiAaLHX (ORCPT ); Mon, 31 Jan 2022 06:07:23 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51960 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358859AbiAaLEB (ORCPT ); Mon, 31 Jan 2022 06:04:01 -0500 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 E5C81B82A62; Mon, 31 Jan 2022 11:03:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A983C340EF; Mon, 31 Jan 2022 11:03:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627038; bh=0EFvWCyzPTR972W2aSbT7/hxxvBhl8DPD0Oj9l1LhLE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=14q6/IpHNzdKi0Cw1tvcq80YDh3h7Fn3CuI0OsHFYLix2H5/Sr7wKPyJgN/Kke9OG vdkULdlacq//SeXknn6UBCA4CifZckzlhIYuPht5Hrki41A05YE6iy7OEQVuOBFtg3 6tiQA8Ni7k5fLzUbnSsHlk0c+p5EeJGvCVOpV82c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck , Sasha Levin Subject: [PATCH 5.10 055/100] hwmon: (lm90) Mark alert as broken for MAX6680 Date: Mon, 31 Jan 2022 11:56:16 +0100 Message-Id: <20220131105222.291685883@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Guenter Roeck commit 94746b0ba479743355e0d3cc1cb9cfe3011fb8be upstream. Experiments with MAX6680 and MAX6681 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -418,7 +418,7 @@ static const struct lm90_params lm90_par }, [max6680] =3D { .flags =3D LM90_HAVE_OFFSET | LM90_HAVE_CRIT - | LM90_HAVE_CRIT_ALRM_SWP, + | LM90_HAVE_CRIT_ALRM_SWP | LM90_HAVE_BROKEN_ALERT, .alert_alarms =3D 0x7c, .max_convrate =3D 7, }, From nobody Tue Jun 30 03:34:06 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 03B0DC433FE for ; Mon, 31 Jan 2022 11:07:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359015AbiAaLH1 (ORCPT ); Mon, 31 Jan 2022 06:07:27 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52000 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358914AbiAaLEE (ORCPT ); Mon, 31 Jan 2022 06:04:04 -0500 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 79B12B82A5F; Mon, 31 Jan 2022 11:04:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2874AC340E8; Mon, 31 Jan 2022 11:04:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627042; bh=pprbZsg+C92F/5sdWdHZshcc/eOL9hMtUXknEI2V4gg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=td+DGUpxjSOaXI5NN1SMoxpVnTIQ0bMNa7ZK/R7YrGElXmInW4iXRIStmKjE0g2xy UEn/gT4HK9QyFC+obVfpPHfSe9M6VsHkN2+DkoXWkISrgpWlYg4enAX+rDDgUxMuNr 7BPV9kQjFvY9/jSqR2kat/1PZFJuBQr0kraGMRLA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hangbin Liu , Xin Long , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 056/100] ping: fix the sk_bound_dev_if match in ping_lookup Date: Mon, 31 Jan 2022 11:56:17 +0100 Message-Id: <20220131105222.322270181@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Xin Long commit 2afc3b5a31f9edf3ef0f374f5d70610c79c93a42 upstream. When 'ping' changes to use PING socket instead of RAW socket by: # sysctl -w net.ipv4.ping_group_range=3D"0 100" the selftests 'router_broadcast.sh' will fail, as such command # ip vrf exec vrf-h1 ping -I veth0 198.51.100.255 -b can't receive the response skb by the PING socket. It's caused by mismatch of sk_bound_dev_if and dif in ping_rcv() when looking up the PING socket, as dif is vrf-h1 if dif's master was set to vrf-h1. This patch is to fix this regression by also checking the sk_bound_dev_if against sdif so that the packets can stil be received even if the socket is not bound to the vrf device but to the real iif. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Reported-by: Hangbin Liu Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv4/ping.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/ipv4/ping.c +++ b/net/ipv4/ping.c @@ -220,7 +220,8 @@ static struct sock *ping_lookup(struct n continue; } =20 - if (sk->sk_bound_dev_if && sk->sk_bound_dev_if !=3D dif) + if (sk->sk_bound_dev_if && sk->sk_bound_dev_if !=3D dif && + sk->sk_bound_dev_if !=3D inet_sdif(skb)) continue; =20 sock_hold(sk); From nobody Tue Jun 30 03:34:06 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 89EDAC433EF for ; Mon, 31 Jan 2022 11:07:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359349AbiAaLHa (ORCPT ); Mon, 31 Jan 2022 06:07:30 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51266 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358954AbiAaLEG (ORCPT ); Mon, 31 Jan 2022 06:04:06 -0500 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 262FFB82A5C; Mon, 31 Jan 2022 11:04:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D0A5C340E8; Mon, 31 Jan 2022 11:04:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627045; bh=epA1HMnU2xeW+Cur3RHnWrcYaGydHPlEDQ/IrYD7WBw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EGW8H8g9fpgLwMdY63T6kKtYTu9Sq52UX49gZy+05B7U6DZtHfcaY7VHAVZkB7C12 GkOOik8tgGSHX1eya/1y7Jo9b2LivI4kRk5Q3iqZ+hrP8kot+syC+3tt71aWAx6Qyo c2dZiEKPgIu5m/AMpaw29OCLhxKG9KZ5wOXFFQCc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , David Ahern , Ray Che , Willy Tarreau , Jakub Kicinski Subject: [PATCH 5.10 057/100] ipv4: avoid using shared IP generator for connected sockets Date: Mon, 31 Jan 2022 11:56:18 +0100 Message-Id: <20220131105222.353437413@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Eric Dumazet commit 23f57406b82de51809d5812afd96f210f8b627f3 upstream. ip_select_ident_segs() has been very conservative about using the connected socket private generator only for packets with IP_DF set, claiming it was needed for some VJ compression implementations. As mentioned in this referenced document, this can be abused. (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment) Before switching to pure random IPID generation and possibly hurt some workloads, lets use the private inet socket generator. Not only this will remove one vulnerability, this will also improve performance of TCP flows using pmtudisc=3D=3DIP_PMTUDISC_DONT Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reported-by: Ray Che Cc: Willy Tarreau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/net/ip.h | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) --- a/include/net/ip.h +++ b/include/net/ip.h @@ -506,19 +506,18 @@ static inline void ip_select_ident_segs( { struct iphdr *iph =3D ip_hdr(skb); =20 + /* We had many attacks based on IPID, use the private + * generator as much as we can. + */ + if (sk && inet_sk(sk)->inet_daddr) { + iph->id =3D htons(inet_sk(sk)->inet_id); + inet_sk(sk)->inet_id +=3D segs; + return; + } if ((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) { - /* This is only to work around buggy Windows95/2000 - * VJ compression implementations. If the ID field - * does not change, they drop every other packet in - * a TCP stream using header compression. - */ - if (sk && inet_sk(sk)->inet_daddr) { - iph->id =3D htons(inet_sk(sk)->inet_id); - inet_sk(sk)->inet_id +=3D segs; - } else { - iph->id =3D 0; - } + iph->id =3D 0; } else { + /* Unfortunately we need the big hammer to get a suitable IPID */ __ip_select_ident(net, iph, segs); } } From nobody Tue Jun 30 03:34:06 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 86636C433F5 for ; Mon, 31 Jan 2022 11:10:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348439AbiAaLKh (ORCPT ); Mon, 31 Jan 2022 06:10:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359487AbiAaLFl (ORCPT ); Mon, 31 Jan 2022 06:05:41 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B14EC061343; Mon, 31 Jan 2022 03:04:09 -0800 (PST) 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 9F63960F30; Mon, 31 Jan 2022 11:04:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66CACC340EE; Mon, 31 Jan 2022 11:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627048; bh=cyrUHQ/bV6GZ/AT9V/xmKq9w0SJfnB1JiyEl7DchvfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kkno23gHTbkwfig28rmM04qUZoqVbQjJC0vvSPHA5HVol7wzfuWnZ1VI8tSJn4Bmq QJZuySOqMZTlsghklnGOumRB4jXbY5vAM5hO4w81/DhHSk3++i5ecsA/gU4+BjzA2X fYnw/O+lht3KFhBfMn2WNawuQqzYSDDexI5sYulk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck , Sasha Levin Subject: [PATCH 5.10 058/100] hwmon: (lm90) Reduce maximum conversion rate for G781 Date: Mon, 31 Jan 2022 11:56:19 +0100 Message-Id: <20220131105222.388646211@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Guenter Roeck [ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ] According to its datasheet, G781 supports a maximum conversion rate value of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only support a maximum conversion rate value of 7 (125 ms). On the other side, chips labeled G781-1 and G784 were found to support a conversion rate value of 8. There is no known means to distinguish G780 from G781 or G784; all chips report the same manufacturer ID and chip revision. Setting the conversion rate register value to 8 on chips not supporting it causes unexpected behavior since the real conversion rate is set to 0 (16 seconds) if a value of 8 is written into the conversion rate register. Limit the conversion rate register value to 7 for all G78x chips to avoid the problem. Fixes: ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -373,7 +373,7 @@ static const struct lm90_params lm90_par .flags =3D LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT | LM90_HAVE_BROKEN_ALERT | LM90_HAVE_CRIT, .alert_alarms =3D 0x7c, - .max_convrate =3D 8, + .max_convrate =3D 7, }, [lm86] =3D { .flags =3D LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT From nobody Tue Jun 30 03:34:06 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 13138C433F5 for ; Mon, 31 Jan 2022 11:07:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359390AbiAaLHc (ORCPT ); Mon, 31 Jan 2022 06:07:32 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38682 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359001AbiAaLEM (ORCPT ); Mon, 31 Jan 2022 06:04:12 -0500 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 D7E5060B98; Mon, 31 Jan 2022 11:04:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A04F3C340E8; Mon, 31 Jan 2022 11:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627051; bh=COVT00Ds8BHWKWCGWI3NHPctY/Se/QhM+ZCvt+pvWIY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CnVyRhCgmRJIZh1BWzQ25cF2x1JgyYTRPdx6MrL4t7Bn2EV6s5JcKgyeGFsFFpIqo Pxcl931IounFC9aVatsSmFVT/Bsxx1H4/WE2oxaNXu/Msbr64UvnzYc6ncudXxnQen 6xu0gKr+Sn+b/CK+55mqYFZHJhx6JO8TojJFL23o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lyu Tao , Trond Myklebust , Anna Schumaker Subject: [PATCH 5.10 059/100] NFSv4: Handle case where the lookup of a directory fails Date: Mon, 31 Jan 2022 11:56:20 +0100 Message-Id: <20220131105222.419819274@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 ac795161c93699d600db16c1a8cc23a65a1eceaf upstream. If the application sets the O_DIRECTORY flag, and tries to open a regular file, nfs_atomic_open() will punt to doing a regular lookup. If the server then returns a regular file, we will happily return a file descriptor with uninitialised open state. The fix is to return the expected ENOTDIR error in these cases. Reported-by: Lyu Tao Fixes: 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/nfs/dir.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1777,6 +1777,19 @@ out: =20 no_open: res =3D nfs_lookup(dir, dentry, lookup_flags); + if (!res) { + inode =3D d_inode(dentry); + if ((lookup_flags & LOOKUP_DIRECTORY) && inode && + !S_ISDIR(inode->i_mode)) + res =3D ERR_PTR(-ENOTDIR); + } else if (!IS_ERR(res)) { + inode =3D d_inode(res); + if ((lookup_flags & LOOKUP_DIRECTORY) && inode && + !S_ISDIR(inode->i_mode)) { + dput(res); + res =3D ERR_PTR(-ENOTDIR); + } + } if (switched) { d_lookup_done(dentry); if (!res) From nobody Tue Jun 30 03:34:06 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 AA9B2C433EF for ; Mon, 31 Jan 2022 11:07:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359041AbiAaLHj (ORCPT ); Mon, 31 Jan 2022 06:07:39 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52194 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359032AbiAaLEQ (ORCPT ); Mon, 31 Jan 2022 06:04:16 -0500 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 AE016B82A68; Mon, 31 Jan 2022 11:04:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB029C340E8; Mon, 31 Jan 2022 11:04:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627054; bh=q2Z8elQyrGNjcKvyqzotXwhcSaZaD3Bj681ehZS/2Yg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rRZ/n3MBs/UzYYdiL56XlpJwKcbI04JdwApU1regGcDWWe8sybwpgzXYx+jYjFakv FnGhMVXrGg+HgDx34guoa852hJigodxVVy/fGpnkLj3KrUR+Kp0+VxcnULfpLfOfG7 /c6662DkYgFPdwBGwYiQmnhLOPQJOtbRhO24mb7s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker Subject: [PATCH 5.10 060/100] NFSv4: nfs_atomic_open() can race when looking up a non-regular file Date: Mon, 31 Jan 2022 11:56:21 +0100 Message-Id: <20220131105222.450508252@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 1751fc1db36f6f411709e143d5393f92d12137a9 upstream. If the file type changes back to being a regular file on the server between the failed OPEN and our LOOKUP, then we need to re-run the OPEN. Fixes: 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/nfs/dir.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1782,12 +1782,17 @@ no_open: if ((lookup_flags & LOOKUP_DIRECTORY) && inode && !S_ISDIR(inode->i_mode)) res =3D ERR_PTR(-ENOTDIR); + else if (inode && S_ISREG(inode->i_mode)) + res =3D ERR_PTR(-EOPENSTALE); } else if (!IS_ERR(res)) { inode =3D d_inode(res); if ((lookup_flags & LOOKUP_DIRECTORY) && inode && !S_ISDIR(inode->i_mode)) { dput(res); res =3D ERR_PTR(-ENOTDIR); + } else if (inode && S_ISREG(inode->i_mode)) { + dput(res); + res =3D ERR_PTR(-EOPENSTALE); } } if (switched) { From nobody Tue Jun 30 03:34:06 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 D3A61C433F5 for ; Mon, 31 Jan 2022 11:10:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359467AbiAaLHv (ORCPT ); Mon, 31 Jan 2022 06:07:51 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52250 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348484AbiAaLEU (ORCPT ); Mon, 31 Jan 2022 06:04:20 -0500 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 E09C1B82A65; Mon, 31 Jan 2022 11:04:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 027C8C340E8; Mon, 31 Jan 2022 11:04:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627057; bh=ZoPY949hCwVCTd+mgsiOvYWdOrBBWHV7xdcxQnPKTBA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OkIadMKcOOgI2q9cK9evsJDbC1JMTadAYZbAlVxq9leVLHoijL8yObaiVpzv1xaxV 10MWdqq6mtvhLIkq8PtWbP6r6vlqfBNJSZR37C9S7RLtIWhe6xCl17LXjEf3J9W3XE R4HZCGbTgXXyP3Qo2YrsyZ9rqs5HGX/glFaj2/ls= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jianguo Wu , "David S. Miller" Subject: [PATCH 5.10 061/100] net-procfs: show net devices bound packet types Date: Mon, 31 Jan 2022 11:56:22 +0100 Message-Id: <20220131105222.483720997@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jianguo Wu commit 1d10f8a1f40b965d449e8f2d5ed7b96a7c138b77 upstream. After commit:7866a621043f ("dev: add per net_device packet type chains"), we can not get packet types that are bound to a specified net device by /proc/net/ptype, this patch fix the regression. Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch: Before: [root@localhost ~]# cat /proc/net/ptype Type Device Function 0800 ip_rcv 0806 arp_rcv 86dd ipv6_rcv After: [root@localhost ~]# cat /proc/net/ptype Type Device Function ALL ens192 tpacket_rcv 0800 ip_rcv 0806 arp_rcv 86dd ipv6_rcv v1 -> v2: - fix the regression rather than adding new /proc API as suggested by Stephen Hemminger. Fixes: 7866a621043f ("dev: add per net_device packet type chains") Signed-off-by: Jianguo Wu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/net-procfs.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) --- a/net/core/net-procfs.c +++ b/net/core/net-procfs.c @@ -193,12 +193,23 @@ static const struct seq_operations softn .show =3D softnet_seq_show, }; =20 -static void *ptype_get_idx(loff_t pos) +static void *ptype_get_idx(struct seq_file *seq, loff_t pos) { + struct list_head *ptype_list =3D NULL; struct packet_type *pt =3D NULL; + struct net_device *dev; loff_t i =3D 0; int t; =20 + for_each_netdev_rcu(seq_file_net(seq), dev) { + ptype_list =3D &dev->ptype_all; + list_for_each_entry_rcu(pt, ptype_list, list) { + if (i =3D=3D pos) + return pt; + ++i; + } + } + list_for_each_entry_rcu(pt, &ptype_all, list) { if (i =3D=3D pos) return pt; @@ -219,22 +230,40 @@ static void *ptype_seq_start(struct seq_ __acquires(RCU) { rcu_read_lock(); - return *pos ? ptype_get_idx(*pos - 1) : SEQ_START_TOKEN; + return *pos ? ptype_get_idx(seq, *pos - 1) : SEQ_START_TOKEN; } =20 static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos) { + struct net_device *dev; struct packet_type *pt; struct list_head *nxt; int hash; =20 ++*pos; if (v =3D=3D SEQ_START_TOKEN) - return ptype_get_idx(0); + return ptype_get_idx(seq, 0); =20 pt =3D v; nxt =3D pt->list.next; + if (pt->dev) { + if (nxt !=3D &pt->dev->ptype_all) + goto found; + + dev =3D pt->dev; + for_each_netdev_continue_rcu(seq_file_net(seq), dev) { + if (!list_empty(&dev->ptype_all)) { + nxt =3D dev->ptype_all.next; + goto found; + } + } + + nxt =3D ptype_all.next; + goto ptype_all; + } + if (pt->type =3D=3D htons(ETH_P_ALL)) { +ptype_all: if (nxt !=3D &ptype_all) goto found; hash =3D 0; From nobody Tue Jun 30 03:34:06 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 51787C4332F for ; Mon, 31 Jan 2022 11:10:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359828AbiAaLH7 (ORCPT ); Mon, 31 Jan 2022 06:07:59 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52292 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359110AbiAaLEW (ORCPT ); Mon, 31 Jan 2022 06:04:22 -0500 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 CCE4FB82A6C; Mon, 31 Jan 2022 11:04:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFC32C340EE; Mon, 31 Jan 2022 11:04:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627060; bh=13so7g2ezdIKuT/cNeRJNDoFrTi74+ykDnHXiaUHom8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hv//6qXq7jkpMArjB4ndN+LurbB7yexshcR3abMz9Ye/6RfHqpedKBcVdaVeT21sF rPIfrobqQkn4Vfpc0T97N8AqpJypmbhnVBvTLx2VTCAC+IZrTYACGSVswkDDYFWjFy kpeyslu9hA/3lFCMVi4IAawaTte0EBUhOTXSJygc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xianting Tian , Dmitry Baryshkov , Sasha Levin Subject: [PATCH 5.10 062/100] drm/msm: Fix wrong size calculation Date: Mon, 31 Jan 2022 11:56:23 +0100 Message-Id: <20220131105222.522549814@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Xianting Tian commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream. For example, memory-region in .dts as below, reg =3D <0x0 0x50000000 0x0 0x20000000> We can get below values, struct resource r; r.start =3D 0x50000000; r.end =3D 0x6fffffff; So the size should be: size =3D r.end - r.start + 1 =3D 0x20000000 Signed-off-by: Xianting Tian Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220112123334.749776-1-xianting.tian@linux= .alibaba.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/msm/msm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -350,7 +350,7 @@ static int msm_init_vram(struct drm_devi of_node_put(node); if (ret) return ret; - size =3D r.end - r.start; + size =3D r.end - r.start + 1; DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start); =20 /* if we have no IOMMU, then we need to use carveout allocator. From nobody Tue Jun 30 03:34:06 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 BD0ADC4332F for ; Mon, 31 Jan 2022 11:10:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359852AbiAaLIB (ORCPT ); Mon, 31 Jan 2022 06:08:01 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52380 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348720AbiAaLE3 (ORCPT ); Mon, 31 Jan 2022 06:04:29 -0500 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 195CFB82A6A; Mon, 31 Jan 2022 11:04:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FF9DC340E8; Mon, 31 Jan 2022 11:04:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627066; bh=yvLfEvfM1S9QsM+cfwQvHnI2a+N1nMMw0orbNRBlg70=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OalX7TuzZJS31C/q0j6S7L0y2RdnmoERvSVQ/ZcCONrD044hb/6JSMFxeyv0/9hSI H98xKYv1RVAgDMwkkiWDWk4mKM9piNDYmYJaO8GDzHKl8Fq2Ne/Exy5b5FyUOud7n8 CGD7xe+GCnBzgonBZqFCuUxdEB5rsdcRNlb0xv70= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miaoqian Lin , Dmitry Baryshkov Subject: [PATCH 5.10 063/100] drm/msm/dsi: Fix missing put_device() call in dsi_get_phy Date: Mon, 31 Jan 2022 11:56:24 +0100 Message-Id: <20220131105222.554006644@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Miaoqian Lin commit c04c3148ca12227d92f91b355b4538cc333c9922 upstream. If of_find_device_by_node() succeeds, dsi_get_phy() doesn't a corresponding put_device(). Thus add put_device() to fix the exception handling. Fixes: ec31abf ("drm/msm/dsi: Separate PHY to another platform device") Signed-off-by: Miaoqian Lin Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211230070943.18116-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/msm/dsi/dsi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/msm/dsi/dsi.c +++ b/drivers/gpu/drm/msm/dsi/dsi.c @@ -33,7 +33,12 @@ static int dsi_get_phy(struct msm_dsi *m =20 of_node_put(phy_node); =20 - if (!phy_pdev || !msm_dsi->phy) { + if (!phy_pdev) { + DRM_DEV_ERROR(&pdev->dev, "%s: phy driver is not ready\n", __func__); + return -EPROBE_DEFER; + } + if (!msm_dsi->phy) { + put_device(&phy_pdev->dev); DRM_DEV_ERROR(&pdev->dev, "%s: phy driver is not ready\n", __func__); return -EPROBE_DEFER; } From nobody Tue Jun 30 03:34:06 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 89042C43217 for ; Mon, 31 Jan 2022 11:10:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376271AbiAaLIE (ORCPT ); Mon, 31 Jan 2022 06:08:04 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:39018 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358725AbiAaLEa (ORCPT ); Mon, 31 Jan 2022 06:04:30 -0500 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 8F14C60ABE; Mon, 31 Jan 2022 11:04:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A75AC340E8; Mon, 31 Jan 2022 11:04:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627070; bh=lALiDyO/Vpb1qIVkbxs7SHyLIB3gHpgwds0GrcoB9Hs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vhY6yQvdHdoKnfRwJ+sVYYRoi4uC2eTBKgZZdetYx2+ekjLCXX+2dlbjBpCNtHI47 cOtIiBE2tRGkuGcDUFNtR/BQXn2bcNNl9WCzHGmoKwYBD72Z9+BINZ4oqpAWY8Equl moKcSbFzv47kRDPruAg+8X8qn2PTEUIewamqabYo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Jos=C3=A9=20Exp=C3=B3sito?= , Dmitry Baryshkov Subject: [PATCH 5.10 064/100] drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable Date: Mon, 31 Jan 2022 11:56:25 +0100 Message-Id: <20220131105222.585441404@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jos=C3=A9 Exp=C3=B3sito commit 5e761a2287234bc402ba7ef07129f5103bcd775c upstream. The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files") Addresses-Coverity-ID: 1493860 ("Null pointer dereference") Signed-off-by: Jos=C3=A9 Exp=C3=B3sito Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220116181844.7400-1-jose.exposito89@gmail= .com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -769,12 +769,14 @@ void __exit msm_dsi_phy_driver_unregiste int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int src_pll_id, struct msm_dsi_phy_clk_request *clk_req) { - struct device *dev =3D &phy->pdev->dev; + struct device *dev; int ret; =20 if (!phy || !phy->cfg->ops.enable) return -EINVAL; =20 + dev =3D &phy->pdev->dev; + ret =3D dsi_phy_enable_resource(phy); if (ret) { DRM_DEV_ERROR(dev, "%s: resource enable failed, %d\n", From nobody Tue Jun 30 03:34:06 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 E0595C4167D for ; Mon, 31 Jan 2022 11:11:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359382AbiAaLLM (ORCPT ); Mon, 31 Jan 2022 06:11:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359699AbiAaLGh (ORCPT ); Mon, 31 Jan 2022 06:06:37 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86EF7C0617AD; Mon, 31 Jan 2022 03:04:35 -0800 (PST) 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 1C07BB82A59; Mon, 31 Jan 2022 11:04:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40EC5C340E8; Mon, 31 Jan 2022 11:04:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627072; bh=d0N1UeJQQ0GuTJSo+G7zA0Va6+YO69yO2bUS0WhAMq0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r94FHgzU/qQaoNJEHy/FIyB+aE+hvh2wUdrJAQ1FHuFGfpLvhbfMYBFeXQx7Pihj2 tXdxGk/jROIVYQ+jb2Yeg+hvfnki6N8UNvW0HsPTk7nqhmoHBHAumLFXkQQh0TcIcP GV1dGYw94eVp5F/cQIwzVeGqE27ZiBnHWUJeHqVg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , syzbot , Jakub Kicinski Subject: [PATCH 5.10 065/100] ipv6: annotate accesses to fn->fn_sernum Date: Mon, 31 Jan 2022 11:56:26 +0100 Message-Id: <20220131105222.616531777@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Eric Dumazet commit aafc2e3285c2d7a79b7ee15221c19fbeca7b1509 upstream. struct fib6_node's fn_sernum field can be read while other threads change it. Add READ_ONCE()/WRITE_ONCE() annotations. Do not change existing smp barriers in fib6_get_cookie_safe() and __fib6_update_sernum_upto_root() syzbot reported: BUG: KCSAN: data-race in fib6_clean_node / inet6_csk_route_socket write to 0xffff88813df62e2c of 4 bytes by task 1920 on cpu 1: fib6_clean_node+0xc2/0x260 net/ipv6/ip6_fib.c:2178 fib6_walk_continue+0x38e/0x430 net/ipv6/ip6_fib.c:2112 fib6_walk net/ipv6/ip6_fib.c:2160 [inline] fib6_clean_tree net/ipv6/ip6_fib.c:2240 [inline] __fib6_clean_all+0x1a9/0x2e0 net/ipv6/ip6_fib.c:2256 fib6_flush_trees+0x6c/0x80 net/ipv6/ip6_fib.c:2281 rt_genid_bump_ipv6 include/net/net_namespace.h:488 [inline] addrconf_dad_completed+0x57f/0x870 net/ipv6/addrconf.c:4230 addrconf_dad_work+0x908/0x1170 process_one_work+0x3f6/0x960 kernel/workqueue.c:2307 worker_thread+0x616/0xa70 kernel/workqueue.c:2454 kthread+0x1bf/0x1e0 kernel/kthread.c:359 ret_from_fork+0x1f/0x30 read to 0xffff88813df62e2c of 4 bytes by task 15701 on cpu 0: fib6_get_cookie_safe include/net/ip6_fib.h:285 [inline] rt6_get_cookie include/net/ip6_fib.h:306 [inline] ip6_dst_store include/net/ip6_route.h:234 [inline] inet6_csk_route_socket+0x352/0x3c0 net/ipv6/inet6_connection_sock.c:109 inet6_csk_xmit+0x91/0x1e0 net/ipv6/inet6_connection_sock.c:121 __tcp_transmit_skb+0x1323/0x1840 net/ipv4/tcp_output.c:1402 tcp_transmit_skb net/ipv4/tcp_output.c:1420 [inline] tcp_write_xmit+0x1450/0x4460 net/ipv4/tcp_output.c:2680 __tcp_push_pending_frames+0x68/0x1c0 net/ipv4/tcp_output.c:2864 tcp_push+0x2d9/0x2f0 net/ipv4/tcp.c:725 mptcp_push_release net/mptcp/protocol.c:1491 [inline] __mptcp_push_pending+0x46c/0x490 net/mptcp/protocol.c:1578 mptcp_sendmsg+0x9ec/0xa50 net/mptcp/protocol.c:1764 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] kernel_sendmsg+0x97/0xd0 net/socket.c:745 sock_no_sendpage+0x84/0xb0 net/core/sock.c:3086 inet_sendpage+0x9d/0xc0 net/ipv4/af_inet.c:834 kernel_sendpage+0x187/0x200 net/socket.c:3492 sock_sendpage+0x5a/0x70 net/socket.c:1007 pipe_to_sendpage+0x128/0x160 fs/splice.c:364 splice_from_pipe_feed fs/splice.c:418 [inline] __splice_from_pipe+0x207/0x500 fs/splice.c:562 splice_from_pipe fs/splice.c:597 [inline] generic_splice_sendpage+0x94/0xd0 fs/splice.c:746 do_splice_from fs/splice.c:767 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:936 splice_direct_to_actor+0x345/0x650 fs/splice.c:891 do_splice_direct+0x106/0x190 fs/splice.c:979 do_sendfile+0x675/0xc40 fs/read_write.c:1245 __do_sys_sendfile64 fs/read_write.c:1310 [inline] __se_sys_sendfile64 fs/read_write.c:1296 [inline] __x64_sys_sendfile64+0x102/0x140 fs/read_write.c:1296 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000026f -> 0x00000271 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 15701 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 The Fixes tag I chose is probably arbitrary, I do not think we need to backport this patch to older kernels. Fixes: c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node") Signed-off-by: Eric Dumazet Reported-by: syzbot Link: https://lore.kernel.org/r/20220120174112.1126644-1-eric.dumazet@gmail= .com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/net/ip6_fib.h | 2 +- net/ipv6/ip6_fib.c | 23 +++++++++++++---------- net/ipv6/route.c | 2 +- 3 files changed, 15 insertions(+), 12 deletions(-) --- a/include/net/ip6_fib.h +++ b/include/net/ip6_fib.h @@ -280,7 +280,7 @@ static inline bool fib6_get_cookie_safe( fn =3D rcu_dereference(f6i->fib6_node); =20 if (fn) { - *cookie =3D fn->fn_sernum; + *cookie =3D READ_ONCE(fn->fn_sernum); /* pairs with smp_wmb() in fib6_update_sernum_upto_root() */ smp_rmb(); status =3D true; --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -110,7 +110,7 @@ void fib6_update_sernum(struct net *net, fn =3D rcu_dereference_protected(f6i->fib6_node, lockdep_is_held(&f6i->fib6_table->tb6_lock)); if (fn) - fn->fn_sernum =3D fib6_new_sernum(net); + WRITE_ONCE(fn->fn_sernum, fib6_new_sernum(net)); } =20 /* @@ -587,12 +587,13 @@ static int fib6_dump_table(struct fib6_t spin_unlock_bh(&table->tb6_lock); if (res > 0) { cb->args[4] =3D 1; - cb->args[5] =3D w->root->fn_sernum; + cb->args[5] =3D READ_ONCE(w->root->fn_sernum); } } else { - if (cb->args[5] !=3D w->root->fn_sernum) { + int sernum =3D READ_ONCE(w->root->fn_sernum); + if (cb->args[5] !=3D sernum) { /* Begin at the root if the tree changed */ - cb->args[5] =3D w->root->fn_sernum; + cb->args[5] =3D sernum; w->state =3D FWS_INIT; w->node =3D w->root; w->skip =3D w->count; @@ -1342,7 +1343,7 @@ static void __fib6_update_sernum_upto_ro /* paired with smp_rmb() in rt6_get_cookie_safe() */ smp_wmb(); while (fn) { - fn->fn_sernum =3D sernum; + WRITE_ONCE(fn->fn_sernum, sernum); fn =3D rcu_dereference_protected(fn->parent, lockdep_is_held(&rt->fib6_table->tb6_lock)); } @@ -2171,8 +2172,8 @@ static int fib6_clean_node(struct fib6_w }; =20 if (c->sernum !=3D FIB6_NO_SERNUM_CHANGE && - w->node->fn_sernum !=3D c->sernum) - w->node->fn_sernum =3D c->sernum; + READ_ONCE(w->node->fn_sernum) !=3D c->sernum) + WRITE_ONCE(w->node->fn_sernum, c->sernum); =20 if (!c->func) { WARN_ON_ONCE(c->sernum =3D=3D FIB6_NO_SERNUM_CHANGE); @@ -2536,7 +2537,7 @@ static void ipv6_route_seq_setup_walk(st iter->w.state =3D FWS_INIT; iter->w.node =3D iter->w.root; iter->w.args =3D iter; - iter->sernum =3D iter->w.root->fn_sernum; + iter->sernum =3D READ_ONCE(iter->w.root->fn_sernum); INIT_LIST_HEAD(&iter->w.lh); fib6_walker_link(net, &iter->w); } @@ -2564,8 +2565,10 @@ static struct fib6_table *ipv6_route_seq =20 static void ipv6_route_check_sernum(struct ipv6_route_iter *iter) { - if (iter->sernum !=3D iter->w.root->fn_sernum) { - iter->sernum =3D iter->w.root->fn_sernum; + int sernum =3D READ_ONCE(iter->w.root->fn_sernum); + + if (iter->sernum !=3D sernum) { + iter->sernum =3D sernum; iter->w.state =3D FWS_INIT; iter->w.node =3D iter->w.root; WARN_ON(iter->w.skip); --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2674,7 +2674,7 @@ static void ip6_link_failure(struct sk_b if (from) { fn =3D rcu_dereference(from->fib6_node); if (fn && (rt->rt6i_flags & RTF_DEFAULT)) - fn->fn_sernum =3D -1; + WRITE_ONCE(fn->fn_sernum, -1); } } rcu_read_unlock(); From nobody Tue Jun 30 03:34:06 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 3F857C433EF for ; Mon, 31 Jan 2022 11:14:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359470AbiAaLOu (ORCPT ); Mon, 31 Jan 2022 06:14:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359713AbiAaLGh (ORCPT ); Mon, 31 Jan 2022 06:06:37 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C9AFC06134D; Mon, 31 Jan 2022 03:04:36 -0800 (PST) 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 2CD9E60E76; Mon, 31 Jan 2022 11:04:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 185CAC340E8; Mon, 31 Jan 2022 11:04:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627075; bh=c5JibMQ6CaH1JvwizkX77Go+XV1EzuwLJ33t5ObNBSs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QBg+R/3AK7rnJs2qJzRgmF8wXaRDjdeLWLZm5055wu+bMtgXrMs5WMWI9FWnZzsuz BdxArPZTs7rK1YU/r7hGWGU971NAIamhxBhZdSoG2DddqYOh2uFSBKOjOXAgynKpcB uqelzXjTDkPaCZ1fQvMwi+r6yNzD3XqhbTPWXuxQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker , Sasha Levin Subject: [PATCH 5.10 066/100] NFS: Ensure the server has an up to date ctime before hardlinking Date: Mon, 31 Jan 2022 11:56:27 +0100 Message-Id: <20220131105222.649556104@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 [ Upstream commit 204975036b34f55237bc44c8a302a88468ef21b5 ] Creating a hard link is required by POSIX to update the file ctime, so ensure that the file data is synced to disk so that we don't clobber the updated ctime by writing back after creating the hard link. Fixes: 9f7682728728 ("NFS: Move the delegation return down into nfs4_proc_l= ink()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/nfs/dir.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2192,6 +2192,8 @@ nfs_link(struct dentry *old_dentry, stru =20 trace_nfs_link_enter(inode, dir, dentry); d_drop(dentry); + if (S_ISREG(inode->i_mode)) + nfs_sync_inode(inode); error =3D NFS_PROTO(dir)->link(inode, dir, &dentry->d_name); if (error =3D=3D 0) { ihold(inode); From nobody Tue Jun 30 03:34:06 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 DEF53C4167B for ; Mon, 31 Jan 2022 11:10:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376328AbiAaLIN (ORCPT ); Mon, 31 Jan 2022 06:08:13 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52594 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359219AbiAaLEp (ORCPT ); Mon, 31 Jan 2022 06:04:45 -0500 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 BEB25B82A4E; Mon, 31 Jan 2022 11:04:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC15FC340E8; Mon, 31 Jan 2022 11:04:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627083; bh=SVOi54IO0O8pR2wEHYPHjVnXxF8fVBac/BX3gwFelaU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0wzKYjIrhiU8LZYoyE6NIWXFhJi06QelyQPwVDFM+nQ0JuLYJgc2F0upLjM7Cgkxq nxcP1RhzbszwZ3v0QGSbiOm95VOjMJSqC1BI2Bk+pgXZn1JtL46QiDi7i17HEUe3LH V56OYe52nq0tyvaw8o1qHGc2iBp9DJIoyFiiG2Zg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker , Sasha Levin Subject: [PATCH 5.10 067/100] NFS: Ensure the server has an up to date ctime before renaming Date: Mon, 31 Jan 2022 11:56:28 +0100 Message-Id: <20220131105222.683259865@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 [ Upstream commit 6ff9d99bb88faebf134ca668842349d9718e5464 ] Renaming a file is required by POSIX to update the file ctime, so ensure that the file data is synced to disk so that we don't clobber the updated ctime by writing back after creating the hard link. Fixes: f2c2c552f119 ("NFS: Move delegation recall into the NFSv4 callback f= or rename_setup()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/nfs/dir.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2282,6 +2282,8 @@ int nfs_rename(struct inode *old_dir, st } } =20 + if (S_ISREG(old_inode->i_mode)) + nfs_sync_inode(old_inode); task =3D nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry, NULL); if (IS_ERR(task)) { error =3D PTR_ERR(task); From nobody Tue Jun 30 03:34:06 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 59681C433F5 for ; Mon, 31 Jan 2022 11:14:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359577AbiAaLOx (ORCPT ); Mon, 31 Jan 2022 06:14:53 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:41228 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359206AbiAaLGq (ORCPT ); Mon, 31 Jan 2022 06:06:46 -0500 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 03B0C60F08; Mon, 31 Jan 2022 11:06:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 182DDC340E8; Mon, 31 Jan 2022 11:06:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627205; bh=T61eFx1WKYVrpzdomxYKH/1JoAQh96Z/sdw+rP1LNLQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BnaFlHA7bB5/ccYol7bL2ADSbsx4kXCVlAvTO25qoWsKowQeIWiBPVFJlSpzEpwUF 9vYtaahRaAx17knTrkC6VsqK/fMDEi3A+6iv1MLnDIExd13MH5108hkUJchDPSsWWW +TTBHCb2wvsOPDNmWadKMzRyO/yGgBq54KpG1+5E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Johan Almbladh , "Naveen N. Rao" , Michael Ellerman , Sasha Levin Subject: [PATCH 5.10 068/100] powerpc64/bpf: Limit ldbrx to processors compliant with ISA v2.06 Date: Mon, 31 Jan 2022 11:56:29 +0100 Message-Id: <20220131105222.723944006@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Naveen N. Rao [ Upstream commit 3f5f766d5f7f95a69a630da3544a1a0cee1cdddf ] Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited= :1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=3D4K SMP NR_CPUS=3D24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty = #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e00= 8a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instruction The illegal instruction turned out to be 'ldbrx' emitted for BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of the same and implement an alternative approach for older processors. Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extend= ed BPF") Reported-by: Johan Almbladh Signed-off-by: Naveen N. Rao Tested-by: Johan Almbladh Acked-by: Johan Almbladh Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/d1e51c6fdf572062cf3009a751c3406bda01b832.16= 41468127.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/powerpc/include/asm/ppc-opcode.h | 1 + arch/powerpc/net/bpf_jit_comp64.c | 22 +++++++++++++--------- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/a= sm/ppc-opcode.h index a6e3700c4566a..f0c0816f57270 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -449,6 +449,7 @@ #define PPC_RAW_LDX(r, base, b) (0x7c00002a | ___PPC_RT(r) | ___PPC_RA(ba= se) | ___PPC_RB(b)) #define PPC_RAW_LHZ(r, base, i) (0xa0000000 | ___PPC_RT(r) | ___PPC_RA(ba= se) | IMM_L(i)) #define PPC_RAW_LHBRX(r, base, b) (0x7c00062c | ___PPC_RT(r) | ___PPC_RA(b= ase) | ___PPC_RB(b)) +#define PPC_RAW_LWBRX(r, base, b) (0x7c00042c | ___PPC_RT(r) | ___PPC_RA(b= ase) | ___PPC_RB(b)) #define PPC_RAW_LDBRX(r, base, b) (0x7c000428 | ___PPC_RT(r) | ___PPC_RA(b= ase) | ___PPC_RB(b)) #define PPC_RAW_STWCX(s, a, b) (0x7c00012d | ___PPC_RS(s) | ___PPC_RA(a) = | ___PPC_RB(b)) #define PPC_RAW_CMPWI(a, i) (0x2c000000 | ___PPC_RA(a) | IMM_L(i)) diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_c= omp64.c index 8936090acb579..0d47514e8870d 100644 --- a/arch/powerpc/net/bpf_jit_comp64.c +++ b/arch/powerpc/net/bpf_jit_comp64.c @@ -651,17 +651,21 @@ bpf_alu32_trunc: EMIT(PPC_RAW_MR(dst_reg, b2p[TMP_REG_1])); break; case 64: - /* - * Way easier and faster(?) to store the value - * into stack and then use ldbrx - * - * ctx->seen will be reliable in pass2, but - * the instructions generated will remain the - * same across all passes - */ + /* Store the value to stack and then use byte-reverse loads */ PPC_BPF_STL(dst_reg, 1, bpf_jit_stack_local(ctx)); EMIT(PPC_RAW_ADDI(b2p[TMP_REG_1], 1, bpf_jit_stack_local(ctx))); - EMIT(PPC_RAW_LDBRX(dst_reg, 0, b2p[TMP_REG_1])); + if (cpu_has_feature(CPU_FTR_ARCH_206)) { + EMIT(PPC_RAW_LDBRX(dst_reg, 0, b2p[TMP_REG_1])); + } else { + EMIT(PPC_RAW_LWBRX(dst_reg, 0, b2p[TMP_REG_1])); + if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN)) + EMIT(PPC_RAW_SLDI(dst_reg, dst_reg, 32)); + EMIT(PPC_RAW_LI(b2p[TMP_REG_2], 4)); + EMIT(PPC_RAW_LWBRX(b2p[TMP_REG_2], b2p[TMP_REG_2], b2p[TMP_REG_1])); + if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)) + EMIT(PPC_RAW_SLDI(b2p[TMP_REG_2], b2p[TMP_REG_2], 32)); + EMIT(PPC_RAW_OR(dst_reg, dst_reg, b2p[TMP_REG_2])); + } break; } break; --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 DE1FCC433F5 for ; Mon, 31 Jan 2022 11:15:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376506AbiAaLPY (ORCPT ); Mon, 31 Jan 2022 06:15:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376381AbiAaLIW (ORCPT ); Mon, 31 Jan 2022 06:08:22 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85861C06137D; Mon, 31 Jan 2022 03:05:09 -0800 (PST) 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 F0E5360B2D; Mon, 31 Jan 2022 11:05:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA995C340E8; Mon, 31 Jan 2022 11:05:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627108; bh=zvyNwOr93+rBG2GHu7E1w57INMl7TdbBKGqvr/NBZrE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ICap4FEnYet9l77TP33XCFgIxV7HeEHYlrr1XvbqcllNSDLYjOkesLoyHZ8NR4DiT FATuXxZCzawaIJ2/Us9aWHGCI+m/HR9eFBdEh7yHVIOSvldM9sHTVhlw24edZwa+fd KXZsbr89EbChoBagHKGLHzUeTUUHMSjT/fMrs/oE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Florian Westphal , Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.10 069/100] netfilter: conntrack: dont increment invalid counter on NF_REPEAT Date: Mon, 31 Jan 2022 11:56:30 +0100 Message-Id: <20220131105222.755280957@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 [ Upstream commit 830af2eba40327abec64325a5b08b1e85c37a2e0 ] The packet isn't invalid, REPEAT means we're trying again after cleaning out a stale connection, e.g. via tcp tracker. This caused increases of invalid stat counter in a test case involving frequent connection reuse, even though no packet is actually invalid. Fixes: 56a62e2218f5 ("netfilter: conntrack: fix NF_REPEAT handling") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/nf_conntrack_core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack= _core.c index f4cf26b606f92..8369af0c50eab 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1832,15 +1832,17 @@ repeat: pr_debug("nf_conntrack_in: Can't track with proto module\n"); nf_conntrack_put(&ct->ct_general); skb->_nfct =3D 0; - NF_CT_STAT_INC_ATOMIC(state->net, invalid); - if (ret =3D=3D -NF_DROP) - NF_CT_STAT_INC_ATOMIC(state->net, drop); /* Special case: TCP tracker reports an attempt to reopen a * closed/aborted connection. We have to go back and create a * fresh conntrack. */ if (ret =3D=3D -NF_REPEAT) goto repeat; + + NF_CT_STAT_INC_ATOMIC(state->net, invalid); + if (ret =3D=3D -NF_DROP) + NF_CT_STAT_INC_ATOMIC(state->net, drop); + ret =3D -ret; goto out; } --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 EEA29C433FE for ; Mon, 31 Jan 2022 11:11:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359201AbiAaLLD (ORCPT ); Mon, 31 Jan 2022 06:11:03 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53620 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348313AbiAaLFo (ORCPT ); Mon, 31 Jan 2022 06:05:44 -0500 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 E2F3BB82A62; Mon, 31 Jan 2022 11:05:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0210C340E8; Mon, 31 Jan 2022 11:05:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627141; bh=8fNIaFx9lhn2hazd1oRZnR9hgJM4vILphr4g949FZmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=egM2xsFYX2o0/Ij2KVcj6L89RpGmyE8OPOq3vh+PPGD4rCLs3iCgGOvw7PJ1eGfSn 2bartePYwsKX9EJk2g8OZmWcLd0oZ2ga5HQR9+E/VxijAl2CWV/wxwyuDvOtRoVa3M qA3ez2kYKwDSLdns0+KOsOiusMAPXlF10bG6UkG0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Randy Dunlap , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Will Deacon , Mathieu Desnoyers , "Paul E. McKenney" , Juri Lelli , Vincent Guittot , Andrew Morton , Linus Torvalds , Sasha Levin Subject: [PATCH 5.10 070/100] kernel: delete repeated words in comments Date: Mon, 31 Jan 2022 11:56:31 +0100 Message-Id: <20220131105222.784795044@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Randy Dunlap [ Upstream commit c034f48e99907d5be147ac8f0f3e630a9307c2be ] Drop repeated words in kernel/events/. {if, the, that, with, time} Drop repeated words in kernel/locking/. {it, no, the} Drop repeated words in kernel/sched/. {in, not} Link: https://lkml.kernel.org/r/20210127023412.26292-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Acked-by: Will Deacon [kernel/locking/] Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Will Deacon Cc: Mathieu Desnoyers Cc: "Paul E. McKenney" Cc: Juri Lelli Cc: Vincent Guittot Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/events/core.c | 8 ++++---- kernel/events/uprobes.c | 2 +- kernel/locking/rtmutex.c | 4 ++-- kernel/locking/rwsem.c | 2 +- kernel/locking/semaphore.c | 2 +- kernel/sched/fair.c | 2 +- kernel/sched/membarrier.c | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index e2d774cc470ee..8dc7c4d12b789 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -266,7 +266,7 @@ static void event_function_call(struct perf_event *even= t, event_f func, void *da if (!event->parent) { /* * If this is a !child event, we must hold ctx::mutex to - * stabilize the the event->ctx relation. See + * stabilize the event->ctx relation. See * perf_event_ctx_lock(). */ lockdep_assert_held(&ctx->mutex); @@ -1300,7 +1300,7 @@ static void put_ctx(struct perf_event_context *ctx) * life-time rules separate them. That is an exiting task cannot fork, and= a * spawning task cannot (yet) exit. * - * But remember that that these are parent<->child context relations, and + * But remember that these are parent<->child context relations, and * migration does not affect children, therefore these two orderings shoul= d not * interact. * @@ -1439,7 +1439,7 @@ static u64 primary_event_id(struct perf_event *event) /* * Get the perf_event_context for a task and lock it. * - * This has to cope with with the fact that until it is locked, + * This has to cope with the fact that until it is locked, * the context could get moved to another task. */ static struct perf_event_context * @@ -2492,7 +2492,7 @@ static void perf_set_shadow_time(struct perf_event *e= vent, * But this is a bit hairy. * * So instead, we have an explicit cgroup call to remain - * within the time time source all along. We believe it + * within the time source all along. We believe it * is cleaner and simpler to understand. */ if (is_cgroup_event(event)) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 00b0358739ab3..e1bbb3b92921d 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -1735,7 +1735,7 @@ void uprobe_free_utask(struct task_struct *t) } =20 /* - * Allocate a uprobe_task object for the task if if necessary. + * Allocate a uprobe_task object for the task if necessary. * Called when the thread hits a breakpoint. * * Returns: diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 2f8cd616d3b29..f00dd928fc711 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1438,7 +1438,7 @@ rt_mutex_fasttrylock(struct rt_mutex *lock, } =20 /* - * Performs the wakeup of the the top-waiter and re-enables preemption. + * Performs the wakeup of the top-waiter and re-enables preemption. */ void rt_mutex_postunlock(struct wake_q_head *wake_q) { @@ -1832,7 +1832,7 @@ struct task_struct *rt_mutex_next_owner(struct rt_mut= ex *lock) * been started. * @waiter: the pre-initialized rt_mutex_waiter * - * Wait for the the lock acquisition started on our behalf by + * Wait for the lock acquisition started on our behalf by * rt_mutex_start_proxy_lock(). Upon failure, the caller must call * rt_mutex_cleanup_proxy_lock(). * diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c index a163542d178ee..cc5cc889b5b7f 100644 --- a/kernel/locking/rwsem.c +++ b/kernel/locking/rwsem.c @@ -1177,7 +1177,7 @@ rwsem_down_write_slowpath(struct rw_semaphore *sem, i= nt state) =20 /* * If there were already threads queued before us and: - * 1) there are no no active locks, wake the front + * 1) there are no active locks, wake the front * queued process(es) as the handoff bit might be set. * 2) there are no active writers and some readers, the lock * must be read owned; so we try to wake any read lock diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c index d9dd94defc0a9..9aa855a96c4ae 100644 --- a/kernel/locking/semaphore.c +++ b/kernel/locking/semaphore.c @@ -119,7 +119,7 @@ EXPORT_SYMBOL(down_killable); * @sem: the semaphore to be acquired * * Try to acquire the semaphore atomically. Returns 0 if the semaphore has - * been acquired successfully or 1 if it it cannot be acquired. + * been acquired successfully or 1 if it cannot be acquired. * * NOTE: This return value is inverted from both spin_trylock and * mutex_trylock! Be careful about this when converting code. diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2a33cb5a10e59..8d2f238fdd2ac 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5149,7 +5149,7 @@ static void do_sched_cfs_slack_timer(struct cfs_bandw= idth *cfs_b) /* * When a group wakes up we want to make sure that its quota is not already * expired/exceeded, otherwise it may be allowed to steal additional ticks= of - * runtime as update_curr() throttling can not not trigger until it's on-r= q. + * runtime as update_curr() throttling can not trigger until it's on-rq. */ static void check_enqueue_throttle(struct cfs_rq *cfs_rq) { diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c index 4d4dd349c05be..cc7cd512e4e33 100644 --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -316,7 +316,7 @@ static int sync_runqueues_membarrier_state(struct mm_st= ruct *mm) =20 /* * For each cpu runqueue, if the task's mm match @mm, ensure that all - * @mm's membarrier state set bits are also set in in the runqueue's + * @mm's membarrier state set bits are also set in the runqueue's * membarrier state. This ensures that a runqueue scheduling * between threads which are users of @mm has its membarrier state * updated. --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 C8968C433F5 for ; Mon, 31 Jan 2022 11:16:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376852AbiAaLQh (ORCPT ); Mon, 31 Jan 2022 06:16:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377062AbiAaLJc (ORCPT ); Mon, 31 Jan 2022 06:09:32 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FA27C0613E5; Mon, 31 Jan 2022 03:06:18 -0800 (PST) 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 D3CF1B82A6C; Mon, 31 Jan 2022 11:06:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 026CAC340E8; Mon, 31 Jan 2022 11:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627175; bh=YFA+HSw1gf6c5MgGDyQRSgkiuwsH9QAjM1b2pFvh1xc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JOXfoT3JqXvY2dkIn7s8c42B6k2Y4kBIgu3cvNpgItsOYnHm4uegsu4823zLI6LNx WM/n1nbxxq5I6i5AUVSnBq/MFdzUGSo4I3ohAls7r4sEj/pBy51lX+KkHh5VoDyuR0 eJa4mcLhrtZKg9uyYW3PHn0PA3NtRwm1qiC0oxlc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Song Liu , Namhyung Kim , Sasha Levin Subject: [PATCH 5.10 071/100] perf: Fix perf_event_read_local() time Date: Mon, 31 Jan 2022 11:56:32 +0100 Message-Id: <20220131105222.818000309@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Peter Zijlstra [ Upstream commit 09f5e7dc7ad705289e1b1ec065439aa3c42951c4 ] Time readers that cannot take locks (due to NMI etc..) currently make use of perf_event::shadow_ctx_time, which, for that event gives: time' =3D now + (time - timestamp) or, alternatively arranged: time' =3D time + (now - timestamp) IOW, the progression of time since the last time the shadow_ctx_time was updated. There's problems with this: A) the shadow_ctx_time is per-event, even though the ctx_time it reflects is obviously per context. The direct concequence of this is that the context needs to iterate all events all the time to keep the shadow_ctx_time in sync. B) even with the prior point, the context itself might not be active meaning its time should not advance to begin with. C) shadow_ctx_time isn't consistently updated when ctx_time is There are 3 users of this stuff, that suffer differently from this: - calc_timer_values() - perf_output_read() - perf_event_update_userpage() /* A */ - perf_event_read_local() /* A,B */ In particular, perf_output_read() doesn't suffer at all, because it's sample driven and hence only relevant when the event is actually running. This same was supposed to be true for perf_event_update_userpage(), after all self-monitoring implies the context is active *HOWEVER*, as per commit f79256532682 ("perf/core: fix userpage->time_enabled of inactive events") this goes wrong when combined with counter overcommit, in that case those events that do not get scheduled when the context becomes active (task events typically) miss out on the EVENT_TIME update and ENABLED time is inflated (for a little while) with the time the context was inactive. Once the event gets rotated in, this gets corrected, leading to a non-monotonic timeflow. perf_event_read_local() made things even worse, it can request time at any point, suffering all the problems perf_event_update_userpage() does and more. Because while perf_event_update_userpage() is limited by the context being active, perf_event_read_local() users have no such constraint. Therefore, completely overhaul things and do away with perf_event::shadow_ctx_time. Instead have regular context time updates keep track of this offset directly and provide perf_event_time_now() to complement perf_event_time(). perf_event_time_now() will, in adition to being context wide, also take into account if the context is active. For inactive context, it will not advance time. This latter property means the cgroup perf_cgroup_info context needs to grow addition state to track this. Additionally, since all this is strictly per-cpu, we can use barrier() to order context activity vs context time. Fixes: 7d9285e82db5 ("perf/bpf: Extend the perf_event_read_local() interfac= e, a.k.a. "bpf: perf event change needed for subsequent bpf helpers"") Signed-off-by: Peter Zijlstra (Intel) Tested-by: Song Liu Tested-by: Namhyung Kim Link: https://lkml.kernel.org/r/YcB06DasOBtU0b00@hirez.programming.kicks-as= s.net Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/perf_event.h | 15 +-- kernel/events/core.c | 246 ++++++++++++++++++++++--------------- 2 files changed, 149 insertions(+), 112 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index c94551091dad3..67a50c78232fe 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -678,18 +678,6 @@ struct perf_event { u64 total_time_running; u64 tstamp; =20 - /* - * timestamp shadows the actual context timing but it can - * be safely used in NMI interrupt context. It reflects the - * context time as it was when the event was last scheduled in, - * or when ctx_sched_in failed to schedule the event because we - * run out of PMC. - * - * ctx_time already accounts for ctx->timestamp. Therefore to - * compute ctx_time for a sample, simply add perf_clock(). - */ - u64 shadow_ctx_time; - struct perf_event_attr attr; u16 header_size; u16 id_header_size; @@ -834,6 +822,7 @@ struct perf_event_context { */ u64 time; u64 timestamp; + u64 timeoffset; =20 /* * These fields let us detect when two contexts have both @@ -916,6 +905,8 @@ struct bpf_perf_event_data_kern { struct perf_cgroup_info { u64 time; u64 timestamp; + u64 timeoffset; + int active; }; =20 struct perf_cgroup { diff --git a/kernel/events/core.c b/kernel/events/core.c index 8dc7c4d12b789..c6493f7e02359 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -673,6 +673,23 @@ perf_event_set_state(struct perf_event *event, enum pe= rf_event_state state) WRITE_ONCE(event->state, state); } =20 +/* + * UP store-release, load-acquire + */ + +#define __store_release(ptr, val) \ +do { \ + barrier(); \ + WRITE_ONCE(*(ptr), (val)); \ +} while (0) + +#define __load_acquire(ptr) \ +({ \ + __unqual_scalar_typeof(*(ptr)) ___p =3D READ_ONCE(*(ptr)); \ + barrier(); \ + ___p; \ +}) + #ifdef CONFIG_CGROUP_PERF =20 static inline bool @@ -718,34 +735,51 @@ static inline u64 perf_cgroup_event_time(struct perf_= event *event) return t->time; } =20 -static inline void __update_cgrp_time(struct perf_cgroup *cgrp) +static inline u64 perf_cgroup_event_time_now(struct perf_event *event, u64= now) { - struct perf_cgroup_info *info; - u64 now; - - now =3D perf_clock(); + struct perf_cgroup_info *t; =20 - info =3D this_cpu_ptr(cgrp->info); + t =3D per_cpu_ptr(event->cgrp->info, event->cpu); + if (!__load_acquire(&t->active)) + return t->time; + now +=3D READ_ONCE(t->timeoffset); + return now; +} =20 - info->time +=3D now - info->timestamp; +static inline void __update_cgrp_time(struct perf_cgroup_info *info, u64 n= ow, bool adv) +{ + if (adv) + info->time +=3D now - info->timestamp; info->timestamp =3D now; + /* + * see update_context_time() + */ + WRITE_ONCE(info->timeoffset, info->time - info->timestamp); } =20 -static inline void update_cgrp_time_from_cpuctx(struct perf_cpu_context *c= puctx) +static inline void update_cgrp_time_from_cpuctx(struct perf_cpu_context *c= puctx, bool final) { struct perf_cgroup *cgrp =3D cpuctx->cgrp; struct cgroup_subsys_state *css; + struct perf_cgroup_info *info; =20 if (cgrp) { + u64 now =3D perf_clock(); + for (css =3D &cgrp->css; css; css =3D css->parent) { cgrp =3D container_of(css, struct perf_cgroup, css); - __update_cgrp_time(cgrp); + info =3D this_cpu_ptr(cgrp->info); + + __update_cgrp_time(info, now, true); + if (final) + __store_release(&info->active, 0); } } } =20 static inline void update_cgrp_time_from_event(struct perf_event *event) { + struct perf_cgroup_info *info; struct perf_cgroup *cgrp; =20 /* @@ -759,8 +793,10 @@ static inline void update_cgrp_time_from_event(struct = perf_event *event) /* * Do not update time when cgroup is not active */ - if (cgroup_is_descendant(cgrp->css.cgroup, event->cgrp->css.cgroup)) - __update_cgrp_time(event->cgrp); + if (cgroup_is_descendant(cgrp->css.cgroup, event->cgrp->css.cgroup)) { + info =3D this_cpu_ptr(event->cgrp->info); + __update_cgrp_time(info, perf_clock(), true); + } } =20 static inline void @@ -784,7 +820,8 @@ perf_cgroup_set_timestamp(struct task_struct *task, for (css =3D &cgrp->css; css; css =3D css->parent) { cgrp =3D container_of(css, struct perf_cgroup, css); info =3D this_cpu_ptr(cgrp->info); - info->timestamp =3D ctx->timestamp; + __update_cgrp_time(info, ctx->timestamp, false); + __store_release(&info->active, 1); } } =20 @@ -980,14 +1017,6 @@ out: return ret; } =20 -static inline void -perf_cgroup_set_shadow_time(struct perf_event *event, u64 now) -{ - struct perf_cgroup_info *t; - t =3D per_cpu_ptr(event->cgrp->info, event->cpu); - event->shadow_ctx_time =3D now - t->timestamp; -} - static inline void perf_cgroup_event_enable(struct perf_event *event, struct perf_event_conte= xt *ctx) { @@ -1065,7 +1094,8 @@ static inline void update_cgrp_time_from_event(struct= perf_event *event) { } =20 -static inline void update_cgrp_time_from_cpuctx(struct perf_cpu_context *c= puctx) +static inline void update_cgrp_time_from_cpuctx(struct perf_cpu_context *c= puctx, + bool final) { } =20 @@ -1097,12 +1127,12 @@ perf_cgroup_switch(struct task_struct *task, struct= task_struct *next) { } =20 -static inline void -perf_cgroup_set_shadow_time(struct perf_event *event, u64 now) +static inline u64 perf_cgroup_event_time(struct perf_event *event) { + return 0; } =20 -static inline u64 perf_cgroup_event_time(struct perf_event *event) +static inline u64 perf_cgroup_event_time_now(struct perf_event *event, u64= now) { return 0; } @@ -1524,22 +1554,59 @@ static void perf_unpin_context(struct perf_event_co= ntext *ctx) /* * Update the record of the current time in a context. */ -static void update_context_time(struct perf_event_context *ctx) +static void __update_context_time(struct perf_event_context *ctx, bool adv) { u64 now =3D perf_clock(); =20 - ctx->time +=3D now - ctx->timestamp; + if (adv) + ctx->time +=3D now - ctx->timestamp; ctx->timestamp =3D now; + + /* + * The above: time' =3D time + (now - timestamp), can be re-arranged + * into: time` =3D now + (time - timestamp), which gives a single value + * offset to compute future time without locks on. + * + * See perf_event_time_now(), which can be used from NMI context where + * it's (obviously) not possible to acquire ctx->lock in order to read + * both the above values in a consistent manner. + */ + WRITE_ONCE(ctx->timeoffset, ctx->time - ctx->timestamp); +} + +static void update_context_time(struct perf_event_context *ctx) +{ + __update_context_time(ctx, true); } =20 static u64 perf_event_time(struct perf_event *event) { struct perf_event_context *ctx =3D event->ctx; =20 + if (unlikely(!ctx)) + return 0; + if (is_cgroup_event(event)) return perf_cgroup_event_time(event); =20 - return ctx ? ctx->time : 0; + return ctx->time; +} + +static u64 perf_event_time_now(struct perf_event *event, u64 now) +{ + struct perf_event_context *ctx =3D event->ctx; + + if (unlikely(!ctx)) + return 0; + + if (is_cgroup_event(event)) + return perf_cgroup_event_time_now(event, now); + + if (!(__load_acquire(&ctx->is_active) & EVENT_TIME)) + return ctx->time; + + now +=3D READ_ONCE(ctx->timeoffset); + return now; } =20 static enum event_type_t get_event_type(struct perf_event *event) @@ -2333,7 +2400,7 @@ __perf_remove_from_context(struct perf_event *event, =20 if (ctx->is_active & EVENT_TIME) { update_context_time(ctx); - update_cgrp_time_from_cpuctx(cpuctx); + update_cgrp_time_from_cpuctx(cpuctx, false); } =20 event_sched_out(event, cpuctx, ctx); @@ -2342,6 +2409,9 @@ __perf_remove_from_context(struct perf_event *event, list_del_event(event, ctx); =20 if (!ctx->nr_events && ctx->is_active) { + if (ctx =3D=3D &cpuctx->ctx) + update_cgrp_time_from_cpuctx(cpuctx, true); + ctx->is_active =3D 0; ctx->rotate_necessary =3D 0; if (ctx->task) { @@ -2467,40 +2537,6 @@ void perf_event_disable_inatomic(struct perf_event *= event) irq_work_queue(&event->pending); } =20 -static void perf_set_shadow_time(struct perf_event *event, - struct perf_event_context *ctx) -{ - /* - * use the correct time source for the time snapshot - * - * We could get by without this by leveraging the - * fact that to get to this function, the caller - * has most likely already called update_context_time() - * and update_cgrp_time_xx() and thus both timestamp - * are identical (or very close). Given that tstamp is, - * already adjusted for cgroup, we could say that: - * tstamp - ctx->timestamp - * is equivalent to - * tstamp - cgrp->timestamp. - * - * Then, in perf_output_read(), the calculation would - * work with no changes because: - * - event is guaranteed scheduled in - * - no scheduled out in between - * - thus the timestamp would be the same - * - * But this is a bit hairy. - * - * So instead, we have an explicit cgroup call to remain - * within the time source all along. We believe it - * is cleaner and simpler to understand. - */ - if (is_cgroup_event(event)) - perf_cgroup_set_shadow_time(event, event->tstamp); - else - event->shadow_ctx_time =3D event->tstamp - ctx->timestamp; -} - #define MAX_INTERRUPTS (~0ULL) =20 static void perf_log_throttle(struct perf_event *event, int enable); @@ -2541,8 +2577,6 @@ event_sched_in(struct perf_event *event, =20 perf_pmu_disable(event->pmu); =20 - perf_set_shadow_time(event, ctx); - perf_log_itrace_start(event); =20 if (event->pmu->add(event, PERF_EF_START)) { @@ -3216,16 +3250,6 @@ static void ctx_sched_out(struct perf_event_context = *ctx, return; } =20 - ctx->is_active &=3D ~event_type; - if (!(ctx->is_active & EVENT_ALL)) - ctx->is_active =3D 0; - - if (ctx->task) { - WARN_ON_ONCE(cpuctx->task_ctx !=3D ctx); - if (!ctx->is_active) - cpuctx->task_ctx =3D NULL; - } - /* * Always update time if it was set; not only when it changes. * Otherwise we can 'forget' to update time for any but the last @@ -3239,7 +3263,22 @@ static void ctx_sched_out(struct perf_event_context = *ctx, if (is_active & EVENT_TIME) { /* update (and stop) ctx time */ update_context_time(ctx); - update_cgrp_time_from_cpuctx(cpuctx); + update_cgrp_time_from_cpuctx(cpuctx, ctx =3D=3D &cpuctx->ctx); + /* + * CPU-release for the below ->is_active store, + * see __load_acquire() in perf_event_time_now() + */ + barrier(); + } + + ctx->is_active &=3D ~event_type; + if (!(ctx->is_active & EVENT_ALL)) + ctx->is_active =3D 0; + + if (ctx->task) { + WARN_ON_ONCE(cpuctx->task_ctx !=3D ctx); + if (!ctx->is_active) + cpuctx->task_ctx =3D NULL; } =20 is_active ^=3D ctx->is_active; /* changed bits */ @@ -3676,13 +3715,19 @@ static noinline int visit_groups_merge(struct perf_= cpu_context *cpuctx, return 0; } =20 +/* + * Because the userpage is strictly per-event (there is no concept of cont= ext, + * so there cannot be a context indirection), every userpage must be updat= ed + * when context time starts :-( + * + * IOW, we must not miss EVENT_TIME edges. + */ static inline bool event_update_userpage(struct perf_event *event) { if (likely(!atomic_read(&event->mmap_count))) return false; =20 perf_event_update_time(event); - perf_set_shadow_time(event, event->ctx); perf_event_update_userpage(event); =20 return true; @@ -3766,13 +3811,23 @@ ctx_sched_in(struct perf_event_context *ctx, struct task_struct *task) { int is_active =3D ctx->is_active; - u64 now; =20 lockdep_assert_held(&ctx->lock); =20 if (likely(!ctx->nr_events)) return; =20 + if (is_active ^ EVENT_TIME) { + /* start ctx time */ + __update_context_time(ctx, false); + perf_cgroup_set_timestamp(task, ctx); + /* + * CPU-release for the below ->is_active store, + * see __load_acquire() in perf_event_time_now() + */ + barrier(); + } + ctx->is_active |=3D (event_type | EVENT_TIME); if (ctx->task) { if (!is_active) @@ -3783,13 +3838,6 @@ ctx_sched_in(struct perf_event_context *ctx, =20 is_active ^=3D ctx->is_active; /* changed bits */ =20 - if (is_active & EVENT_TIME) { - /* start ctx time */ - now =3D perf_clock(); - ctx->timestamp =3D now; - perf_cgroup_set_timestamp(task, ctx); - } - /* * First go through the list and put on any pinned groups * in order to give them the best chance of going on. @@ -4325,6 +4373,18 @@ static inline u64 perf_event_count(struct perf_event= *event) return local64_read(&event->count) + atomic64_read(&event->child_count); } =20 +static void calc_timer_values(struct perf_event *event, + u64 *now, + u64 *enabled, + u64 *running) +{ + u64 ctx_time; + + *now =3D perf_clock(); + ctx_time =3D perf_event_time_now(event, *now); + __perf_update_times(event, ctx_time, enabled, running); +} + /* * NMI-safe method to read a local event, that is an event that * is: @@ -4384,10 +4444,9 @@ int perf_event_read_local(struct perf_event *event, = u64 *value, =20 *value =3D local64_read(&event->count); if (enabled || running) { - u64 now =3D event->shadow_ctx_time + perf_clock(); - u64 __enabled, __running; + u64 __enabled, __running, __now;; =20 - __perf_update_times(event, now, &__enabled, &__running); + calc_timer_values(event, &__now, &__enabled, &__running); if (enabled) *enabled =3D __enabled; if (running) @@ -5694,18 +5753,6 @@ static int perf_event_index(struct perf_event *event) return event->pmu->event_idx(event); } =20 -static void calc_timer_values(struct perf_event *event, - u64 *now, - u64 *enabled, - u64 *running) -{ - u64 ctx_time; - - *now =3D perf_clock(); - ctx_time =3D event->shadow_ctx_time + *now; - __perf_update_times(event, ctx_time, enabled, running); -} - static void perf_event_init_userpage(struct perf_event *event) { struct perf_event_mmap_page *userpg; @@ -6245,7 +6292,6 @@ accounting: ring_buffer_attach(event, rb); =20 perf_event_update_time(event); - perf_set_shadow_time(event, event->ctx); perf_event_init_userpage(event); perf_event_update_userpage(event); } else { --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 DB24AC433EF for ; Mon, 31 Jan 2022 11:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359397AbiAaLQv (ORCPT ); Mon, 31 Jan 2022 06:16:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377169AbiAaLJp (ORCPT ); Mon, 31 Jan 2022 06:09:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88691C0604CA; Mon, 31 Jan 2022 03:06:28 -0800 (PST) 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 2794460FB5; Mon, 31 Jan 2022 11:06:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA66BC340E8; Mon, 31 Jan 2022 11:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627187; bh=Nc46HbOlscxH1ZoeqPE08D0tvHM0jh6dbN/WgavK4V0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=18Qr1qrSSg2IJjB7PRReUVX8Q85srXRZWUZINWKYyT2n1ByOHOJstErZ5Z9aEIYy9 MLJiL+TZqXdjFDvzORVc3FBd/LjAzRx2YHtPEVARu8PaVD0ecG2EbPn7cWTBiU/9r+ 2aM8sZm3vfXRtyabPrUaQd8UmaxVmrgC2BVJsr50= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rick Yiu , Vincent Guittot , "Peter Zijlstra (Intel)" , Dietmar Eggemann , Sachin Sant , Sasha Levin Subject: [PATCH 5.10 072/100] sched/pelt: Relax the sync of util_sum with util_avg Date: Mon, 31 Jan 2022 11:56:33 +0100 Message-Id: <20220131105222.848675855@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Vincent Guittot [ Upstream commit 98b0d890220d45418cfbc5157b3382e6da5a12ab ] Rick reported performance regressions in bugzilla because of cpu frequency being lower than before: https://bugzilla.kernel.org/show_bug.cgi?id=3D215045 He bisected the problem to: commit 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consiste= nt") This commit forces util_sum to be synced with the new util_avg after removing the contribution of a task and before the next periodic sync. By doing so util_sum is rounded to its lower bound and might lost up to LOAD_AVG_MAX-1 of accumulated contribution which has not yet been reflected in util_avg. Instead of always setting util_sum to the low bound of util_avg, which can significantly lower the utilization of root cfs_rq after propagating the change down into the hierarchy, we revert the change of util_sum and propagate the difference. In addition, we also check that cfs's util_sum always stays above the lower bound for a given util_avg as it has been observed that sched_entity's util_sum is sometimes above cfs one. Fixes: 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consiste= nt") Reported-by: Rick Yiu Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Tested-by: Sachin Sant Link: https://lkml.kernel.org/r/20220111134659.24961-2-vincent.guittot@lina= ro.org Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/sched/fair.c | 16 +++++++++++++--- kernel/sched/pelt.h | 4 +++- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 8d2f238fdd2ac..acd9833b8ec22 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3379,7 +3379,6 @@ void set_task_rq_fair(struct sched_entity *se, se->avg.last_update_time =3D n_last_update_time; } =20 - /* * When on migration a sched_entity joins/leaves the PELT hierarchy, we ne= ed to * propagate its contribution. The key to this propagation is the invariant @@ -3447,7 +3446,6 @@ void set_task_rq_fair(struct sched_entity *se, * XXX: only do this for the part of runnable > running ? * */ - static inline void update_tg_cfs_util(struct cfs_rq *cfs_rq, struct sched_entity *se, struct = cfs_rq *gcfs_rq) { @@ -3676,7 +3674,19 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_r= q) =20 r =3D removed_util; sub_positive(&sa->util_avg, r); - sa->util_sum =3D sa->util_avg * divider; + sub_positive(&sa->util_sum, r * divider); + /* + * Because of rounding, se->util_sum might ends up being +1 more than + * cfs->util_sum. Although this is not a problem by itself, detaching + * a lot of tasks with the rounding problem between 2 updates of + * util_avg (~1ms) can make cfs->util_sum becoming null whereas + * cfs_util_avg is not. + * Check that util_sum is still above its lower bound for the new + * util_avg. Given that period_contrib might have moved since the last + * sync, we are only sure that util_sum must be above or equal to + * util_avg * minimum possible divider + */ + sa->util_sum =3D max_t(u32, sa->util_sum, sa->util_avg * PELT_MIN_DIVIDE= R); =20 r =3D removed_runnable; sub_positive(&sa->runnable_avg, r); diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h index 0b9aeebb9c325..45bf08e22207c 100644 --- a/kernel/sched/pelt.h +++ b/kernel/sched/pelt.h @@ -37,9 +37,11 @@ update_irq_load_avg(struct rq *rq, u64 running) } #endif =20 +#define PELT_MIN_DIVIDER (LOAD_AVG_MAX - 1024) + static inline u32 get_pelt_divider(struct sched_avg *avg) { - return LOAD_AVG_MAX - 1024 + avg->period_contrib; + return PELT_MIN_DIVIDER + avg->period_contrib; } =20 static inline void cfs_se_util_change(struct sched_avg *avg) --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 ADB0DC43217 for ; Mon, 31 Jan 2022 11:11:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359093AbiAaLK6 (ORCPT ); Mon, 31 Jan 2022 06:10:58 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:40980 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348507AbiAaLGb (ORCPT ); Mon, 31 Jan 2022 06:06:31 -0500 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 5BBC26104B; Mon, 31 Jan 2022 11:06:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AB5AC36AE3; Mon, 31 Jan 2022 11:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627190; bh=i/qDGYIStvA+YTvPwrw5QtUqxP1K+kAf+KVBEzQxREI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1BosN7zXh58OxuN54z9NnVW7AbWtak0/3Hlz5E4dK1D+RdlGpNwFTH90ZqARKazJG qiVwZUKx+/X1dctg3LCtcq/eU5ILSxrSbILOrN/MMybZIiWnY8t93ezi/NIbfmrMHO BqdIEJLKVHmdRV6Rn0DPv7qMMKcfNAHymZOfcTNM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Hancock , Florian Fainelli , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 073/100] net: phy: broadcom: hook up soft_reset for BCM54616S Date: Mon, 31 Jan 2022 11:56:34 +0100 Message-Id: <20220131105222.877560759@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Robert Hancock [ Upstream commit d15c7e875d44367005370e6a82e8f3a382a04f9b ] A problem was encountered with the Bel-Fuse 1GBT-SFP05 SFP module (which is a 1 Gbps copper module operating in SGMII mode with an internal BCM54616S PHY device) using the Xilinx AXI Ethernet MAC core, where the module would work properly on the initial insertion or boot of the device, but after the device was rebooted, the link would either only come up at 100 Mbps speeds or go up and down erratically. I found no meaningful changes in the PHY configuration registers between the working and non-working boots, but the status registers seemed to have a lot of error indications set on the SERDES side of the device on the non-working boot. I suspect the problem is that whatever happens on the SGMII link when the device is rebooted and the FPGA logic gets reloaded ends up putting the module's onboard PHY into a bad state. Since commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") the genphy_soft_reset call is not made automatically by the PHY core unless the callback is explicitly specified in the driver structure. For most of these Broadcom devices, there is probably a hardware reset that gets asserted to reset the PHY during boot, however for SFP modules (where the BCM54616S is commonly found) no such reset line exists, so if the board keeps the SFP cage powered up across a reboot, it will end up with no reset occurring during reboots. Hook up the genphy_soft_reset callback for BCM54616S to ensure that a PHY reset is performed before the device is initialized. This appears to fix the issue with erratic operation after a reboot with this SFP module. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Robert Hancock Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/phy/broadcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c index dbed15dc0fe77..644861366d544 100644 --- a/drivers/net/phy/broadcom.c +++ b/drivers/net/phy/broadcom.c @@ -789,6 +789,7 @@ static struct phy_driver broadcom_drivers[] =3D { .phy_id_mask =3D 0xfffffff0, .name =3D "Broadcom BCM54616S", /* PHY_GBIT_FEATURES */ + .soft_reset =3D genphy_soft_reset, .config_init =3D bcm54xx_config_init, .config_aneg =3D bcm54616s_config_aneg, .ack_interrupt =3D bcm_phy_ack_intr, --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 55ADAC433F5 for ; Mon, 31 Jan 2022 11:17:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359708AbiAaLRE (ORCPT ); Mon, 31 Jan 2022 06:17:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377216AbiAaLJs (ORCPT ); Mon, 31 Jan 2022 06:09:48 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3350CC0604D4; Mon, 31 Jan 2022 03:06:36 -0800 (PST) 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 E760BB82A5C; Mon, 31 Jan 2022 11:06:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39E48C340EF; Mon, 31 Jan 2022 11:06:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627193; bh=fwtUg8Y8iUk8jIUE8qbO9EPXZyhnyzScNpHop/rrleU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xWDc+pOiguFC7IEfLsIlnY0PT41t7VOWSqXsmpZAlP7mURjT/svW3gjYBOeux0qjn MI9G5+24s7GL9/H+nk7a2u/hopas68UklEuQTEogN1F004v90bkIcTERe58TyT1BUT gSnXxuVYyBzFqfNhFPIXzutSEco4rPZsa4EPJTGY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Marek=20Beh=C3=BAn?= , Andrew Lunn , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 074/100] phylib: fix potential use-after-free Date: Mon, 31 Jan 2022 11:56:35 +0100 Message-Id: <20220131105222.910242948@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 Beh=C3=BAn [ Upstream commit cbda1b16687580d5beee38273f6241ae3725960c ] Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach(). The comment before the put_device() call says that the phydev might go away with put_device(). Fix potential use-after-free by calling phy_device_reset() before put_device(). Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support") Signed-off-by: Marek Beh=C3=BAn Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220119162748.32418-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/phy/phy_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 85f3cde5ffd09..d2f6d8107595a 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1682,6 +1682,9 @@ void phy_detach(struct phy_device *phydev) phy_driver_is_genphy_10g(phydev)) device_release_driver(&phydev->mdio.dev); =20 + /* Assert the reset signal */ + phy_device_reset(phydev, 1); + /* * The phydev might go away on the put_device() below, so avoid * a use-after-free bug by reading the underlying bus first. @@ -1693,9 +1696,6 @@ void phy_detach(struct phy_device *phydev) ndev_owner =3D dev->dev.parent->driver->owner; if (ndev_owner !=3D bus->owner) module_put(bus->owner); - - /* Assert the reset signal */ - phy_device_reset(phydev, 1); } EXPORT_SYMBOL(phy_detach); =20 --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 CDCA0C433EF for ; Mon, 31 Jan 2022 11:17:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359656AbiAaLRA (ORCPT ); Mon, 31 Jan 2022 06:17:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377226AbiAaLJt (ORCPT ); Mon, 31 Jan 2022 06:09:49 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32406C0613FC; Mon, 31 Jan 2022 03:06:39 -0800 (PST) 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 EDA89B82A60; Mon, 31 Jan 2022 11:06:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AD48C340EE; Mon, 31 Jan 2022 11:06:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627196; bh=pdE/ftul88bx3uGjcDMp1tLlzo0wwAG4y/GYzI/oO7A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kbndM2cRJI6gclSUB2ugjYg7q30V5L6VANTJp9xFSH/aSjfBSuXM0ZXmisxudaKhZ w11zTyr7jnfsBPwzmfKw4Ex0/uke1IoS2rqdAlks+GwfOY9RLhcJgV5hSVcd3MVBjk 8kig/mEtXuHURdktV5TBpN1Rb4Z9mdqkJBOBSlt4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Subbaraya Sundeep , Sunil Goutham , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 075/100] octeontx2-pf: Forward error codes to VF Date: Mon, 31 Jan 2022 11:56:36 +0100 Message-Id: <20220131105222.951181036@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Subbaraya Sundeep [ Upstream commit a8db854be28622a2477cb21cdf7f829adbb2c42d ] PF forwards its VF messages to AF and corresponding replies from AF to VF. AF sets proper error code in the replies after processing message requests. Currently PF checks the error codes in replies and sends invalid message to VF. This way VF lacks the information of error code set by AF for its messages. This patch changes that such that PF simply forwards AF replies so that VF can handle error codes. Fixes: d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling= ") Signed-off-by: Subbaraya Sundeep Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers= /net/ethernet/marvell/octeontx2/nic/otx2_pf.c index 044a5b1196acb..161174be51c31 100644 --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c @@ -386,7 +386,12 @@ static int otx2_forward_vf_mbox_msgs(struct otx2_nic *= pf, dst_mdev->msg_size =3D mbox_hdr->msg_size; dst_mdev->num_msgs =3D num_msgs; err =3D otx2_sync_mbox_msg(dst_mbox); - if (err) { + /* Error code -EIO indicate there is a communication failure + * to the AF. Rest of the error codes indicate that AF processed + * VF messages and set the error codes in response messages + * (if any) so simply forward responses to VF. + */ + if (err =3D=3D -EIO) { dev_warn(pf->dev, "AF not responding to VF%d messages\n", vf); /* restore PF mbase and exit */ --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 AAFA9C4707A for ; Mon, 31 Jan 2022 11:13:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376773AbiAaLNN (ORCPT ); Mon, 31 Jan 2022 06:13:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377235AbiAaLJt (ORCPT ); Mon, 31 Jan 2022 06:09:49 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08CE9C061398; Mon, 31 Jan 2022 03:06:41 -0800 (PST) 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 A79E5B82A60; Mon, 31 Jan 2022 11:06:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25373C340EF; Mon, 31 Jan 2022 11:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627199; bh=hRKTuIsnl4WN0VxrzUwjAAfV/KmgykqxL+AVfx9ryCM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RCUdZo/h1DrWQTvBFsIjnh1ZkJRwuCuVYZ9ea/VYApRNJ69DAV2V2y23FWJfwTTBL IIi1hx8e6upOs/H6zx+NHcJhhUmDH+QljbRrmVWrMzsSOf7sSTooSOdqYgs8nW7BkA trE35hylR4zBtE79ceB9EWy3RDP7STzTacrxKS9w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Dionne , David Howells , linux-afs@lists.infradead.org, "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 076/100] rxrpc: Adjust retransmission backoff Date: Mon, 31 Jan 2022 11:56:37 +0100 Message-Id: <20220131105222.987434426@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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 [ Upstream commit 2c13c05c5ff4b9fc907b07f7311821910ebaaf8a ] Improve retransmission backoff by only backing off when we retransmit data packets rather than when we set the lost ack timer. To this end: (1) In rxrpc_resend(), use rxrpc_get_rto_backoff() when setting the retransmission timer and only tell it that we are retransmitting if we actually have things to retransmit. Note that it's possible for the retransmission algorithm to race with the processing of a received ACK, so we may see no packets needing retransmission. (2) In rxrpc_send_data_packet(), don't bump the backoff when setting the ack_lost_at timer, as it may then get bumped twice. With this, when looking at one particular packet, the retransmission intervals were seen to be 1.5ms, 2ms, 3ms, 5ms, 9ms, 17ms, 33ms, 71ms, 136ms, 264ms, 544ms, 1.088s, 2.1s, 4.2s and 8.3s. Fixes: c410bf01933e ("rxrpc: Fix the excessive initial retransmission timeo= ut") Suggested-by: Marc Dionne Signed-off-by: David Howells Reviewed-by: Marc Dionne Tested-by: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/164138117069.2023386.17446904856843997127.s= tgit@warthog.procyon.org.uk/ Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/rxrpc/call_event.c | 8 +++----- net/rxrpc/output.c | 2 +- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c index 6be2672a65eab..df864e6922679 100644 --- a/net/rxrpc/call_event.c +++ b/net/rxrpc/call_event.c @@ -157,7 +157,7 @@ static void rxrpc_congestion_timeout(struct rxrpc_call = *call) static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j) { struct sk_buff *skb; - unsigned long resend_at, rto_j; + unsigned long resend_at; rxrpc_seq_t cursor, seq, top; ktime_t now, max_age, oldest, ack_ts; int ix; @@ -165,10 +165,8 @@ static void rxrpc_resend(struct rxrpc_call *call, unsi= gned long now_j) =20 _enter("{%d,%d}", call->tx_hard_ack, call->tx_top); =20 - rto_j =3D call->peer->rto_j; - now =3D ktime_get_real(); - max_age =3D ktime_sub(now, jiffies_to_usecs(rto_j)); + max_age =3D ktime_sub(now, jiffies_to_usecs(call->peer->rto_j)); =20 spin_lock_bh(&call->lock); =20 @@ -213,7 +211,7 @@ static void rxrpc_resend(struct rxrpc_call *call, unsig= ned long now_j) } =20 resend_at =3D nsecs_to_jiffies(ktime_to_ns(ktime_sub(now, oldest))); - resend_at +=3D jiffies + rto_j; + resend_at +=3D jiffies + rxrpc_get_rto_backoff(call->peer, retrans); WRITE_ONCE(call->resend_at, resend_at); =20 if (unacked) diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index 10f2bf2e9068a..a45c83f22236e 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -468,7 +468,7 @@ done: if (call->peer->rtt_count > 1) { unsigned long nowj =3D jiffies, ack_lost_at; =20 - ack_lost_at =3D rxrpc_get_rto_backoff(call->peer, retrans); + ack_lost_at =3D rxrpc_get_rto_backoff(call->peer, false); ack_lost_at +=3D nowj; WRITE_ONCE(call->ack_lost_at, ack_lost_at); rxrpc_reduce_call_timer(call, ack_lost_at, nowj, --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 BA9C5C35268 for ; Mon, 31 Jan 2022 11:13:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376818AbiAaLNU (ORCPT ); Mon, 31 Jan 2022 06:13:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377243AbiAaLJu (ORCPT ); Mon, 31 Jan 2022 06:09:50 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0493FC0613A2; Mon, 31 Jan 2022 03:06:45 -0800 (PST) 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 B8284B82A5C; Mon, 31 Jan 2022 11:06:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 034D4C340EE; Mon, 31 Jan 2022 11:06:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627202; bh=Bw3JlHcsA59KK7BZytbzclqcj9Dlm72ho+5EOc7ejeo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v2S3I6uyYBNZK0LZYJ9zCPMhA+Adp7vsF0e3DmUQ3F7OxNB+vxSFJ/mjAKTvzYjsY J7EpU9iDUJJlPmY2Kz3BDred7pNWOVqx5BIoFzskva1cTXjc3TcfQ6yMBmidSzS0pr KWim36KzvLW67kt7E6JB1HVLvU3BtsJ9hSbExu78= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mihai Carabas , Ard Biesheuvel , Sasha Levin Subject: [PATCH 5.10 077/100] efi/libstub: arm64: Fix image check alignment at entry Date: Mon, 31 Jan 2022 11:56:38 +0100 Message-Id: <20220131105223.021387714@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Mihai Carabas [ Upstream commit e9b7c3a4263bdcfd31bc3d03d48ce0ded7a94635 ] The kernel is aligned at SEGMENT_SIZE and this is the size populated in the= PE headers: arch/arm64/kernel/efi-header.S: .long SEGMENT_ALIGN // SectionAlignment EFI_KIMG_ALIGN is defined as: (SEGMENT_ALIGN > THREAD_ALIGN ? SEGMENT_ALIGN= : THREAD_ALIGN) So it depends on THREAD_ALIGN. On newer builds this message started to appe= ar even though the loader is taking into account the PE header (which is stati= ng SEGMENT_ALIGN). Fixes: c32ac11da3f8 ("efi/libstub: arm64: Double check image alignment at e= ntry") Signed-off-by: Mihai Carabas Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/firmware/efi/libstub/arm64-stub.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/e= fi/libstub/arm64-stub.c index c1b57dfb12776..415a971e76947 100644 --- a/drivers/firmware/efi/libstub/arm64-stub.c +++ b/drivers/firmware/efi/libstub/arm64-stub.c @@ -119,9 +119,9 @@ efi_status_t handle_kernel_image(unsigned long *image_a= ddr, if (image->image_base !=3D _text) efi_err("FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value\n"= ); =20 - if (!IS_ALIGNED((u64)_text, EFI_KIMG_ALIGN)) - efi_err("FIRMWARE BUG: kernel image not aligned on %ldk boundary\n", - EFI_KIMG_ALIGN >> 10); + if (!IS_ALIGNED((u64)_text, SEGMENT_ALIGN)) + efi_err("FIRMWARE BUG: kernel image not aligned on %dk boundary\n", + SEGMENT_ALIGN >> 10); =20 kernel_size =3D _edata - _text; kernel_memsize =3D kernel_size + (_end - _edata); --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 1BBBDC4167D for ; Mon, 31 Jan 2022 11:10:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376453AbiAaLI3 (ORCPT ); Mon, 31 Jan 2022 06:08:29 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:39646 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359331AbiAaLFM (ORCPT ); Mon, 31 Jan 2022 06:05:12 -0500 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 0425F60FD2; Mon, 31 Jan 2022 11:05:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4085C340E8; Mon, 31 Jan 2022 11:05:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627111; bh=z3hZqaG3OAOpTGubGmzQdXcuX5HhIvzRJ1/enbB/OB0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nnvBcVYL9CGRZSiqjq9I/ROrQjPTTpN0pU51B8L0iwuaZQBJxmurYBdb+LzAxvSyn wQpbxBExEnt+qQGF8I9bxxMYi2bnbQErfPSQ1huQEYHaOHwj+rphs4jvncT9q7HQ9k ufUkkHQTkOHgk/muabH4WuZ2c/r8RQvwE+BSvoN8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Lehan , Guenter Roeck , Sasha Levin Subject: [PATCH 5.10 078/100] hwmon: (lm90) Mark alert as broken for MAX6654 Date: Mon, 31 Jan 2022 11:56:39 +0100 Message-Id: <20220131105223.055021917@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Guenter Roeck [ Upstream commit a53fff96f35763d132a36c620b183fdf11022d7a ] Experiments with MAX6654 show that its alert function is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver") Cc: Josh Lehan Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hwmon/lm90.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c index fef02bcfedbcf..6841d0401bbd4 100644 --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -400,6 +400,7 @@ static const struct lm90_params lm90_params[] =3D { .reg_local_ext =3D MAX6657_REG_R_LOCAL_TEMPL, }, [max6654] =3D { + .flags =3D LM90_HAVE_BROKEN_ALERT, .alert_alarms =3D 0x7c, .max_convrate =3D 7, .reg_local_ext =3D MAX6657_REG_R_LOCAL_TEMPL, --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 037FAC433F5 for ; Mon, 31 Jan 2022 11:10:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376470AbiAaLIb (ORCPT ); Mon, 31 Jan 2022 06:08:31 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53200 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359357AbiAaLFR (ORCPT ); Mon, 31 Jan 2022 06:05:17 -0500 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 9A4E8B82A5E; Mon, 31 Jan 2022 11:05:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAA41C340E8; Mon, 31 Jan 2022 11:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627114; bh=UZqAeWaT4UU0ub23NmEW130ffEa5NGj+ACSVG0Tkre8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XNr/BTh28u2Lmv5Vn95gAayqgrWbI4lGA82hJcryCnk2pSGvRmwBANmH5c9b5wa6B htT1rqTWVHLmlLtGLwmYKmz32VyROOsFfseoKXvZ7BLGybsaNsqMNQyZ3u9Bvtg9jN nmDbjwwusK5O5c0Xl6JmH9EIf2pGQXc30JVY2R/M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sachin Sant , Athira Rajeev , Nicholas Piggin , Michael Ellerman , Sasha Levin Subject: [PATCH 5.10 079/100] powerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending Date: Mon, 31 Jan 2022 11:56:40 +0100 Message-Id: <20220131105223.086890433@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Athira Rajeev [ Upstream commit fb6433b48a178d4672cb26632454ee0b21056eaa ] Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel triggered below warning: [ 172.851380] ------------[ cut here ]------------ [ 172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq= .h:246 power_pmu_disable+0x270/0x280 [ 172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_def= rag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc= 32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables e= xt4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse [ 172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc= 5-03218-g798527287598 #2 [ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c0000000001= 3b180 [ 172.851458] REGS: c000000017687860 TRAP: 0700 Not tainted (5.16.0-rc5= -03218-g798527287598) [ 172.851465] MSR: 8000000000029033 CR: 48004884 = XER: 20040000 [ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1 [ 172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 00= 00000000000004 [ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00= 000008b7ed0000 [ 172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c0= 00000000d58e68 [ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 00= 00000000000000 [ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0= 000000025396d0 [ 172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 00= 00000000000003 [ 172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c0= 0000000a3bb600 [ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0= 000008ba0020d8 [ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280 [ 172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280 [ 172.851565] Call Trace: [ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x21= 4/0x280 (unreliable) [ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/= 0x60 [ 172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sche= d_out+0x1d4/0x660 [ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0 [ 172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140 [ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0= x40 [ 172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+= 0x18c/0x380 [ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xe= c/0x268 The warning indicates that MSR_EE being set(interrupt enabled) when there was an overflown PMC detected. This could happen in power_pmu_disable since it runs under interrupt soft disable condition ( local_irq_save ) and not with interrupts hard disabled. commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") intended to clear PMI pending bit in Paca when disabling the PMU. It could happen that PMC gets overflown while code is in power_pmu_disable callback function. Hence add a check to see if PMI pending bit is set in Paca before clearing it via clear_pmi_pending. Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI = before resetting an overflown PMC") Reported-by: Sachin Sant Signed-off-by: Athira Rajeev Tested-by: Sachin Sant Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220122033429.25395-1-atrajeev@linux.vnet.= ibm.com Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/powerpc/perf/core-book3s.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3= s.c index bd34e062bd290..e49aa8fc6a491 100644 --- a/arch/powerpc/perf/core-book3s.c +++ b/arch/powerpc/perf/core-book3s.c @@ -1273,9 +1273,20 @@ static void power_pmu_disable(struct pmu *pmu) * Otherwise provide a warning if there is PMI pending, but * no counter is found overflown. */ - if (any_pmc_overflown(cpuhw)) - clear_pmi_irq_pending(); - else + if (any_pmc_overflown(cpuhw)) { + /* + * Since power_pmu_disable runs under local_irq_save, it + * could happen that code hits a PMC overflow without PMI + * pending in paca. Hence only clear PMI pending if it was + * set. + * + * If a PMI is pending, then MSR[EE] must be disabled (because + * the masked PMI handler disabling EE). So it is safe to + * call clear_pmi_irq_pending(). + */ + if (pmi_irq_pending()) + clear_pmi_irq_pending(); + } else WARN_ON(pmi_irq_pending()); =20 val =3D mmcra =3D cpuhw->mmcr.mmcra; --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 5FB79C4332F for ; Mon, 31 Jan 2022 11:12:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359838AbiAaLMN (ORCPT ); Mon, 31 Jan 2022 06:12:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376504AbiAaLIe (ORCPT ); Mon, 31 Jan 2022 06:08:34 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C859BC0619C0; Mon, 31 Jan 2022 03:05:19 -0800 (PST) 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 92001B82A5F; Mon, 31 Jan 2022 11:05:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA563C340E8; Mon, 31 Jan 2022 11:05:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627117; bh=I0uXQkDbhcrgFlOrWUKs2lEyJYwQN3pii/jlSjzk5Z0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v4YoXnq0U2NoZGCn/J83NydPWzjXIUpBk7HxFCNFazQZHnR5MOqWrTezbOYQbuO1l PMK+shbyDDOGR4JLMQOp5nlPVJUPAX/KN9wTXtFS5eB5F3VPFtcejR7SajtBMrsLrc YlOMVIVvPlvVtQVOfbU5lcPDNdxE73QxFPtVmVGw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yajun Deng , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 080/100] net: ipv4: Move ip_options_fragment() out of loop Date: Mon, 31 Jan 2022 11:56:41 +0100 Message-Id: <20220131105223.127439495@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Yajun Deng [ Upstream commit faf482ca196a5b16007190529b3b2dd32ab3f761 ] The ip_options_fragment() only called when iter->offset is equal to zero, so move it out of loop, and inline 'Copy the flags to each fragment.' As also, remove the unused parameter in ip_frag_ipcb(). Signed-off-by: Yajun Deng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv4/ip_output.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 10d4cde31c6bf..fb91a466b2d34 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -614,18 +614,6 @@ void ip_fraglist_init(struct sk_buff *skb, struct iphd= r *iph, } EXPORT_SYMBOL(ip_fraglist_init); =20 -static void ip_fraglist_ipcb_prepare(struct sk_buff *skb, - struct ip_fraglist_iter *iter) -{ - struct sk_buff *to =3D iter->frag; - - /* Copy the flags to each fragment. */ - IPCB(to)->flags =3D IPCB(skb)->flags; - - if (iter->offset =3D=3D 0) - ip_options_fragment(to); -} - void ip_fraglist_prepare(struct sk_buff *skb, struct ip_fraglist_iter *ite= r) { unsigned int hlen =3D iter->hlen; @@ -671,7 +659,7 @@ void ip_frag_init(struct sk_buff *skb, unsigned int hle= n, EXPORT_SYMBOL(ip_frag_init); =20 static void ip_frag_ipcb(struct sk_buff *from, struct sk_buff *to, - bool first_frag, struct ip_frag_state *state) + bool first_frag) { /* Copy the flags to each fragment. */ IPCB(to)->flags =3D IPCB(from)->flags; @@ -845,12 +833,13 @@ int ip_do_fragment(struct net *net, struct sock *sk, = struct sk_buff *skb, =20 /* Everything is OK. Generate! */ ip_fraglist_init(skb, iph, hlen, &iter); + ip_options_fragment(iter.frag); =20 for (;;) { /* Prepare header of the next frame, * before previous one went down. */ if (iter.frag) { - ip_fraglist_ipcb_prepare(skb, &iter); + IPCB(iter.frag)->flags =3D IPCB(skb)->flags; ip_fraglist_prepare(skb, &iter); } =20 @@ -905,7 +894,7 @@ slow_path: err =3D PTR_ERR(skb2); goto fail; } - ip_frag_ipcb(skb, skb2, first_frag, &state); + ip_frag_ipcb(skb, skb2, first_frag); =20 /* * Put this fragment into the sending queue. --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 0C902C4332F for ; Mon, 31 Jan 2022 11:10:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376496AbiAaLId (ORCPT ); Mon, 31 Jan 2022 06:08:33 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38682 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358994AbiAaLFV (ORCPT ); Mon, 31 Jan 2022 06:05:21 -0500 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 1207360B98; Mon, 31 Jan 2022 11:05:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0558BC340EF; Mon, 31 Jan 2022 11:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627120; bh=hRGw969o3xfx3kaJXxvceU8n0eam0mIvnot3klzJX4g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YkZSV1x0U2qugzhKdw2ieREP3/qwmM4D5ggY8m//DZdbjNcUecLBEbov9uzIY2Yc/ HTnA9RgoqgCyue1AP8/RmAS1rTH7RtVYsh+8zaFzNn8cT2MgAj6NBJ/81Bv42eUSaN DuYh8Yqs2pZnpGynlu8q26Cf7Znwue4QGTCKBoVo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Yajun Deng , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 081/100] net: ipv4: Fix the warning for dereference Date: Mon, 31 Jan 2022 11:56:42 +0100 Message-Id: <20220131105223.166114763@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Yajun Deng [ Upstream commit 1b9fbe813016b08e08b22ddba4ddbf9cb1b04b00 ] Add a if statements to avoid the warning. Dan Carpenter report: The patch faf482ca196a: "net: ipv4: Move ip_options_fragment() out of loop" from Aug 23, 2021, leads to the following Smatch complaint: net/ipv4/ip_output.c:833 ip_do_fragment() warn: variable dereferenced before check 'iter.frag' (see line 828) Reported-by: Dan Carpenter Fixes: faf482ca196a ("net: ipv4: Move ip_options_fragment() out of loop") Link: https://lore.kernel.org/netdev/20210830073802.GR7722@kadam/T/#t Signed-off-by: Yajun Deng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv4/ip_output.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index fb91a466b2d34..e77afaecc9818 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -833,7 +833,9 @@ int ip_do_fragment(struct net *net, struct sock *sk, st= ruct sk_buff *skb, =20 /* Everything is OK. Generate! */ ip_fraglist_init(skb, iph, hlen, &iter); - ip_options_fragment(iter.frag); + + if (iter.frag) + ip_options_fragment(iter.frag); =20 for (;;) { /* Prepare header of the next frame, --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 B1E99C433EF for ; Mon, 31 Jan 2022 11:10:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376534AbiAaLIg (ORCPT ); Mon, 31 Jan 2022 06:08:36 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:39888 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359393AbiAaLFY (ORCPT ); Mon, 31 Jan 2022 06:05:24 -0500 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 195F960B28; Mon, 31 Jan 2022 11:05:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9239C340E8; Mon, 31 Jan 2022 11:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627123; bh=PvqhyxCJZxpLaJ8L1wBqus7S7SnmSWuGiwYAapgizFM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a48DE/2OobGJM0F/OnQfi9Z8QQt6RZhnreEaMhXkadtHC34X5vQvLVBKXa7KZHz7z /M+s8+HNFsL9n+NKhy0hcrMr2mL+Mc1iJHDBeoYjDFkcKt/fA+Sh2vR3PAzatRW55G 8609n/2esPXaigPtG/ywCs9qHvT0/iKO6umbvEUY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, caixf , Jakub Kicinski , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 082/100] ipv4: fix ip option filtering for locally generated fragments Date: Mon, 31 Jan 2022 11:56:43 +0100 Message-Id: <20220131105223.204395895@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jakub Kicinski [ Upstream commit 27a8caa59babb96c5890569e131bc0eb6d45daee ] During IP fragmentation we sanitize IP options. This means overwriting options which should not be copied with NOPs. Only the first fragment has the original, full options. ip_fraglist_prepare() copies the IP header and options from previous fragment to the next one. Commit 19c3401a917b ("net: ipv4: place control buffer handling away from fragmentation iterators") moved sanitizing options before ip_fraglist_prepare() which means options are sanitized and then overwritten again with the old values. Fixing this is not enough, however, nor did the sanitization work prior to aforementioned commit. ip_options_fragment() (which does the sanitization) uses ipcb->opt.optlen for the length of the options. ipcb->opt of fragments is not populated (it's 0), only the head skb has the state properly built. So even when called at the right time ip_options_fragment() does nothing. This seems to date back all the way to v2.5.44 when the fast path for pre-fragmented skbs had been introduced. Prior to that ip_options_build() would have been called for every fragment (in fact ever since v2.5.44 the fragmentation handing in ip_options_build() has been dead code, I'll clean it up in -next). In the original patch (see Link) caixf mentions fixing the handling for fragments other than the second one, but I'm not sure how _any_ fragment could have had their options sanitized with the code as it stood. Tested with python (MTU on lo lowered to 1000 to force fragmentation): import socket s =3D socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS, bytearray([7,4,5,192, 20|0x80,4,1,0])) s.sendto(b'1'*2000, ('127.0.0.1', 1234)) Before: IP (tos 0x0, ttl 64, id 1053, offset 0, flags [+], proto UDP (17), length 9= 96, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256)) localhost.36500 > localhost.search-agent: UDP, length 2000 IP (tos 0x0, ttl 64, id 1053, offset 968, flags [+], proto UDP (17), length= 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256)) localhost > localhost: udp IP (tos 0x0, ttl 64, id 1053, offset 1936, flags [none], proto UDP (17), le= ngth 100, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256)) localhost > localhost: udp After: IP (tos 0x0, ttl 96, id 42549, offset 0, flags [+], proto UDP (17), length = 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256)) localhost.51607 > localhost.search-agent: UDP, bad length 2000 > 960 IP (tos 0x0, ttl 96, id 42549, offset 968, flags [+], proto UDP (17), lengt= h 996, options (NOP,NOP,NOP,NOP,RA value 256)) localhost > localhost: udp IP (tos 0x0, ttl 96, id 42549, offset 1936, flags [none], proto UDP (17), l= ength 100, options (NOP,NOP,NOP,NOP,RA value 256)) localhost > localhost: udp RA (20 | 0x80) is now copied as expected, RR (7) is "NOPed out". Link: https://lore.kernel.org/netdev/20220107080559.122713-1-ooppublic@163.= com/ Fixes: 19c3401a917b ("net: ipv4: place control buffer handling away from fr= agmentation iterators") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: caixf Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv4/ip_output.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index e77afaecc9818..4f76e8183f403 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -834,15 +834,24 @@ int ip_do_fragment(struct net *net, struct sock *sk, = struct sk_buff *skb, /* Everything is OK. Generate! */ ip_fraglist_init(skb, iph, hlen, &iter); =20 - if (iter.frag) - ip_options_fragment(iter.frag); - for (;;) { /* Prepare header of the next frame, * before previous one went down. */ if (iter.frag) { + bool first_frag =3D (iter.offset =3D=3D 0); + IPCB(iter.frag)->flags =3D IPCB(skb)->flags; ip_fraglist_prepare(skb, &iter); + if (first_frag && IPCB(skb)->opt.optlen) { + /* ipcb->opt is not populated for frags + * coming from __ip_make_skb(), + * ip_options_fragment() needs optlen + */ + IPCB(iter.frag)->opt.optlen =3D + IPCB(skb)->opt.optlen; + ip_options_fragment(iter.frag); + ip_send_check(iter.iph); + } } =20 skb->tstamp =3D tstamp; --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 A31EBC4332F for ; Mon, 31 Jan 2022 11:12:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376311AbiAaLM1 (ORCPT ); Mon, 31 Jan 2022 06:12:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376614AbiAaLIm (ORCPT ); Mon, 31 Jan 2022 06:08:42 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21C05C0619D0; Mon, 31 Jan 2022 03:05:29 -0800 (PST) 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 BB32EB82A5F; Mon, 31 Jan 2022 11:05:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3C31C340E8; Mon, 31 Jan 2022 11:05:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627126; bh=gzbIsjtQpfVOlvuIIXAoK1Ll7cxgvVQq1fRslI9n4/E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tVkHloly3ci8jzwUKya/z486yM1teLiOLny+cWO07+dotZc4B2qgBrh45k6P1wVAi 1//ySqqnO4eTtf6cowunRbGsdQafpcJVeYDYBudGwzOZdGMb6u8v+HPJYEJPzUXzt9 OOidsRS70Uc+gd3h0Ik503mp2RgllGoXw4OTvkkY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sukadev Bhattiprolu , Dany Madden , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 083/100] ibmvnic: init ->running_cap_crqs early Date: Mon, 31 Jan 2022 11:56:44 +0100 Message-Id: <20220131105223.242124271@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Sukadev Bhattiprolu [ Upstream commit 151b6a5c06b678687f64f2d9a99fd04d5cd32b72 ] We use ->running_cap_crqs to determine when the ibmvnic_tasklet() should send out the next protocol message type. i.e when we get back responses to all our QUERY_CAPABILITY CRQs we send out REQUEST_CAPABILITY crqs. Similiary, when we get responses to all the REQUEST_CAPABILITY crqs, we send out the QUERY_IP_OFFLOAD CRQ. We currently increment ->running_cap_crqs as we send out each CRQ and have the ibmvnic_tasklet() send out the next message type, when this running_cap_crqs count drops to 0. This assumes that all the CRQs of the current type were sent out before the count drops to 0. However it is possible that we send out say 6 CRQs, get preempted and receive all the 6 responses before we send out the remaining CRQs. This can result in ->running_cap_crqs count dropping to zero before all messages of the current type were sent and we end up sending the next protocol message too early. Instead initialize the ->running_cap_crqs upfront so the tasklet will only send the next protocol message after all responses are received. Use the cap_reqs local variable to also detect any discrepancy (either now or in future) in the number of capability requests we actually send. Currently only send_query_cap() is affected by this behavior (of sending next message early) since it is called from the worker thread (during reset) and from application thread (during ->ndo_open()) and they can be preempted. send_request_cap() is only called from the tasklet which processes CRQ responses sequentially, is not be affected. But to maintain the existing symmtery with send_query_capability() we update send_request_capability() also. Fixes: 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capa= bilities crqs") Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/ibm/ibmvnic.c | 106 +++++++++++++++++++---------- 1 file changed, 71 insertions(+), 35 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/= ibmvnic.c index 4f99d97638248..232c68af4c60a 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -3401,11 +3401,25 @@ static void send_request_cap(struct ibmvnic_adapter= *adapter, int retry) struct device *dev =3D &adapter->vdev->dev; union ibmvnic_crq crq; int max_entries; + int cap_reqs; + + /* We send out 6 or 7 REQUEST_CAPABILITY CRQs below (depending on + * the PROMISC flag). Initialize this count upfront. When the tasklet + * receives a response to all of these, it will send the next protocol + * message (QUERY_IP_OFFLOAD). + */ + if (!(adapter->netdev->flags & IFF_PROMISC) || + adapter->promisc_supported) + cap_reqs =3D 7; + else + cap_reqs =3D 6; =20 if (!retry) { /* Sub-CRQ entries are 32 byte long */ int entries_page =3D 4 * PAGE_SIZE / (sizeof(u64) * 4); =20 + atomic_set(&adapter->running_cap_crqs, cap_reqs); + if (adapter->min_tx_entries_per_subcrq > entries_page || adapter->min_rx_add_entries_per_subcrq > entries_page) { dev_err(dev, "Fatal, invalid entries per sub-crq\n"); @@ -3466,44 +3480,45 @@ static void send_request_cap(struct ibmvnic_adapter= *adapter, int retry) adapter->opt_rx_comp_queues; =20 adapter->req_rx_add_queues =3D adapter->max_rx_add_queues; + } else { + atomic_add(cap_reqs, &adapter->running_cap_crqs); } - memset(&crq, 0, sizeof(crq)); crq.request_capability.first =3D IBMVNIC_CRQ_CMD; crq.request_capability.cmd =3D REQUEST_CAPABILITY; =20 crq.request_capability.capability =3D cpu_to_be16(REQ_TX_QUEUES); crq.request_capability.number =3D cpu_to_be64(adapter->req_tx_queues); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_RX_QUEUES); crq.request_capability.number =3D cpu_to_be64(adapter->req_rx_queues); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_RX_ADD_QUEUES); crq.request_capability.number =3D cpu_to_be64(adapter->req_rx_add_queues); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_TX_ENTRIES_PER_SUBCRQ); crq.request_capability.number =3D cpu_to_be64(adapter->req_tx_entries_per_subcrq); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_RX_ADD_ENTRIES_PER_SUBCRQ); crq.request_capability.number =3D cpu_to_be64(adapter->req_rx_add_entries_per_subcrq); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_MTU); crq.request_capability.number =3D cpu_to_be64(adapter->req_mtu); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 if (adapter->netdev->flags & IFF_PROMISC) { @@ -3511,16 +3526,21 @@ static void send_request_cap(struct ibmvnic_adapter= *adapter, int retry) crq.request_capability.capability =3D cpu_to_be16(PROMISC_REQUESTED); crq.request_capability.number =3D cpu_to_be64(1); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); } } else { crq.request_capability.capability =3D cpu_to_be16(PROMISC_REQUESTED); crq.request_capability.number =3D cpu_to_be64(0); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); } + + /* Keep at end to catch any discrepancy between expected and actual + * CRQs sent. + */ + WARN_ON(cap_reqs !=3D 0); } =20 static int pending_scrq(struct ibmvnic_adapter *adapter, @@ -3953,118 +3973,132 @@ static void send_query_map(struct ibmvnic_adapter= *adapter) static void send_query_cap(struct ibmvnic_adapter *adapter) { union ibmvnic_crq crq; + int cap_reqs; + + /* We send out 25 QUERY_CAPABILITY CRQs below. Initialize this count + * upfront. When the tasklet receives a response to all of these, it + * can send out the next protocol messaage (REQUEST_CAPABILITY). + */ + cap_reqs =3D 25; + + atomic_set(&adapter->running_cap_crqs, cap_reqs); =20 - atomic_set(&adapter->running_cap_crqs, 0); memset(&crq, 0, sizeof(crq)); crq.query_capability.first =3D IBMVNIC_CRQ_CMD; crq.query_capability.cmd =3D QUERY_CAPABILITY; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_TX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_RX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_RX_ADD_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_TX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_RX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_RX_ADD_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_TX_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_RX_ADD_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_TX_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_RX_ADD_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(TCP_IP_OFFLOAD); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(PROMISC_SUPPORTED); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_MTU); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_MTU); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_MULTICAST_FILTERS); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(VLAN_HEADER_INSERTION); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(RX_VLAN_HEADER_INSERTION); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_TX_SG_ENTRIES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(RX_SG_SUPPORTED); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_TX_COMP_SUB_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_RX_COMP_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_RX_BUFADD_Q_PER_RX_COMP_Q); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_TX_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_RXBA_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(TX_RX_DESC_REQ); - atomic_inc(&adapter->running_cap_crqs); + ibmvnic_send_crq(adapter, &crq); + cap_reqs--; + + /* Keep at end to catch any discrepancy between expected and actual + * CRQs sent. + */ + WARN_ON(cap_reqs !=3D 0); } =20 static void send_query_ip_offload(struct ibmvnic_adapter *adapter) @@ -4369,6 +4403,8 @@ static void handle_request_cap_rsp(union ibmvnic_crq = *crq, char *name; =20 atomic_dec(&adapter->running_cap_crqs); + netdev_dbg(adapter->netdev, "Outstanding request-caps: %d\n", + atomic_read(&adapter->running_cap_crqs)); switch (be16_to_cpu(crq->request_capability_rsp.capability)) { case REQ_TX_QUEUES: req_value =3D &adapter->req_tx_queues; --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 3F534C3525A for ; Mon, 31 Jan 2022 11:10:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376564AbiAaLIh (ORCPT ); Mon, 31 Jan 2022 06:08:37 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53422 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359429AbiAaLFc (ORCPT ); Mon, 31 Jan 2022 06:05:32 -0500 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 D812CB82A5F; Mon, 31 Jan 2022 11:05:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00BA6C340EF; Mon, 31 Jan 2022 11:05:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627129; bh=ae8R5cR9og/FxynuOn/VIw3QPeA3VAi0XqcCVhZbz3A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1uacvQwVTPGI6SjWRLWx/D3oAEFcUug3cFDuhkKuERWG1q5cgmld+MWY4G1FlU9Ul 4Q/nJ6VPdBclrygP59EMd9f9RYuPc29f2XzaJDu2ijaNu7JqrrfMQ9PmEIyILE5xHI NgjsxxpalgOkLg3tOpGYUeDUBJQsvj6fgHGvQ3vw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sukadev Bhattiprolu , Dany Madden , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 084/100] ibmvnic: dont spin in tasklet Date: Mon, 31 Jan 2022 11:56:45 +0100 Message-Id: <20220131105223.274263195@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Sukadev Bhattiprolu [ Upstream commit 48079e7fdd0269d66b1d7d66ae88bd03162464ad ] ibmvnic_tasklet() continuously spins waiting for responses to all capability requests. It does this to avoid encountering an error during initialization of the vnic. However if there is a bug in the VIOS and we do not receive a response to one or more queries the tasklet ends up spinning continuously leading to hard lock ups. If we fail to receive a message from the VIOS it is reasonable to timeout the login attempt rather than spin indefinitely in the tasklet. Fixes: 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capa= bilities crqs") Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/ibm/ibmvnic.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/= ibmvnic.c index 232c68af4c60a..c7be7ab131b19 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -5075,12 +5075,6 @@ static void ibmvnic_tasklet(struct tasklet_struct *t) ibmvnic_handle_crq(crq, adapter); crq->generic.first =3D 0; } - - /* remain in tasklet until all - * capabilities responses are received - */ - if (!adapter->wait_capability) - done =3D true; } /* if capabilities CRQ's were sent in this tasklet, the following * tasklet must wait until all responses are received --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 3E527C433FE for ; Mon, 31 Jan 2022 11:10:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376590AbiAaLIk (ORCPT ); Mon, 31 Jan 2022 06:08:40 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:52194 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244106AbiAaLFg (ORCPT ); Mon, 31 Jan 2022 06:05:36 -0500 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 E2CDDB82A69; Mon, 31 Jan 2022 11:05:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 026AAC340E8; Mon, 31 Jan 2022 11:05:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627132; bh=ST2g1u3enQMTIQJwFsAGphaXguH4KWHUMg1J47wQY6M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=in68ONs0jGke3eOPcjSU+knQINYhn40HGs+phqbnZQPSAk/NNW+kyvW+CtmX35vqL AMsBVox1APV5gZK8ygXlLX1DMXv1EKwVd3C+yRe6l13kl8phibAWrGA+YuuKZwJA9m rVXZwRO+v5nAunOk9TvcCcgMqNf8QDwnGe0FrgUo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Kelley , Haiyang Zhang , Helge Deller , Wei Liu , Sasha Levin Subject: [PATCH 5.10 085/100] video: hyperv_fb: Fix validation of screen resolution Date: Mon, 31 Jan 2022 11:56:46 +0100 Message-Id: <20220131105223.314368801@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Michael Kelley [ Upstream commit 9ff5549b1d1d3c3a9d71220d44bd246586160f1d ] In the WIN10 version of the Synthetic Video protocol with Hyper-V, Hyper-V reports a list of supported resolutions as part of the protocol negotiation. The driver calculates the maximum width and height from the list of resolutions, and uses those maximums to validate any screen resolution specified in the video=3D option on the kernel boot line. This method of validation is incorrect. For example, the list of supported resolutions could contain 1600x1200 and 1920x1080, both of which fit in an 8 Mbyte frame buffer. But calculating the max width and height yields 1920 and 1200, and 1920x1200 resolution does not fit in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted, causing a kernel fault when the driver accesses memory outside the frame buffer. Instead, validate the specified screen resolution by calculating its size, and comparing against the frame buffer size. Delete the code for calculating the max width and height from the list of resolutions, since these max values have no use. Also add the frame buffer size to the info message to aid in understanding why a resolution might be rejected. Fixes: 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen resolution fr= om Hyper-V host") Signed-off-by: Michael Kelley Reviewed-by: Haiyang Zhang Acked-by: Helge Deller Link: https://lore.kernel.org/r/1642360711-2335-1-git-send-email-mikelley@m= icrosoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/video/fbdev/hyperv_fb.c | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_f= b.c index 4dc9077dd2ac0..3c309ab208874 100644 --- a/drivers/video/fbdev/hyperv_fb.c +++ b/drivers/video/fbdev/hyperv_fb.c @@ -286,8 +286,6 @@ struct hvfb_par { =20 static uint screen_width =3D HVFB_WIDTH; static uint screen_height =3D HVFB_HEIGHT; -static uint screen_width_max =3D HVFB_WIDTH; -static uint screen_height_max =3D HVFB_HEIGHT; static uint screen_depth; static uint screen_fb_size; static uint dio_fb_size; /* FB size for deferred IO */ @@ -581,7 +579,6 @@ static int synthvid_get_supported_resolution(struct hv_= device *hdev) int ret =3D 0; unsigned long t; u8 index; - int i; =20 memset(msg, 0, sizeof(struct synthvid_msg)); msg->vid_hdr.type =3D SYNTHVID_RESOLUTION_REQUEST; @@ -612,13 +609,6 @@ static int synthvid_get_supported_resolution(struct hv= _device *hdev) goto out; } =20 - for (i =3D 0; i < msg->resolution_resp.resolution_count; i++) { - screen_width_max =3D max_t(unsigned int, screen_width_max, - msg->resolution_resp.supported_resolution[i].width); - screen_height_max =3D max_t(unsigned int, screen_height_max, - msg->resolution_resp.supported_resolution[i].height); - } - screen_width =3D msg->resolution_resp.supported_resolution[index].width; screen_height =3D @@ -940,7 +930,7 @@ static void hvfb_get_option(struct fb_info *info) =20 if (x < HVFB_WIDTH_MIN || y < HVFB_HEIGHT_MIN || (synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10) && - (x > screen_width_max || y > screen_height_max)) || + (x * y * screen_depth / 8 > screen_fb_size)) || (par->synthvid_version =3D=3D SYNTHVID_VERSION_WIN8 && x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8) || (par->synthvid_version =3D=3D SYNTHVID_VERSION_WIN7 && @@ -1193,8 +1183,8 @@ static int hvfb_probe(struct hv_device *hdev, } =20 hvfb_get_option(info); - pr_info("Screen resolution: %dx%d, Color depth: %d\n", - screen_width, screen_height, screen_depth); + pr_info("Screen resolution: %dx%d, Color depth: %d, Frame buffer size: %d= \n", + screen_width, screen_height, screen_depth, screen_fb_size); =20 ret =3D hvfb_getmem(hdev, info); if (ret) { --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 6E384C433EF for ; Mon, 31 Jan 2022 11:12:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376394AbiAaLMh (ORCPT ); Mon, 31 Jan 2022 06:12:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376816AbiAaLJJ (ORCPT ); Mon, 31 Jan 2022 06:09:09 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F0D3C061A27; Mon, 31 Jan 2022 03:05:36 -0800 (PST) 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 202B260FB5; Mon, 31 Jan 2022 11:05:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03DB3C340EF; Mon, 31 Jan 2022 11:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627135; bh=rPxomZGLw2T0AeFweigh+gNKt3+WX6XmgfGi+QBKnqY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kW1OVtmxFxyqkLQP6VVYZKwHTEcGd5II8dTE6mV6EJLuVhjIWEHRTsUCcLJu/0wN5 +vJtSo7E3ZX63QtoKj05Oq24nwASYc8IpnR1FIUau/KCO8nuCOvxcLUaerD0IzM3yG LiTJaxrTFbAKUvOynWZ7CSVXpTZeoJmeUqI5RYFs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miaoqian Lin , Dmitry Baryshkov , Sasha Levin Subject: [PATCH 5.10 086/100] drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phy Date: Mon, 31 Jan 2022 11:56:47 +0100 Message-Id: <20220131105223.346360687@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Miaoqian Lin [ Upstream commit 774fe0cd838d1b1419d41ab4ea0613c80d4ecbd7 ] The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling path. Fixes: e00012b256d4 ("drm/msm/hdmi: Make HDMI core get its PHY") Signed-off-by: Miaoqian Lin Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220107085026.23831-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/msm/hdmi/hdmi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdm= i.c index 737453b6e5966..94f948ef279d1 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c @@ -97,10 +97,15 @@ static int msm_hdmi_get_phy(struct hdmi *hdmi) =20 of_node_put(phy_node); =20 - if (!phy_pdev || !hdmi->phy) { + if (!phy_pdev) { DRM_DEV_ERROR(&pdev->dev, "phy driver is not ready\n"); return -EPROBE_DEFER; } + if (!hdmi->phy) { + DRM_DEV_ERROR(&pdev->dev, "phy driver is not ready\n"); + put_device(&phy_pdev->dev); + return -EPROBE_DEFER; + } =20 hdmi->phy_dev =3D get_device(&phy_pdev->dev); =20 --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 8F19DC433EF for ; Mon, 31 Jan 2022 11:16:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349703AbiAaLQH (ORCPT ); Mon, 31 Jan 2022 06:16:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376844AbiAaLJL (ORCPT ); Mon, 31 Jan 2022 06:09:11 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3249C0610EC; Mon, 31 Jan 2022 03:05:40 -0800 (PST) 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 C0701B82A71; Mon, 31 Jan 2022 11:05:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0389BC340EF; Mon, 31 Jan 2022 11:05:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627138; bh=Ic9+VcG7lFp7Q3GuEkC8fKcySwrc/W83HucGFrLwprE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AkoOvEbGc3nRiU/0lxMFQtfFwsm875JSc092QgUM8LowuRxbnufnCyMoRiw9UyMTe /4mOiHncQNzazR8PzAWqfNZkCBLmS/yRETNIYodr1lxuW7+CvvvL2qGQMFsHws9aAf oIkeMg+ad03LXJ5PA1GVmo5KMuRkhKekx7LJ1s/c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Jos=C3=A9=20Exp=C3=B3sito?= , Dmitry Baryshkov , Sasha Levin Subject: [PATCH 5.10 087/100] drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc Date: Mon, 31 Jan 2022 11:56:48 +0100 Message-Id: <20220131105223.386734401@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Jos=C3=A9 Exp=C3=B3sito [ Upstream commit 170b22234d5495f5e0844246e23f004639ee89ba ] The function performs a check on the "ctx" input parameter, however, it is used before the check. Initialize the "base" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 4259ff7ae509e ("drm/msm/dpu: add support for pcc color block in dpu = driver") Addresses-Coverity-ID: 1493866 ("Null pointer dereference") Signed-off-by: Jos=C3=A9 Exp=C3=B3sito Link: https://lore.kernel.org/r/20220109192431.135949-1-jose.exposito89@gma= il.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c b/drivers/gpu/drm/= msm/disp/dpu1/dpu_hw_dspp.c index a7a24539921f3..a6efc11eba93f 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c @@ -26,9 +26,16 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx, struct dpu_hw_pcc_cfg *cfg) { =20 - u32 base =3D ctx->cap->sblk->pcc.base; + u32 base; =20 - if (!ctx || !base) { + if (!ctx) { + DRM_ERROR("invalid ctx %pK\n", ctx); + return; + } + + base =3D ctx->cap->sblk->pcc.base; + + if (!base) { DRM_ERROR("invalid ctx %pK pcc base 0x%x\n", ctx, base); return; } --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 A9263C433FE for ; Mon, 31 Jan 2022 11:16:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359171AbiAaLQm (ORCPT ); Mon, 31 Jan 2022 06:16:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376861AbiAaLJN (ORCPT ); Mon, 31 Jan 2022 06:09:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A89D9C06176C; Mon, 31 Jan 2022 03:05:45 -0800 (PST) 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 46DB960FD3; Mon, 31 Jan 2022 11:05:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BE44C340E8; Mon, 31 Jan 2022 11:05:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627144; bh=GZs9L7T9/6ZSXdD31buqSGJavwQTf+8MmVZed58b7SQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p76fQLriKmSUuTPzcKBuxW2DNmq1Yi592q4rAeznuPJXRSjSaW3oaHH6ELuCytZwq LHxnjKG0ywQSk96zQZAWZTQqq3xZ9QVsI5csvk7ffkTHd/0ZqBj5iIuo3k6ZsA7LaM sDaI3LOfYVZdtV7BKV1wSaZPyBOchxZDlhaW/fTk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hangyu Hua , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 088/100] yam: fix a memory leak in yam_siocdevprivate() Date: Mon, 31 Jan 2022 11:56:49 +0100 Message-Id: <20220131105223.422990110@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Hangyu Hua [ Upstream commit 29eb31542787e1019208a2e1047bb7c76c069536 ] ym needs to be free when ym->cmd !=3D SIOCYAMSMCS. Fixes: 0781168e23a2 ("yam: fix a missing-check bug") Signed-off-by: Hangyu Hua Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/hamradio/yam.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c index 5ab53e9942f30..5d30b3e1806ab 100644 --- a/drivers/net/hamradio/yam.c +++ b/drivers/net/hamradio/yam.c @@ -951,9 +951,7 @@ static int yam_ioctl(struct net_device *dev, struct ifr= eq *ifr, int cmd) sizeof(struct yamdrv_ioctl_mcs)); if (IS_ERR(ym)) return PTR_ERR(ym); - if (ym->cmd !=3D SIOCYAMSMCS) - return -EINVAL; - if (ym->bitrate > YAM_MAXBITRATE) { + if (ym->cmd !=3D SIOCYAMSMCS || ym->bitrate > YAM_MAXBITRATE) { kfree(ym); return -EINVAL; } --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 BE605C433EF for ; Mon, 31 Jan 2022 11:10:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358697AbiAaLKl (ORCPT ); Mon, 31 Jan 2022 06:10:41 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:40236 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359535AbiAaLFs (ORCPT ); Mon, 31 Jan 2022 06:05:48 -0500 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 3EA7660FF5; Mon, 31 Jan 2022 11:05:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B9BBC340EE; Mon, 31 Jan 2022 11:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627147; bh=AIh8bcIWrRf1bu2DJjMdLk+QgJB8K2W75FM7fvF8Zj8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KtMV0NNfsi02efq8tCV93eF3UeiiFsDVw6ieEkd+ziwXHZykKw0vRhyaUsE53c7Uq a9qRsd45FN7gYB/j0+WIdL3GPYfroGKJTGgGbJuA4qLtc7bwhHRF/gdr2UH3I45fjH QHl15BROkVq5sZFfpbopa9lx4cn5g8UXrfWrvGeo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Colin Foster , =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , Jesper Dangaard Brouer , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 089/100] net: cpsw: Properly initialise struct page_pool_params Date: Mon, 31 Jan 2022 11:56:50 +0100 Message-Id: <20220131105223.452077670@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Toke H=C3=B8iland-J=C3=B8rgensen [ Upstream commit c63003e3d99761afb280add3b30de1cf30fa522b ] The cpsw driver didn't properly initialise the struct page_pool_params before calling page_pool_create(), which leads to crashes after the struct has been expanded with new parameters. The second Fixes tag below is where the buggy code was introduced, but because the code was moved around this patch will only apply on top of the commit in the first Fixes tag. Fixes: c5013ac1dd0e ("net: ethernet: ti: cpsw: move set of common functions= in cpsw_priv") Fixes: 9ed4050c0d75 ("net: ethernet: ti: cpsw: add XDP support") Reported-by: Colin Foster Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Tested-by: Colin Foster Acked-by: Jesper Dangaard Brouer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/ti/cpsw_priv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/cpsw_priv.c b/drivers/net/ethernet/ti/= cpsw_priv.c index 424e644724e46..e74f2e95a46eb 100644 --- a/drivers/net/ethernet/ti/cpsw_priv.c +++ b/drivers/net/ethernet/ti/cpsw_priv.c @@ -1144,7 +1144,7 @@ int cpsw_fill_rx_channels(struct cpsw_priv *priv) static struct page_pool *cpsw_create_page_pool(struct cpsw_common *cpsw, int size) { - struct page_pool_params pp_params; + struct page_pool_params pp_params =3D {}; struct page_pool *pool; =20 pp_params.order =3D 0; --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 632D5C433FE for ; Mon, 31 Jan 2022 11:14:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358317AbiAaLOb (ORCPT ); Mon, 31 Jan 2022 06:14:31 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53778 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359087AbiAaLFy (ORCPT ); Mon, 31 Jan 2022 06:05:54 -0500 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 070F1B82A6B; Mon, 31 Jan 2022 11:05:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 383ADC340EE; Mon, 31 Jan 2022 11:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627150; bh=iLf+aQshedKdJMZ/kjXdA49LDG7dvJiXr2Q4KVVJcKc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cSvNyB8X525aWAbfONEHmyr+hbYOqk4Yr6lG1qbR2aQk3HFExbCqTX3O9hUoB5Vhu nwYKbmsPGFISa7JfrLXK29P2CITebjBslLx2O/jveQtkO5Af7p6RQk2ttBgzl731Mq IGX7InZCIDwAv6a1kdqBOIS3TSkjWH6QfgmwZK7I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yufeng Mo , Guangbin Huang , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 090/100] net: hns3: handle empty unknown interrupt for VF Date: Mon, 31 Jan 2022 11:56:51 +0100 Message-Id: <20220131105223.483458541@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Yufeng Mo [ Upstream commit 2f61353cd2f789a4229b6f5c1c24a40a613357bb ] Since some interrupt states may be cleared by hardware, the driver may receive an empty interrupt. Currently, the VF driver directly disables the vector0 interrupt in this case. As a result, the VF is unavailable. Therefore, the vector0 interrupt should be enabled in this case. Fixes: b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/= Global/IMP reset") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/dr= ivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c index 6e7da1dc2e8c3..d6580e942724d 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c @@ -2382,8 +2382,7 @@ static irqreturn_t hclgevf_misc_irq_handle(int irq, v= oid *data) break; } =20 - if (event_cause !=3D HCLGEVF_VECTOR0_EVENT_OTHER) - hclgevf_enable_vector(&hdev->misc_vector, true); + hclgevf_enable_vector(&hdev->misc_vector, true); =20 return IRQ_HANDLED; } --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 79629C433EF for ; Mon, 31 Jan 2022 11:14:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359172AbiAaLOk (ORCPT ); Mon, 31 Jan 2022 06:14:40 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:40292 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359543AbiAaLFz (ORCPT ); Mon, 31 Jan 2022 06:05:55 -0500 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 9F3A160ECF; Mon, 31 Jan 2022 11:05:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58129C340E8; Mon, 31 Jan 2022 11:05:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627154; bh=qlYEMax3/uk+lIMXDR6HWYREniDkhu3SiEJfvPNDbaw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pyLQsk79Z5vtfWl8PP7CbSgvphyHHcUTr4QxMJB3HsY0yk6rSHaLS5tQ7tdAtYoy5 xB7LqDqwkL989CYRflcUSv4okxxI9X6N1WaDe1Mr4ICgR+3XMIHqG+jdj2/OIWjIPH WaCm7oDTWUtn3Txsd3lpieF/5dd2W7SV5sJz6jX4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guillaume Nault , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 091/100] Revert "ipv6: Honor all IPv6 PIO Valid Lifetime values" Date: Mon, 31 Jan 2022 11:56:52 +0100 Message-Id: <20220131105223.513846641@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Guillaume Nault [ Upstream commit 36268983e90316b37000a005642af42234dabb36 ] This reverts commit b75326c201242de9495ff98e5d5cff41d7fc0d9d. This commit breaks Linux compatibility with USGv6 tests. The RFC this commit was based on is actually an expired draft: no published RFC currently allows the new behaviour it introduced. Without full IETF endorsement, the flash renumbering scenario this patch was supposed to enable is never going to work, as other IPv6 equipements on the same LAN will keep the 2 hours limit. Fixes: b75326c20124 ("ipv6: Honor all IPv6 PIO Valid Lifetime values") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/net/addrconf.h | 2 ++ net/ipv6/addrconf.c | 27 ++++++++++++++++++++------- 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/include/net/addrconf.h b/include/net/addrconf.h index 78ea3e332688f..e7ce719838b5e 100644 --- a/include/net/addrconf.h +++ b/include/net/addrconf.h @@ -6,6 +6,8 @@ #define RTR_SOLICITATION_INTERVAL (4*HZ) #define RTR_SOLICITATION_MAX_INTERVAL (3600*HZ) /* 1 hour */ =20 +#define MIN_VALID_LIFETIME (2*3600) /* 2 hours */ + #define TEMP_VALID_LIFETIME (7*86400) #define TEMP_PREFERRED_LIFETIME (86400) #define REGEN_MAX_RETRY (3) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 29526937077b3..4dde49e628fab 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -2577,7 +2577,7 @@ int addrconf_prefix_rcv_add_addr(struct net *net, str= uct net_device *dev, __u32 valid_lft, u32 prefered_lft) { struct inet6_ifaddr *ifp =3D ipv6_get_ifaddr(net, addr, dev, 1); - int create =3D 0; + int create =3D 0, update_lft =3D 0; =20 if (!ifp && valid_lft) { int max_addresses =3D in6_dev->cnf.max_addresses; @@ -2621,19 +2621,32 @@ int addrconf_prefix_rcv_add_addr(struct net *net, s= truct net_device *dev, unsigned long now; u32 stored_lft; =20 - /* Update lifetime (RFC4862 5.5.3 e) - * We deviate from RFC4862 by honoring all Valid Lifetimes to - * improve the reaction of SLAAC to renumbering events - * (draft-gont-6man-slaac-renum-06, Section 4.2) - */ + /* update lifetime (RFC2462 5.5.3 e) */ spin_lock_bh(&ifp->lock); now =3D jiffies; if (ifp->valid_lft > (now - ifp->tstamp) / HZ) stored_lft =3D ifp->valid_lft - (now - ifp->tstamp) / HZ; else stored_lft =3D 0; - if (!create && stored_lft) { + const u32 minimum_lft =3D min_t(u32, + stored_lft, MIN_VALID_LIFETIME); + valid_lft =3D max(valid_lft, minimum_lft); + + /* RFC4862 Section 5.5.3e: + * "Note that the preferred lifetime of the + * corresponding address is always reset to + * the Preferred Lifetime in the received + * Prefix Information option, regardless of + * whether the valid lifetime is also reset or + * ignored." + * + * So we should always update prefered_lft here. + */ + update_lft =3D 1; + } + + if (update_lft) { ifp->valid_lft =3D valid_lft; ifp->prefered_lft =3D prefered_lft; ifp->tstamp =3D now; --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 BCE3DC43217 for ; Mon, 31 Jan 2022 11:10:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244782AbiAaLKr (ORCPT ); Mon, 31 Jan 2022 06:10:47 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:40362 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348644AbiAaLF6 (ORCPT ); Mon, 31 Jan 2022 06:05:58 -0500 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 E31B460F96; Mon, 31 Jan 2022 11:05:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99CA0C340E8; Mon, 31 Jan 2022 11:05:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627157; bh=3hFFj0tKoi4W0dZl+5NryhfL92TrUgIrc2iiMZM4PNw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KqKpgcJ5/szGiyQlYsV5akHUiI22U8sUl/cdjZzfzW6WpNRNiS7NGLBeCd8g7rEol xQdIm7O7Md45mpqlKnUZ/oROweQ7Q1SeBHlGEUFpSGCBsY0tSMXu7W6AoRHnGiA3zl lP12NZVPuh8EXgXNcFm+8OQXMw1RjydvVisNYWWg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Benjamin Poirier , Nikolay Aleksandrov , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 092/100] net: bridge: vlan: fix single net device option dumping Date: Mon, 31 Jan 2022 11:56:53 +0100 Message-Id: <20220131105223.546309373@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Nikolay Aleksandrov [ Upstream commit dcb2c5c6ca9b9177f04abaf76e5a983d177c9414 ] When dumping vlan options for a single net device we send the same entries infinitely because user-space expects a 0 return at the end but we keep returning skb->len and restarting the dump on retry. Fix it by returning the value from br_vlan_dump_dev() if it completed or there was an error. The only case that must return skb->len is when the dump was incomplete and needs to continue (-EMSGSIZE). Reported-by: Benjamin Poirier Fixes: 8dcea187088b ("net: bridge: vlan: add rtm definitions and dump suppo= rt") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/bridge/br_vlan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c index 08c77418c687b..1f508d998fb2d 100644 --- a/net/bridge/br_vlan.c +++ b/net/bridge/br_vlan.c @@ -1873,7 +1873,8 @@ static int br_vlan_rtm_dump(struct sk_buff *skb, stru= ct netlink_callback *cb) goto out_err; } err =3D br_vlan_dump_dev(dev, skb, cb, dump_flags); - if (err && err !=3D -EMSGSIZE) + /* if the dump completed without an error we return 0 here */ + if (err !=3D -EMSGSIZE) goto out_err; } else { for_each_netdev_rcu(net, dev) { --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 C4310C433EF for ; Mon, 31 Jan 2022 11:10:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239834AbiAaLKx (ORCPT ); Mon, 31 Jan 2022 06:10:53 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53886 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235281AbiAaLGD (ORCPT ); Mon, 31 Jan 2022 06:06:03 -0500 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 9AA2FB82A5D; Mon, 31 Jan 2022 11:06:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B782BC340E8; Mon, 31 Jan 2022 11:05:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627160; bh=8QpPn/EcYTTWSowcI/ZY+gOqZOAzFOy0LCORVktrvLE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f4GQWfyzoN+ZFT3ywCh2pxZgwhDXPJBZWxrVY7qrD0CF8eDEVml8b/hlnMEL7D5xI AouwoWKllYPLYX8Sg3mFnfZh06VRnjriVJ4jYaSA67DK6TyGZx1/TiiX6hRKL1mhAG 0I5yL0Tsvvtf2LA9WlSBTZL5COJ94WiblGNX+Who= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , syzbot , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 093/100] ipv4: raw: lock the socket in raw_bind() Date: Mon, 31 Jan 2022 11:56:54 +0100 Message-Id: <20220131105223.580898656@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Eric Dumazet [ Upstream commit 153a0d187e767c68733b8e9f46218eb1f41ab902 ] For some reason, raw_bind() forgot to lock the socket. BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0: raw_bind+0x1b0/0x250 net/ipv4/raw.c:739 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443 __sys_bind+0x14b/0x1b0 net/socket.c:1697 __do_sys_bind net/socket.c:1708 [inline] __se_sys_bind net/socket.c:1706 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1706 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1: __ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0x0003007f Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv4/raw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index 7d26e0f8bdaeb..5d95f80314f95 100644 --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -721,6 +721,7 @@ static int raw_bind(struct sock *sk, struct sockaddr *u= addr, int addr_len) int ret =3D -EINVAL; int chk_addr_ret; =20 + lock_sock(sk); if (sk->sk_state !=3D TCP_CLOSE || addr_len < sizeof(struct sockaddr_in)) goto out; =20 @@ -740,7 +741,9 @@ static int raw_bind(struct sock *sk, struct sockaddr *u= addr, int addr_len) inet->inet_saddr =3D 0; /* Use device */ sk_dst_reset(sk); ret =3D 0; -out: return ret; +out: + release_sock(sk); + return ret; } =20 /* --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 F3811C433EF for ; Mon, 31 Jan 2022 11:14:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359237AbiAaLOo (ORCPT ); Mon, 31 Jan 2022 06:14:44 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53918 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359584AbiAaLGG (ORCPT ); Mon, 31 Jan 2022 06:06:06 -0500 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 AC82FB82A70; Mon, 31 Jan 2022 11:06:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0C14C340E8; Mon, 31 Jan 2022 11:06:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627163; bh=YCch70a1xuaiG3umi4jdkuzRFuQOW2nax+is+noWyYA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XmINA14dD37ib8KiUUEo7RKt5viWzzqZyFAkwCIckNbgXcSMb4vz4UbcuHwlUWAOL xCFxqSHcgqgA38Hbf2Uvdb1wFlu1CMPk2Eo5q7b5M+1ENvBD8BzIP9UM6yWoQ5x5TP Ch/CV1eVREcgangkGpZH1lJbVp5VUY/c+5MCEU80= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Ray Che , David Ahern , Geoff Alexander , Willy Tarreau , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 094/100] ipv4: tcp: send zero IPID in SYNACK messages Date: Mon, 31 Jan 2022 11:56:55 +0100 Message-Id: <20220131105223.613060330@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Eric Dumazet [ Upstream commit 970a5a3ea86da637471d3cd04d513a0755aba4bf ] In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and ACK sent in SYN-RECV and TIME-WAIT state") we took care of some ctl packets sent by TCP. It turns out we need to use a similar strategy for SYNACK packets. By default, they carry IP_DF and IPID=3D=3D0, but there are ways to ask them to use the hashed IP ident generator and thus be used to build off-path attacks. (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment) One of this way is to force (before listener is started) echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc Another way is using forged ICMP ICMP_FRAG_NEEDED with a very small MTU (like 68) to force a false return from ip_dont_fragment() In this patch, ip_build_and_send_pkt() uses the following heuristics. 1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore can use IP_DF regardless of the listener or route pmtu setting. 2) In case the SYNACK packet is bigger than IPV4_MIN_MTU, we use prandom_u32() generator instead of the IPv4 hashed ident one. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: Ray Che Reviewed-by: David Ahern Cc: Geoff Alexander Cc: Willy Tarreau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/ipv4/ip_output.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 4f76e8183f403..5e48b3d3a00db 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -162,12 +162,19 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const = struct sock *sk, iph->daddr =3D (opt && opt->opt.srr ? opt->opt.faddr : daddr); iph->saddr =3D saddr; iph->protocol =3D sk->sk_protocol; - if (ip_dont_fragment(sk, &rt->dst)) { + /* Do not bother generating IPID for small packets (eg SYNACK) */ + if (skb->len <=3D IPV4_MIN_MTU || ip_dont_fragment(sk, &rt->dst)) { iph->frag_off =3D htons(IP_DF); iph->id =3D 0; } else { iph->frag_off =3D 0; - __ip_select_ident(net, iph, 1); + /* TCP packets here are SYNACK with fat IPv4/TCP options. + * Avoid using the hashed IP ident generator. + */ + if (sk->sk_protocol =3D=3D IPPROTO_TCP) + iph->id =3D (__force __be16)prandom_u32(); + else + __ip_select_ident(net, iph, 1); } =20 if (opt && opt->opt.optlen) { --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 4D387C433EF for ; Mon, 31 Jan 2022 11:16:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376771AbiAaLQX (ORCPT ); Mon, 31 Jan 2022 06:16:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376987AbiAaLJ0 (ORCPT ); Mon, 31 Jan 2022 06:09:26 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DC02C061777; Mon, 31 Jan 2022 03:06:09 -0800 (PST) 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 BE9D2B82A74; Mon, 31 Jan 2022 11:06:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBAE1C340E8; Mon, 31 Jan 2022 11:06:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627166; bh=rzVO/2az8f+goj1WhpUhD/OCjQLJr0nUHjFRc4YWh50=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2Bph26F41TfSnzYw23FKKA4VPFRAUUSlGoQERZPo6WMB3QNr0yBKc0/AGy2VRR8nJ eimDSrKjOmz8UxGQ3PjCH+QQr/XQFcTDACE0lsPVXZgeLAVVWexoA6tAFn+7a2dOz4 1BqHXx/5zXWQK6gdvDyDOFUo9EEsztun0BnyegOY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , David Ahern , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 095/100] ipv4: remove sparse error in ip_neigh_gw4() Date: Mon, 31 Jan 2022 11:56:56 +0100 Message-Id: <20220131105223.645251314@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Eric Dumazet [ Upstream commit 3c42b2019863b327caa233072c50739d4144dd16 ] ./include/net/route.h:373:48: warning: incorrect type in argument 2 (differ= ent base types) ./include/net/route.h:373:48: expected unsigned int [usertype] key ./include/net/route.h:373:48: got restricted __be32 [usertype] daddr Fixes: 5c9f7c1dfc2e ("ipv4: Add helpers for neigh lookup for nexthop") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20220127013404.1279313-1-eric.dumazet@gmail= .com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/net/route.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/route.h b/include/net/route.h index ff021cab657e5..a07c277cd33e8 100644 --- a/include/net/route.h +++ b/include/net/route.h @@ -369,7 +369,7 @@ static inline struct neighbour *ip_neigh_gw4(struct net= _device *dev, { struct neighbour *neigh; =20 - neigh =3D __ipv4_neigh_lookup_noref(dev, daddr); + neigh =3D __ipv4_neigh_lookup_noref(dev, (__force u32)daddr); if (unlikely(!neigh)) neigh =3D __neigh_create(&arp_tbl, &daddr, dev, false); =20 --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 434B2C4167E for ; Mon, 31 Jan 2022 11:13:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376516AbiAaLMx (ORCPT ); Mon, 31 Jan 2022 06:12:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377043AbiAaLJb (ORCPT ); Mon, 31 Jan 2022 06:09:31 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 289ECC0604C2; Mon, 31 Jan 2022 03:06:11 -0800 (PST) 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 AB087B82A71; Mon, 31 Jan 2022 11:06:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3B50C340E8; Mon, 31 Jan 2022 11:06:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627169; bh=RU/aoYH9VVAzoILzyFoXl7OLpyGsCBshNoSXoZibb58=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yOMDMKGSBObc2qqfBg7hFwSY2MMf6DTFE5pRkwLCz0Gl/t0VUdZDUNbi35Msx7jeF rjKsSkViATkAw7cOPA+p1OH4AlQkcrc6+UV8gMTSFOwclZ0xqC11NXY15QtwDLb2Vi LuBhn3ygnG4i4/cN9VDEG7gIcl99hW5lMW3/YdKI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tim Yi , Nikolay Aleksandrov , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 096/100] net: bridge: vlan: fix memory leak in __allowed_ingress Date: Mon, 31 Jan 2022 11:56:57 +0100 Message-Id: <20220131105223.675973580@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Tim Yi [ Upstream commit fd20d9738395cf8e27d0a17eba34169699fccdff ] When using per-vlan state, if vlan snooping and stats are disabled, untagged or priority-tagged ingress frame will go to check pvid state. If the port state is forwarding and the pvid state is not learning/forwarding, untagged or priority-tagged frame will be dropped but skb memory is not freed. Should free skb when __allowed_ingress returns false. Fixes: a580c76d534c ("net: bridge: vlan: add per-vlan state") Signed-off-by: Tim Yi Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20220127074953.12632-1-tim.yi@pica8.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/bridge/br_vlan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c index 1f508d998fb2d..852f4b54e8811 100644 --- a/net/bridge/br_vlan.c +++ b/net/bridge/br_vlan.c @@ -543,10 +543,10 @@ static bool __allowed_ingress(const struct net_bridge= *br, if (!br_opt_get(br, BROPT_VLAN_STATS_ENABLED)) { if (*state =3D=3D BR_STATE_FORWARDING) { *state =3D br_vlan_get_pvid_state(vg); - return br_vlan_state_allowed(*state, true); - } else { - return true; + if (!br_vlan_state_allowed(*state, true)) + goto drop; } + return true; } } v =3D br_vlan_find(vg, *vid); --=20 2.34.1 From nobody Tue Jun 30 03:34:06 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 2AB96C433F5 for ; Mon, 31 Jan 2022 11:14:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359315AbiAaLOr (ORCPT ); Mon, 31 Jan 2022 06:14:47 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:54076 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358926AbiAaLGO (ORCPT ); Mon, 31 Jan 2022 06:06:14 -0500 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 BCF59B82A6E; Mon, 31 Jan 2022 11:06:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C603FC340E8; Mon, 31 Jan 2022 11:06:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627172; bh=DoZ1E/+8ix+OgIbNqPUNVDPpuSpcbXv83pH9UB60g/M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JuC7Bok7U+kB85x2SPeAhJ1ud11gf02HV+VK47KWfePS/3CpwT/eKdxQKLfhgUqXc efN0l5GHhcdIhg2XcaKfjFCUSboOl2U17k/k5KcjQiVicrs1WwwwdlcksJbMCiO8mh 7oO71m1tcAUQZ8G1annCzkQD86lIND7XjxLSjn5U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Kleine-Budde Subject: [PATCH 5.10 097/100] dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config Date: Mon, 31 Jan 2022 11:56:58 +0100 Message-Id: <20220131105223.714641649@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Marc Kleine-Budde commit 17a30422621c0e04cb6060d20d7edcefd7463347 upstream. This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32 doesn't fit into the MRAM. Use a depth of 16 instead. Fixes: 4edd396a1911 ("dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4= x5X driver") Link: https://lore.kernel.org/all/20220119062951.2939851-1-mkl@pengutronix.= de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- Documentation/devicetree/bindings/net/can/tcan4x5x.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt @@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 { #address-cells =3D <1>; #size-cells =3D <1>; spi-max-frequency =3D <10000000>; - bosch,mram-cfg =3D <0x0 0 0 32 0 0 1 1>; + bosch,mram-cfg =3D <0x0 0 0 16 0 0 1 1>; interrupt-parent =3D <&gpio1>; interrupts =3D <14 IRQ_TYPE_LEVEL_LOW>; device-state-gpios =3D <&gpio3 21 GPIO_ACTIVE_HIGH>; From nobody Tue Jun 30 03:34:06 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 47BE8C35272 for ; Mon, 31 Jan 2022 11:13:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376540AbiAaLM4 (ORCPT ); Mon, 31 Jan 2022 06:12:56 -0500 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 S1377072AbiAaLJg (ORCPT ); Mon, 31 Jan 2022 06:09:36 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C291C0613E7; Mon, 31 Jan 2022 03:06:21 -0800 (PST) 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 0F195B82A65; Mon, 31 Jan 2022 11:06:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F6F8C340E8; Mon, 31 Jan 2022 11:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627178; bh=bZ6ukf/XeQnZfTLzn0CS/fdzDUU9lgLzWoBo03yH37s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FiSNH/rlUtEazYOQnE971InUJ1M2Rz2/nwZKFtV7eLtoODRjm9xuzQFUnkxnZE6Qj mQzq4p7IbP6qH245N3yy7TXdj7nmkPaCRpwqavD+4llJRJEK6YnW25q2Mg9/2QoSmG /YqhP8rSbyg/xKJemZ0VLHNxzEjLeGj9z7txrJl0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Dmitry V. Levin" , Masahiro Yamada Subject: [PATCH 5.10 098/100] usr/include/Makefile: add linux/nfc.h to the compile-test coverage Date: Mon, 31 Jan 2022 11:56:59 +0100 Message-Id: <20220131105223.745422665@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Dmitry V. Levin commit 10756dc5b02bff370ddd351d7744bc99ada659c2 upstream. As linux/nfc.h userspace compilation was finally fixed by commits 79b69a83705e ("nfc: uapi: use kernel size_t to fix user-space builds") and 7175f02c4e5f ("uapi: fix linux/nfc.h userspace compilation errors"), there is no need to keep the compile-test exception for it in usr/include/Makefile. Signed-off-by: Dmitry V. Levin Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- usr/include/Makefile | 1 - 1 file changed, 1 deletion(-) --- a/usr/include/Makefile +++ b/usr/include/Makefile @@ -34,7 +34,6 @@ no-header-test +=3D linux/hdlc/ioctl.h no-header-test +=3D linux/ivtv.h no-header-test +=3D linux/kexec.h no-header-test +=3D linux/matroxfb.h -no-header-test +=3D linux/nfc.h no-header-test +=3D linux/omap3isp.h no-header-test +=3D linux/omapfb.h no-header-test +=3D linux/patchkey.h From nobody Tue Jun 30 03:34:06 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 C9C84C433F5 for ; Mon, 31 Jan 2022 11:16:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359320AbiAaLQs (ORCPT ); Mon, 31 Jan 2022 06:16:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377130AbiAaLJn (ORCPT ); Mon, 31 Jan 2022 06:09:43 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25FF6C0604C5; Mon, 31 Jan 2022 03:06:23 -0800 (PST) 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 C3DD5B82A65; Mon, 31 Jan 2022 11:06:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16B7FC340EE; Mon, 31 Jan 2022 11:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627181; bh=xpJRa1/Hqa4J8TOwr9A3cijO2CHMQKV430HfQznfbS0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lFiMa59K9cxN/pzfLs6G1UMLaDL04NRpdofAdrj6sH5rjIu+twCTQ7s+u02C3ZooX d0Eiar52KAg86LHIHX+yFnH+D376HIk+yWMYbnK6T6yWz8RGN/ws6mKrop5QGkEo43 qb8I8nMed92rTGUPTSA1I8LwUNig8fC5Yhw1nF7U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ivan Delalande , Amir Goldstein , Jan Kara Subject: [PATCH 5.10 099/100] fsnotify: invalidate dcache before IN_DELETE event Date: Mon, 31 Jan 2022 11:57:00 +0100 Message-Id: <20220131105223.775234099@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: Amir Goldstein commit a37d9a17f099072fe4d3a9048b0321978707a918 upstream. Apparently, there are some applications that use IN_DELETE event as an invalidation mechanism and expect that if they try to open a file with the name reported with the delete event, that it should not contain the content of the deleted file. Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify will have access to a positive dentry. This allowed a race where opening the deleted file via cached dentry is now possible after receiving the IN_DELETE event. To fix the regression, create a new hook fsnotify_delete() that takes the unlinked inode as an argument and use a helper d_delete_notify() to pin the inode, so we can pass it to fsnotify_delete() after d_delete(). Backporting hint: this regression is from v5.3. Although patch will apply with only trivial conflicts to v5.4 and v5.10, it won't build, because fsnotify_delete() implementation is different in each of those versions (see fsnotify_link()). A follow up patch will fix the fsnotify_unlink/rmdir() calls in pseudo filesystem that do not need to call d_delete(). Link: https://lore.kernel.org/r/20220120215305.282577-1-amir73il@gmail.com Reported-by: Ivan Delalande Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_de= lete()") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/ioctl.c | 6 +---- fs/namei.c | 10 ++++----- include/linux/fsnotify.h | 48 +++++++++++++++++++++++++++++++++++++++++-= ----- 3 files changed, 49 insertions(+), 15 deletions(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -3103,10 +3103,8 @@ static noinline int btrfs_ioctl_snap_des inode_lock(inode); err =3D btrfs_delete_subvolume(dir, dentry); inode_unlock(inode); - if (!err) { - fsnotify_rmdir(dir, dentry); - d_delete(dentry); - } + if (!err) + d_delete_notify(dir, dentry); =20 out_dput: dput(dentry); --- a/fs/namei.c +++ b/fs/namei.c @@ -3709,13 +3709,12 @@ int vfs_rmdir(struct inode *dir, struct dentry->d_inode->i_flags |=3D S_DEAD; dont_mount(dentry); detach_mounts(dentry); - fsnotify_rmdir(dir, dentry); =20 out: inode_unlock(dentry->d_inode); dput(dentry); if (!error) - d_delete(dentry); + d_delete_notify(dir, dentry); return error; } EXPORT_SYMBOL(vfs_rmdir); @@ -3825,7 +3824,6 @@ int vfs_unlink(struct inode *dir, struct if (!error) { dont_mount(dentry); detach_mounts(dentry); - fsnotify_unlink(dir, dentry); } } } @@ -3833,9 +3831,11 @@ out: inode_unlock(target); =20 /* We don't d_delete() NFS sillyrenamed files--they still exist. */ - if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) { + if (!error && dentry->d_flags & DCACHE_NFSFS_RENAMED) { + fsnotify_unlink(dir, dentry); + } else if (!error) { fsnotify_link_count(target); - d_delete(dentry); + d_delete_notify(dir, dentry); } =20 return error; --- a/include/linux/fsnotify.h +++ b/include/linux/fsnotify.h @@ -204,16 +204,52 @@ static inline void fsnotify_link(struct } =20 /* + * fsnotify_delete - @dentry was unlinked and unhashed + * + * Caller must make sure that dentry->d_name is stable. + * + * Note: unlike fsnotify_unlink(), we have to pass also the unlinked inode + * as this may be called after d_delete() and old_dentry may be negative. + */ +static inline void fsnotify_delete(struct inode *dir, struct inode *inode, + struct dentry *dentry) +{ + __u32 mask =3D FS_DELETE; + + if (S_ISDIR(inode->i_mode)) + mask |=3D FS_ISDIR; + + fsnotify_name(dir, mask, inode, &dentry->d_name, 0); +} + +/** + * d_delete_notify - delete a dentry and call fsnotify_delete() + * @dentry: The dentry to delete + * + * This helper is used to guaranty that the unlinked inode cannot be found + * by lookup of this name after fsnotify_delete() event has been delivered. + */ +static inline void d_delete_notify(struct inode *dir, struct dentry *dentr= y) +{ + struct inode *inode =3D d_inode(dentry); + + ihold(inode); + d_delete(dentry); + fsnotify_delete(dir, inode, dentry); + iput(inode); +} + +/* * fsnotify_unlink - 'name' was unlinked * * Caller must make sure that dentry->d_name is stable. */ static inline void fsnotify_unlink(struct inode *dir, struct dentry *dentr= y) { - /* Expected to be called before d_delete() */ - WARN_ON_ONCE(d_is_negative(dentry)); + if (WARN_ON_ONCE(d_is_negative(dentry))) + return; =20 - fsnotify_dirent(dir, dentry, FS_DELETE); + fsnotify_delete(dir, d_inode(dentry), dentry); } =20 /* @@ -233,10 +269,10 @@ static inline void fsnotify_mkdir(struct */ static inline void fsnotify_rmdir(struct inode *dir, struct dentry *dentry) { - /* Expected to be called before d_delete() */ - WARN_ON_ONCE(d_is_negative(dentry)); + if (WARN_ON_ONCE(d_is_negative(dentry))) + return; =20 - fsnotify_dirent(dir, dentry, FS_DELETE | FS_ISDIR); + fsnotify_delete(dir, d_inode(dentry), dentry); } =20 /* From nobody Tue Jun 30 03:34:06 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 7F0D8C433EF for ; Mon, 31 Jan 2022 11:16:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376937AbiAaLQz (ORCPT ); Mon, 31 Jan 2022 06:16:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377159AbiAaLJp (ORCPT ); Mon, 31 Jan 2022 06:09:45 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3B2EC0604C8; Mon, 31 Jan 2022 03:06:26 -0800 (PST) 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 B0B68B82A5C; Mon, 31 Jan 2022 11:06:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F370DC340EF; Mon, 31 Jan 2022 11:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643627184; bh=JJG8FPMAU2MXhrU12vj6pVtNxghJpIL8qz7OMrp+rNM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mjsVgmoH7vgvJnyuW+q31Ta9StpGAWD83p2KwzZZie4FfneblOsBKYP2QKSJWNXpe Oh7yXuXxlI1OVzdlqt4nJdu4nLKcHc3g5TAgc1y9FJnW8KX1i0k8DrvUGQ8BviCriN xybWx9qJ6GMeo5KySxMvLOQ496OjlPgmL482DNNk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+ac94ae5f68b84197f41c@syzkaller.appspotmail.com, OGAWA Hirofumi , Ming Lei , Jens Axboe Subject: [PATCH 5.10 100/100] block: Fix wrong offset in bio_truncate() Date: Mon, 31 Jan 2022 11:57:01 +0100 Message-Id: <20220131105223.808036007@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105220.424085452@linuxfoundation.org> References: <20220131105220.424085452@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: OGAWA Hirofumi commit 3ee859e384d453d6ac68bfd5971f630d9fa46ad3 upstream. bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. Reported-by: syzbot+ac94ae5f68b84197f41c@syzkaller.appspotmail.com Signed-off-by: OGAWA Hirofumi Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/875yqt1c9g.fsf@mail.parknet.co.jp Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- block/bio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/block/bio.c +++ b/block/bio.c @@ -575,7 +575,8 @@ void bio_truncate(struct bio *bio, unsig offset =3D new_size - done; else offset =3D 0; - zero_user(bv.bv_page, offset, bv.bv_len - offset); + zero_user(bv.bv_page, bv.bv_offset + offset, + bv.bv_len - offset); truncated =3D true; } done +=3D bv.bv_len;