From nobody Mon Jun 29 18:37: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 599C2C433F5 for ; Fri, 4 Feb 2022 09:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357399AbiBDJVe (ORCPT ); Fri, 4 Feb 2022 04:21:34 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:40518 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357406AbiBDJVJ (ORCPT ); Fri, 4 Feb 2022 04:21: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 dfw.source.kernel.org (Postfix) with ESMTPS id E748061605; Fri, 4 Feb 2022 09:21:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DB7EC004E1; Fri, 4 Feb 2022 09:21:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966468; bh=4KnP9f2BG2N0gQWpClCCaBlbp1tyU3Pjw2Z1LPrgmQ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rAL+gOlFfuOUq7SkRpRlMKuMVEiOwcWB/Q06FJygbytejlhsdt0HT/EQ1zfQw4Ks/ v46Sd4GaJeai+BbM5yiZOUf6VMBu1l+mS/db8TEZ14kFi851qgDznR/N/b5o1WjIMc k2tMUA7EN0+rTjSaN1duJKRstzVlVKzxbBrnw7x4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joseph Bao , Lukas Wunner , Bjorn Helgaas , Stuart Hayes Subject: [PATCH 5.10 01/25] PCI: pciehp: Fix infinite loop in IRQ handler upon power fault Date: Fri, 4 Feb 2022 10:20:08 +0100 Message-Id: <20220204091914.330419771@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Lukas Wunner commit 23584c1ed3e15a6f4bfab8dc5a88d94ab929ee12 upstream. The Power Fault Detected bit in the Slot Status register differs from all other hotplug events in that it is sticky: It can only be cleared after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8: If a power controller detects a main power fault on the hot-plug slot, it must automatically set its internal main power fault latch [...]. The main power fault latch is cleared when software turns off power to the hot-plug slot. The stickiness used to cause interrupt storms and infinite loops which were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable software notification on empty slots"). Unfortunately in 2020 the infinite loop issue was inadvertently reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race"): The hardirq handler pciehp_isr() clears the PFD bit until pciehp's power_fault_detected flag is set. That happens in the IRQ thread pciehp_ist(), which never learns of the event because the hardirq handler is stuck in an infinite loop. Fix by setting the power_fault_detected flag already in the hardirq handler. Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D214989 Link: https://lore.kernel.org/linux-pci/DM8PR11MB5702255A6A92F735D90A444686= 8B9@DM8PR11MB5702.namprd11.prod.outlook.com Fixes: 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt race") Link: https://lore.kernel.org/r/66eaeef31d4997ceea357ad93259f290ededecfd.16= 37187226.git.lukas@wunner.de Reported-by: Joseph Bao Tested-by: Joseph Bao Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v4.19+ Cc: Stuart Hayes 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/pci/hotplug/pciehp_hpc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pciehp_hpc.c @@ -642,6 +642,8 @@ read_status: */ if (ctrl->power_fault_detected) status &=3D ~PCI_EXP_SLTSTA_PFD; + else if (status & PCI_EXP_SLTSTA_PFD) + ctrl->power_fault_detected =3D true; =20 events |=3D status; if (!events) { @@ -651,7 +653,7 @@ read_status: } =20 if (status) { - pcie_capability_write_word(pdev, PCI_EXP_SLTSTA, events); + pcie_capability_write_word(pdev, PCI_EXP_SLTSTA, status); =20 /* * In MSI mode, all event bits must be zero before the port @@ -725,8 +727,7 @@ static irqreturn_t pciehp_ist(int irq, v } =20 /* Check Power Fault Detected */ - if ((events & PCI_EXP_SLTSTA_PFD) && !ctrl->power_fault_detected) { - ctrl->power_fault_detected =3D 1; + if (events & PCI_EXP_SLTSTA_PFD) { ctrl_err(ctrl, "Slot(%s): Power fault\n", slot_name(ctrl)); pciehp_set_indicators(ctrl, PCI_EXP_SLTCTL_PWR_IND_OFF, PCI_EXP_SLTCTL_ATTN_IND_ON); From nobody Mon Jun 29 18:37: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 881D7C433F5 for ; Fri, 4 Feb 2022 09:22:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357380AbiBDJW1 (ORCPT ); Fri, 4 Feb 2022 04:22:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357543AbiBDJVr (ORCPT ); Fri, 4 Feb 2022 04:21:47 -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 7FC0AC06176D; Fri, 4 Feb 2022 01:21:46 -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 455CCB836B9; Fri, 4 Feb 2022 09:21:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35548C004E1; Fri, 4 Feb 2022 09:21:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966503; bh=HF8PCrqcOsp+S8v1dXh6Awe5oWy11tf8qytKG0CdvcI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UAtF78ZfXTDsGUhmZw+zLOBe+0RSEjO+OHHYZjkybOHdGaQk0cD8Rq4v+zJ3f4H8c pIxvAiOxOp0IKW2aCZIuZ8rb35z9IwqqxQqda2ZbBSF7JHvNmryEgCcQsCCUe3iW9T s0feeMeRzTIO2gbXz3+Ih+W7/dThsBeuEiMj460s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Matthias Kaehlcke , Alex Elder , "David S. Miller" Subject: [PATCH 5.10 02/25] net: ipa: fix atomic update in ipa_endpoint_replenish() Date: Fri, 4 Feb 2022 10:20:09 +0100 Message-Id: <20220204091914.361925939@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Alex Elder commit 6c0e3b5ce94947b311348c367db9e11dcb2ccc93 upstream. In ipa_endpoint_replenish(), if an error occurs when attempting to replenish a receive buffer, we just quit and try again later. In that case we increment the backlog count to reflect that the attempt was unsuccessful. Then, if the add_one flag was true we increment the backlog again. This second increment is not included in the backlog local variable though, and its value determines whether delayed work should be scheduled. This is a bug. Fix this by determining whether 1 or 2 should be added to the backlog before adding it in a atomic_add_return() call. Reviewed-by: Matthias Kaehlcke Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ipa/ipa_endpoint.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/net/ipa/ipa_endpoint.c +++ b/drivers/net/ipa/ipa_endpoint.c @@ -918,10 +918,7 @@ static void ipa_endpoint_replenish(struc =20 try_again_later: /* The last one didn't succeed, so fix the backlog */ - backlog =3D atomic_inc_return(&endpoint->replenish_backlog); - - if (count) - atomic_add(count, &endpoint->replenish_backlog); + backlog =3D atomic_add_return(count + 1, &endpoint->replenish_backlog); =20 /* Whenever a receive buffer transaction completes we'll try to * replenish again. It's unlikely, but if we fail to supply even From nobody Mon Jun 29 18:37: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 31A3EC433F5 for ; Fri, 4 Feb 2022 09:22:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357536AbiBDJWz (ORCPT ); Fri, 4 Feb 2022 04:22:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357605AbiBDJWI (ORCPT ); Fri, 4 Feb 2022 04:22:08 -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 4D953C061769; Fri, 4 Feb 2022 01:22: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 B4DAC615ED; Fri, 4 Feb 2022 09:22:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72371C004E1; Fri, 4 Feb 2022 09:22:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966527; bh=r+9CMK2YraWHNvdjd/Uq7p2YSuxZJmo5/XjNTWxAkws=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p2Q2wWkS60k+/f0mPvEjeNx/Wp9nsB7vbyYLNJpVDU+DWKL52i/uEx/txRk0mhOTt v5ppdJb1gOkrJ9kHIYosakk6gMrm6+kaPmGP7r4+ngTTZBRS8l80zFg91D5C+BisPa n7XITJzctdTjBMFCYqUMEcMlGKsA8LPxmWizqdVU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alex Elder , "David S. Miller" Subject: [PATCH 5.10 03/25] net: ipa: use a bitmap for endpoint replenish_enabled Date: Fri, 4 Feb 2022 10:20:10 +0100 Message-Id: <20220204091914.389643045@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Alex Elder commit c1aaa01dbf4cef95af3e04a5a43986c290e06ea3 upstream. Define a new replenish_flags bitmap to contain Boolean flags associated with an endpoint's replenishing state. Replace the replenish_enabled field with a flag in that bitmap. This is to prepare for the next patch, which adds another flag. Signed-off-by: Alex Elder 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ipa/ipa_endpoint.c | 8 ++++---- drivers/net/ipa/ipa_endpoint.h | 13 ++++++++++++- 2 files changed, 16 insertions(+), 5 deletions(-) --- a/drivers/net/ipa/ipa_endpoint.c +++ b/drivers/net/ipa/ipa_endpoint.c @@ -901,7 +901,7 @@ static void ipa_endpoint_replenish(struc struct gsi *gsi; u32 backlog; =20 - if (!endpoint->replenish_enabled) { + if (!test_bit(IPA_REPLENISH_ENABLED, endpoint->replenish_flags)) { if (count) atomic_add(count, &endpoint->replenish_saved); return; @@ -938,7 +938,7 @@ static void ipa_endpoint_replenish_enabl u32 max_backlog; u32 saved; =20 - endpoint->replenish_enabled =3D true; + set_bit(IPA_REPLENISH_ENABLED, endpoint->replenish_flags); while ((saved =3D atomic_xchg(&endpoint->replenish_saved, 0))) atomic_add(saved, &endpoint->replenish_backlog); =20 @@ -952,7 +952,7 @@ static void ipa_endpoint_replenish_disab { u32 backlog; =20 - endpoint->replenish_enabled =3D false; + clear_bit(IPA_REPLENISH_ENABLED, endpoint->replenish_flags); while ((backlog =3D atomic_xchg(&endpoint->replenish_backlog, 0))) atomic_add(backlog, &endpoint->replenish_saved); } @@ -1469,7 +1469,7 @@ static void ipa_endpoint_setup_one(struc /* RX transactions require a single TRE, so the maximum * backlog is the same as the maximum outstanding TREs. */ - endpoint->replenish_enabled =3D false; + clear_bit(IPA_REPLENISH_ENABLED, endpoint->replenish_flags); atomic_set(&endpoint->replenish_saved, gsi_channel_tre_max(gsi, endpoint->channel_id)); atomic_set(&endpoint->replenish_backlog, 0); --- a/drivers/net/ipa/ipa_endpoint.h +++ b/drivers/net/ipa/ipa_endpoint.h @@ -40,6 +40,17 @@ enum ipa_endpoint_name { #define IPA_ENDPOINT_MAX 32 /* Max supported by driver */ =20 /** + * enum ipa_replenish_flag: RX buffer replenish flags + * + * @IPA_REPLENISH_ENABLED: Whether receive buffer replenishing is enabled + * @IPA_REPLENISH_COUNT: Number of defined replenish flags + */ +enum ipa_replenish_flag { + IPA_REPLENISH_ENABLED, + IPA_REPLENISH_COUNT, /* Number of flags (must be last) */ +}; + +/** * struct ipa_endpoint - IPA endpoint information * @channel_id: EP's GSI channel * @evt_ring_id: EP's GSI channel event ring @@ -60,7 +71,7 @@ struct ipa_endpoint { struct net_device *netdev; =20 /* Receive buffer replenishing for RX endpoints */ - bool replenish_enabled; + DECLARE_BITMAP(replenish_flags, IPA_REPLENISH_COUNT); u32 replenish_ready; atomic_t replenish_saved; atomic_t replenish_backlog; From nobody Mon Jun 29 18:37: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 AA9C2C433EF for ; Fri, 4 Feb 2022 09:23:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357495AbiBDJW6 (ORCPT ); Fri, 4 Feb 2022 04:22:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357531AbiBDJWM (ORCPT ); Fri, 4 Feb 2022 04:22:12 -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 668D6C061760; Fri, 4 Feb 2022 01:22: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 dfw.source.kernel.org (Postfix) with ESMTPS id CD5A46162C; Fri, 4 Feb 2022 09:22:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B08BBC004E1; Fri, 4 Feb 2022 09:22:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966530; bh=WaDGmJ3k0j4stp3NMd9qs5wTtfDR4VHH69jQNzw4zAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iomp+G4sVDLziErQcGM0Rky/Zb3qb0+llMa2lkeverZ+jLIu++wGF1fZQ+qUrPO1z jL9AswVhN5Qd9A005ItC9kohFsoKVcEDyHf2HdyVDDINlzRKzxAT1HY7M1bt/pBz7b uyI43jfZfxm2+YO6LcrJnLGERiLUGtdavuWOtBRU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alex Elder , "David S. Miller" Subject: [PATCH 5.10 04/25] net: ipa: prevent concurrent replenish Date: Fri, 4 Feb 2022 10:20:11 +0100 Message-Id: <20220204091914.428884604@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Alex Elder commit 998c0bd2b3715244da7639cc4e6a2062cb79c3f4 upstream. We have seen cases where an endpoint RX completion interrupt arrives while replenishing for the endpoint is underway. This causes another instance of replenishing to begin as part of completing the receive transaction. If this occurs it can lead to transaction corruption. Use a new flag to ensure only one replenish instance for an endpoint executes at a time. Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints") Signed-off-by: Alex Elder 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ipa/ipa_endpoint.c | 12 ++++++++++++ drivers/net/ipa/ipa_endpoint.h | 2 ++ 2 files changed, 14 insertions(+) --- a/drivers/net/ipa/ipa_endpoint.c +++ b/drivers/net/ipa/ipa_endpoint.c @@ -907,16 +907,27 @@ static void ipa_endpoint_replenish(struc return; } =20 + /* If already active, just update the backlog */ + if (test_and_set_bit(IPA_REPLENISH_ACTIVE, endpoint->replenish_flags)) { + if (count) + atomic_add(count, &endpoint->replenish_backlog); + return; + } =20 while (atomic_dec_not_zero(&endpoint->replenish_backlog)) if (ipa_endpoint_replenish_one(endpoint)) goto try_again_later; + + clear_bit(IPA_REPLENISH_ACTIVE, endpoint->replenish_flags); + if (count) atomic_add(count, &endpoint->replenish_backlog); =20 return; =20 try_again_later: + clear_bit(IPA_REPLENISH_ACTIVE, endpoint->replenish_flags); + /* The last one didn't succeed, so fix the backlog */ backlog =3D atomic_add_return(count + 1, &endpoint->replenish_backlog); =20 @@ -1470,6 +1481,7 @@ static void ipa_endpoint_setup_one(struc * backlog is the same as the maximum outstanding TREs. */ clear_bit(IPA_REPLENISH_ENABLED, endpoint->replenish_flags); + clear_bit(IPA_REPLENISH_ACTIVE, endpoint->replenish_flags); atomic_set(&endpoint->replenish_saved, gsi_channel_tre_max(gsi, endpoint->channel_id)); atomic_set(&endpoint->replenish_backlog, 0); --- a/drivers/net/ipa/ipa_endpoint.h +++ b/drivers/net/ipa/ipa_endpoint.h @@ -43,10 +43,12 @@ enum ipa_endpoint_name { * enum ipa_replenish_flag: RX buffer replenish flags * * @IPA_REPLENISH_ENABLED: Whether receive buffer replenishing is enabled + * @IPA_REPLENISH_ACTIVE: Whether replenishing is underway * @IPA_REPLENISH_COUNT: Number of defined replenish flags */ enum ipa_replenish_flag { IPA_REPLENISH_ENABLED, + IPA_REPLENISH_ACTIVE, IPA_REPLENISH_COUNT, /* Number of flags (must be last) */ }; =20 From nobody Mon Jun 29 18:37: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 C2530C433FE for ; Fri, 4 Feb 2022 09:23:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357780AbiBDJXC (ORCPT ); Fri, 4 Feb 2022 04:23:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357622AbiBDJWQ (ORCPT ); Fri, 4 Feb 2022 04:22:16 -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 21248C061763; Fri, 4 Feb 2022 01:22:16 -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 CF332B836ED; Fri, 4 Feb 2022 09:22:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6893C004E1; Fri, 4 Feb 2022 09:22:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966533; bh=D6CdPuM11W/cFHrtJL2IQl5AyPJZgCOpQpKSV5wrNE4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DJuFecwT+0Uy0RgSvE/L2V2pHG7itf6VYRjsMTOUKhvqX6fiR6egyHoBu0oP9nAwL vLWUoF80VB6BCz88ndoAVZkSPmVzgFVZG7OM+xVVXZmcasIe6PmUODJRht4IKlYk0L GVX7yK78/sBqqeFlsnl1/sQ0zunKXU7XpcVztr6o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Saravana Kannan , Kevin Hilman Subject: [PATCH 5.10 05/25] Revert "drivers: bus: simple-pm-bus: Add support for probing simple bus only devices" Date: Fri, 4 Feb 2022 10:20:12 +0100 Message-Id: <20220204091914.467025114@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Kevin Hilman This reverts commit d5f13bbb51046537b2c2b9868177fb8fe8a6a6e9 which is commit 98e96cf80045a383fcc47c58dd4e87b3ae587b3e upstream. This change related to fw_devlink was backported to v5.10 but has severaly other dependencies that were not backported. As discussed with the original author, the best approach for v5.10 is to revert. Link: https://lore.kernel.org/linux-omap/7hk0efmfzo.fsf@baylibre.com Acked-by: Saravana Kannan Signed-off-by: Kevin Hilman 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/bus/simple-pm-bus.c | 39 +-------------------------------------- 1 file changed, 1 insertion(+), 38 deletions(-) --- a/drivers/bus/simple-pm-bus.c +++ b/drivers/bus/simple-pm-bus.c @@ -16,33 +16,7 @@ =20 static int simple_pm_bus_probe(struct platform_device *pdev) { - const struct device *dev =3D &pdev->dev; - struct device_node *np =3D dev->of_node; - const struct of_device_id *match; - - /* - * Allow user to use driver_override to bind this driver to a - * transparent bus device which has a different compatible string - * that's not listed in simple_pm_bus_of_match. We don't want to do any - * of the simple-pm-bus tasks for these devices, so return early. - */ - if (pdev->driver_override) - return 0; - - match =3D of_match_device(dev->driver->of_match_table, dev); - /* - * These are transparent bus devices (not simple-pm-bus matches) that - * have their child nodes populated automatically. So, don't need to - * do anything more. We only match with the device if this driver is - * the most specific match because we don't want to incorrectly bind to - * a device that has a more specific driver. - */ - if (match && match->data) { - if (of_property_match_string(np, "compatible", match->compatible) =3D=3D= 0) - return 0; - else - return -ENODEV; - } + struct device_node *np =3D pdev->dev.of_node; =20 dev_dbg(&pdev->dev, "%s\n", __func__); =20 @@ -56,25 +30,14 @@ static int simple_pm_bus_probe(struct pl =20 static int simple_pm_bus_remove(struct platform_device *pdev) { - const void *data =3D of_device_get_match_data(&pdev->dev); - - if (pdev->driver_override || data) - return 0; - dev_dbg(&pdev->dev, "%s\n", __func__); =20 pm_runtime_disable(&pdev->dev); return 0; } =20 -#define ONLY_BUS ((void *) 1) /* Match if the device is only a bus. */ - static const struct of_device_id simple_pm_bus_of_match[] =3D { { .compatible =3D "simple-pm-bus", }, - { .compatible =3D "simple-bus", .data =3D ONLY_BUS }, - { .compatible =3D "simple-mfd", .data =3D ONLY_BUS }, - { .compatible =3D "isa", .data =3D ONLY_BUS }, - { .compatible =3D "arm,amba-bus", .data =3D ONLY_BUS }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match); From nobody Mon Jun 29 18:37: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 B70F5C433EF for ; Fri, 4 Feb 2022 09:23:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357811AbiBDJXG (ORCPT ); Fri, 4 Feb 2022 04:23:06 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:41756 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357625AbiBDJWR (ORCPT ); Fri, 4 Feb 2022 04:22: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 dfw.source.kernel.org (Postfix) with ESMTPS id 4F6F0615DC; Fri, 4 Feb 2022 09:22:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DEDFC004E1; Fri, 4 Feb 2022 09:22:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966536; bh=XbccLvw/D0ZxgOoY+2yrv/Y8kbTKWwmyKM28ESuMBcU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KRErtUQZS2eyAQg7+79VtMNhz3i3/DDfvdt4+qCiKejrVaLA9xf1jQ0c1Tnqdak5G JPoG1TZajf7fmgGWGfjAo0k5rpmv6pzr2MQBZsrCNMq19WrAiJ7GMKLh+vo5U+5abT b/ABE2OdVZQMSv6O6bJ5Hd92MpyoHlksiKQ9tYns= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+8112db3ab20e70d50c31@syzkaller.appspotmail.com, Sean Christopherson , Paolo Bonzini , Tadeusz Struk Subject: [PATCH 5.10 06/25] KVM: x86: Forcibly leave nested virt when SMM state is toggled Date: Fri, 4 Feb 2022 10:20:13 +0100 Message-Id: <20220204091914.497446272@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 f7e570780efc5cec9b2ed1e0472a7da14e864fdb upstream. Forcibly leave nested virtualization operation if userspace toggles SMM state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace forces the vCPU out of SMM while it's post-VMXON and then injects an SMI, vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both vmxon=3Dfalse and smm.vmxon=3Dfalse, but all other nVMX state allocated. Don't attempt to gracefully handle the transition as (a) most transitions are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't sufficient information to handle all transitions, e.g. SVM wants access to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede KVM_SET_NESTED_STATE during state restore as the latter disallows putting the vCPU into L2 if SMM is active, and disallows tagging the vCPU as being post-VMXON in SMM if SMM is not active. Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU in an architecturally impossible state. WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665= [inline] WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vm= x/vmx.c:2656 Modules linked in: CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS G= oogle 01/01/2011 RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline] RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00 Call Trace: kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123 kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline] kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:= 460 kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline] kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676 kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline] kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250 kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273 __fput+0x286/0x9f0 fs/file_table.c:311 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x4b0/0x28c0 kernel/signal.c:2862 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x44/0xae Cc: stable@vger.kernel.org Reported-by: syzbot+8112db3ab20e70d50c31@syzkaller.appspotmail.com Signed-off-by: Sean Christopherson Message-Id: <20220125220358.2091737-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Backported-by: Tadeusz Struk Signed-off-by: Sean Christopherson 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/svm/nested.c | 10 ++++++++-- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/svm.h | 2 +- arch/x86/kvm/vmx/nested.c | 1 + arch/x86/kvm/x86.c | 2 ++ 6 files changed, 14 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1285,6 +1285,7 @@ struct kvm_x86_ops { }; =20 struct kvm_x86_nested_ops { + void (*leave_nested)(struct kvm_vcpu *vcpu); int (*check_events)(struct kvm_vcpu *vcpu); bool (*hv_timer_pending)(struct kvm_vcpu *vcpu); int (*get_state)(struct kvm_vcpu *vcpu, --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -783,8 +783,10 @@ void svm_free_nested(struct vcpu_svm *sv /* * Forcibly leave nested mode in order to be able to reset the VCPU later = on. */ -void svm_leave_nested(struct vcpu_svm *svm) +void svm_leave_nested(struct kvm_vcpu *vcpu) { + struct vcpu_svm *svm =3D to_svm(vcpu); + if (is_guest_mode(&svm->vcpu)) { struct vmcb *hsave =3D svm->nested.hsave; struct vmcb *vmcb =3D svm->vmcb; @@ -1185,7 +1187,7 @@ static int svm_set_nested_state(struct k return -EINVAL; =20 if (!(kvm_state->flags & KVM_STATE_NESTED_GUEST_MODE)) { - svm_leave_nested(svm); + svm_leave_nested(vcpu); svm_set_gif(svm, !!(kvm_state->flags & KVM_STATE_NESTED_GIF_SET)); return 0; } @@ -1238,6 +1240,9 @@ static int svm_set_nested_state(struct k copy_vmcb_control_area(&hsave->control, &svm->vmcb->control); hsave->save =3D *save; =20 + if (is_guest_mode(vcpu)) + svm_leave_nested(vcpu); + svm->nested.vmcb12_gpa =3D kvm_state->hdr.svm.vmcb_pa; load_nested_vmcb_control(svm, ctl); nested_prepare_vmcb_control(svm); @@ -1252,6 +1257,7 @@ out_free: } =20 struct kvm_x86_nested_ops svm_nested_ops =3D { + .leave_nested =3D svm_leave_nested, .check_events =3D svm_check_nested_events, .get_nested_state_pages =3D svm_get_nested_state_pages, .get_state =3D svm_get_nested_state, --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -279,7 +279,7 @@ int svm_set_efer(struct kvm_vcpu *vcpu, =20 if ((old_efer & EFER_SVME) !=3D (efer & EFER_SVME)) { if (!(efer & EFER_SVME)) { - svm_leave_nested(svm); + svm_leave_nested(vcpu); svm_set_gif(svm, true); =20 /* --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -393,7 +393,7 @@ static inline bool nested_exit_on_nmi(st =20 int enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa, struct vmcb *nested_vmcb); -void svm_leave_nested(struct vcpu_svm *svm); +void svm_leave_nested(struct kvm_vcpu *vcpu); void svm_free_nested(struct vcpu_svm *svm); int svm_allocate_nested(struct vcpu_svm *svm); int nested_svm_vmrun(struct vcpu_svm *svm); --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -6628,6 +6628,7 @@ __init int nested_vmx_hardware_setup(int } =20 struct kvm_x86_nested_ops vmx_nested_ops =3D { + .leave_nested =3D vmx_leave_nested, .check_events =3D vmx_check_nested_events, .hv_timer_pending =3D nested_vmx_preemption_timer_pending, .get_state =3D vmx_get_nested_state, --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4391,6 +4391,8 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_e vcpu->arch.hflags |=3D HF_SMM_MASK; else vcpu->arch.hflags &=3D ~HF_SMM_MASK; + + kvm_x86_ops.nested_ops->leave_nested(vcpu); kvm_smm_changed(vcpu); } =20 From nobody Mon Jun 29 18:37: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 F40A7C4332F for ; Fri, 4 Feb 2022 09:23:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357668AbiBDJXQ (ORCPT ); Fri, 4 Feb 2022 04:23:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357554AbiBDJWW (ORCPT ); Fri, 4 Feb 2022 04:22: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 50BC2C061777; Fri, 4 Feb 2022 01:22:22 -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 1DA2BB836F5; Fri, 4 Feb 2022 09:22:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5556DC004E1; Fri, 4 Feb 2022 09:22:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966540; bh=penmrp4zrZH2irsB7ocveGnycO9Fjfbz+W0k28rbUS8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h7TA2XU6w/lWpAxHbxCxwIGgy/Bb/GMIAMLeuwHIZJhcC+rOZMgknou59GEa9nE5D e59AGLvRXORhQ4vLcw+YyC5c3HyHMhiSCrSZFeXHflEemuQ+ENgT0lTHk9DpJh2zjy tPkbVKXTSaU7ROqM6rufvBw7jNtqD4ldmv7TnVrc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+cdb5dd11c97cc532efad@syzkaller.appspotmail.com, Linus Torvalds , Suren Baghdasaryan , "Peter Zijlstra (Intel)" , Eric Biggers , Johannes Weiner , Eric Biggers Subject: [PATCH 5.10 07/25] psi: Fix uaf issue when psi trigger is destroyed while being polled Date: Fri, 4 Feb 2022 10:20:14 +0100 Message-Id: <20220204091914.528444186@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Suren Baghdasaryan commit a06247c6804f1a7c86a2e5398a4c1f1db1471848 upstream. With write operation on psi files replacing old trigger with a new one, the lifetime of its waitqueue is totally arbitrary. Overwriting an existing trigger causes its waitqueue to be freed and pending poll() will stumble on trigger->event_wait which was destroyed. Fix this by disallowing to redefine an existing psi trigger. If a write operation is used on a file descriptor with an already existing psi trigger, the operation will fail with EBUSY error. Also bypass a check for psi_disabled in the psi_trigger_destroy as the flag can be flipped after the trigger is created, leading to a memory leak. Fixes: 0e94682b73bf ("psi: introduce psi monitor") Reported-by: syzbot+cdb5dd11c97cc532efad@syzkaller.appspotmail.com Suggested-by: Linus Torvalds Analyzed-by: Eric Biggers Signed-off-by: Suren Baghdasaryan Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Eric Biggers Acked-by: Johannes Weiner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220111232309.1786347-1-surenb@google.com [surenb: backported to 5.10 kernel] CC: stable@vger.kernel.org # 5.10 Signed-off-by: Suren Baghdasaryan 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- Documentation/accounting/psi.rst | 3 + include/linux/psi.h | 2 - include/linux/psi_types.h | 3 - kernel/cgroup/cgroup.c | 11 ++++-- kernel/sched/psi.c | 66 +++++++++++++++++-----------------= ----- 5 files changed, 40 insertions(+), 45 deletions(-) --- a/Documentation/accounting/psi.rst +++ b/Documentation/accounting/psi.rst @@ -92,7 +92,8 @@ Triggers can be set on more than one psi for the same psi metric can be specified. However for each trigger a separ= ate file descriptor is required to be able to poll it separately from others, therefore for each trigger a separate open() syscall should be made even -when opening the same psi interface file. +when opening the same psi interface file. Write operations to a file descr= iptor +with an already existing psi trigger will fail with EBUSY. =20 Monitors activate only when system enters stall state for the monitored psi metric and deactivates upon exit from the stall state. While system is --- a/include/linux/psi.h +++ b/include/linux/psi.h @@ -33,7 +33,7 @@ void cgroup_move_task(struct task_struct =20 struct psi_trigger *psi_trigger_create(struct psi_group *group, char *buf, size_t nbytes, enum psi_res res); -void psi_trigger_replace(void **trigger_ptr, struct psi_trigger *t); +void psi_trigger_destroy(struct psi_trigger *t); =20 __poll_t psi_trigger_poll(void **trigger_ptr, struct file *file, poll_table *wait); --- a/include/linux/psi_types.h +++ b/include/linux/psi_types.h @@ -128,9 +128,6 @@ struct psi_trigger { * events to one per window */ u64 last_event_time; - - /* Refcounting to prevent premature destruction */ - struct kref refcount; }; =20 struct psi_group { --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -3601,6 +3601,12 @@ static ssize_t cgroup_pressure_write(str cgroup_get(cgrp); cgroup_kn_unlock(of->kn); =20 + /* Allow only one trigger per file descriptor */ + if (of->priv) { + cgroup_put(cgrp); + return -EBUSY; + } + psi =3D cgroup_ino(cgrp) =3D=3D 1 ? &psi_system : &cgrp->psi; new =3D psi_trigger_create(psi, buf, nbytes, res); if (IS_ERR(new)) { @@ -3608,8 +3614,7 @@ static ssize_t cgroup_pressure_write(str return PTR_ERR(new); } =20 - psi_trigger_replace(&of->priv, new); - + smp_store_release(&of->priv, new); cgroup_put(cgrp); =20 return nbytes; @@ -3644,7 +3649,7 @@ static __poll_t cgroup_pressure_poll(str =20 static void cgroup_pressure_release(struct kernfs_open_file *of) { - psi_trigger_replace(&of->priv, NULL); + psi_trigger_destroy(of->priv); } #endif /* CONFIG_PSI */ =20 --- a/kernel/sched/psi.c +++ b/kernel/sched/psi.c @@ -1116,7 +1116,6 @@ struct psi_trigger *psi_trigger_create(s t->event =3D 0; t->last_event_time =3D 0; init_waitqueue_head(&t->event_wait); - kref_init(&t->refcount); =20 mutex_lock(&group->trigger_lock); =20 @@ -1145,15 +1144,19 @@ struct psi_trigger *psi_trigger_create(s return t; } =20 -static void psi_trigger_destroy(struct kref *ref) +void psi_trigger_destroy(struct psi_trigger *t) { - struct psi_trigger *t =3D container_of(ref, struct psi_trigger, refcount); - struct psi_group *group =3D t->group; + struct psi_group *group; struct task_struct *task_to_destroy =3D NULL; =20 - if (static_branch_likely(&psi_disabled)) + /* + * We do not check psi_disabled since it might have been disabled after + * the trigger got created. + */ + if (!t) return; =20 + group =3D t->group; /* * Wakeup waiters to stop polling. Can happen if cgroup is deleted * from under a polling process. @@ -1189,9 +1192,9 @@ static void psi_trigger_destroy(struct k mutex_unlock(&group->trigger_lock); =20 /* - * Wait for both *trigger_ptr from psi_trigger_replace and - * poll_task RCUs to complete their read-side critical sections - * before destroying the trigger and optionally the poll_task + * Wait for psi_schedule_poll_work RCU to complete its read-side + * critical section before destroying the trigger and optionally the + * poll_task. */ synchronize_rcu(); /* @@ -1208,18 +1211,6 @@ static void psi_trigger_destroy(struct k kfree(t); } =20 -void psi_trigger_replace(void **trigger_ptr, struct psi_trigger *new) -{ - struct psi_trigger *old =3D *trigger_ptr; - - if (static_branch_likely(&psi_disabled)) - return; - - rcu_assign_pointer(*trigger_ptr, new); - if (old) - kref_put(&old->refcount, psi_trigger_destroy); -} - __poll_t psi_trigger_poll(void **trigger_ptr, struct file *file, poll_table *wait) { @@ -1229,24 +1220,15 @@ __poll_t psi_trigger_poll(void **trigger if (static_branch_likely(&psi_disabled)) return DEFAULT_POLLMASK | EPOLLERR | EPOLLPRI; =20 - rcu_read_lock(); - - t =3D rcu_dereference(*(void __rcu __force **)trigger_ptr); - if (!t) { - rcu_read_unlock(); + t =3D smp_load_acquire(trigger_ptr); + if (!t) return DEFAULT_POLLMASK | EPOLLERR | EPOLLPRI; - } - kref_get(&t->refcount); - - rcu_read_unlock(); =20 poll_wait(file, &t->event_wait, wait); =20 if (cmpxchg(&t->event, 1, 0) =3D=3D 1) ret |=3D EPOLLPRI; =20 - kref_put(&t->refcount, psi_trigger_destroy); - return ret; } =20 @@ -1270,14 +1252,24 @@ static ssize_t psi_write(struct file *fi =20 buf[buf_size - 1] =3D '\0'; =20 - new =3D psi_trigger_create(&psi_system, buf, nbytes, res); - if (IS_ERR(new)) - return PTR_ERR(new); - seq =3D file->private_data; + /* Take seq->lock to protect seq->private from concurrent writes */ mutex_lock(&seq->lock); - psi_trigger_replace(&seq->private, new); + + /* Allow only one trigger per file descriptor */ + if (seq->private) { + mutex_unlock(&seq->lock); + return -EBUSY; + } + + new =3D psi_trigger_create(&psi_system, buf, nbytes, res); + if (IS_ERR(new)) { + mutex_unlock(&seq->lock); + return PTR_ERR(new); + } + + smp_store_release(&seq->private, new); mutex_unlock(&seq->lock); =20 return nbytes; @@ -1312,7 +1304,7 @@ static int psi_fop_release(struct inode { struct seq_file *seq =3D file->private_data; =20 - psi_trigger_replace(&seq->private, NULL); + psi_trigger_destroy(seq->private); return single_release(inode, file); } =20 From nobody Mon Jun 29 18:37: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 2FE9BC433EF for ; Fri, 4 Feb 2022 09:23:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357138AbiBDJXO (ORCPT ); Fri, 4 Feb 2022 04:23:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357434AbiBDJWY (ORCPT ); Fri, 4 Feb 2022 04:22:24 -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 7CBC4C061768; Fri, 4 Feb 2022 01:22:24 -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 D78CB615C6; Fri, 4 Feb 2022 09:22:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F917C004E1; Fri, 4 Feb 2022 09:22:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966543; bh=BaI0hfJd/rGtZze9o9YgtkFOcrtctxZCV+DtA+iaZ6c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aCgoWumMoh2xbuqwIIJpjbDoJtX8a7qvywKXgvFqE1N297ovvVKNLBvixCtuEy6iO BgNPf7b0IvgNuFZYC9q9oooMLPOzRvRI6cmSubIV6XiOTYMc6/7iTCIQxroZYiu+ps cCgAE1UzB8Y5GKWwiqGSYdd6ojLhlk7J6kgt9Dzc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marco Elver , "Peter Zijlstra (Intel)" Subject: [PATCH 5.10 08/25] perf: Rework perf_event_exit_event() Date: Fri, 4 Feb 2022 10:20:15 +0100 Message-Id: <20220204091914.560626177@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 commit ef54c1a476aef7eef26fe13ea10dc090952c00f8 upstream. Make perf_event_exit_event() more robust, such that we can use it from other contexts. Specifically the up and coming remove_on_exec. For this to work we need to address a few issues. Remove_on_exec will not destroy the entire context, so we cannot rely on TASK_TOMBSTONE to disable event_function_call() and we thus have to use perf_remove_from_context(). When using perf_remove_from_context(), there's two races to consider. The first is against close(), where we can have concurrent tear-down of the event. The second is against child_list iteration, which should not find a half baked event. To address this, teach perf_remove_from_context() to special case !ctx->is_active and about DETACH_CHILD. [ elver@google.com: fix racing parent/child exit in sync_child_event(). ] Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210408103605.1676875-2-elver@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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- include/linux/perf_event.h | 1=20 kernel/events/core.c | 144 +++++++++++++++++++++++++---------------= ----- 2 files changed, 81 insertions(+), 64 deletions(-) --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -607,6 +607,7 @@ struct swevent_hlist { #define PERF_ATTACH_TASK_DATA 0x08 #define PERF_ATTACH_ITRACE 0x10 #define PERF_ATTACH_SCHED_CB 0x20 +#define PERF_ATTACH_CHILD 0x40 =20 struct perf_cgroup; struct perf_buffer; --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -2276,6 +2276,26 @@ out: perf_event__header_size(leader); } =20 +static void sync_child_event(struct perf_event *child_event); + +static void perf_child_detach(struct perf_event *event) +{ + struct perf_event *parent_event =3D event->parent; + + if (!(event->attach_state & PERF_ATTACH_CHILD)) + return; + + event->attach_state &=3D ~PERF_ATTACH_CHILD; + + if (WARN_ON_ONCE(!parent_event)) + return; + + lockdep_assert_held(&parent_event->child_mutex); + + sync_child_event(event); + list_del_init(&event->child_list); +} + static bool is_orphaned_event(struct perf_event *event) { return event->state =3D=3D PERF_EVENT_STATE_DEAD; @@ -2383,6 +2403,7 @@ group_sched_out(struct perf_event *group } =20 #define DETACH_GROUP 0x01UL +#define DETACH_CHILD 0x02UL =20 /* * Cross CPU call to remove a performance event @@ -2406,6 +2427,8 @@ __perf_remove_from_context(struct perf_e event_sched_out(event, cpuctx, ctx); if (flags & DETACH_GROUP) perf_group_detach(event); + if (flags & DETACH_CHILD) + perf_child_detach(event); list_del_event(event, ctx); =20 if (!ctx->nr_events && ctx->is_active) { @@ -2437,25 +2460,21 @@ static void perf_remove_from_context(str =20 lockdep_assert_held(&ctx->mutex); =20 - event_function_call(event, __perf_remove_from_context, (void *)flags); - /* - * The above event_function_call() can NO-OP when it hits - * TASK_TOMBSTONE. In that case we must already have been detached - * from the context (by perf_event_exit_event()) but the grouping - * might still be in-tact. - */ - WARN_ON_ONCE(event->attach_state & PERF_ATTACH_CONTEXT); - if ((flags & DETACH_GROUP) && - (event->attach_state & PERF_ATTACH_GROUP)) { - /* - * Since in that case we cannot possibly be scheduled, simply - * detach now. - */ - raw_spin_lock_irq(&ctx->lock); - perf_group_detach(event); + * Because of perf_event_exit_task(), perf_remove_from_context() ought + * to work in the face of TASK_TOMBSTONE, unlike every other + * event_function_call() user. + */ + raw_spin_lock_irq(&ctx->lock); + if (!ctx->is_active) { + __perf_remove_from_context(event, __get_cpu_context(ctx), + ctx, (void *)flags); raw_spin_unlock_irq(&ctx->lock); + return; } + raw_spin_unlock_irq(&ctx->lock); + + event_function_call(event, __perf_remove_from_context, (void *)flags); } =20 /* @@ -12330,14 +12349,17 @@ void perf_pmu_migrate_context(struct pmu } EXPORT_SYMBOL_GPL(perf_pmu_migrate_context); =20 -static void sync_child_event(struct perf_event *child_event, - struct task_struct *child) +static void sync_child_event(struct perf_event *child_event) { struct perf_event *parent_event =3D child_event->parent; u64 child_val; =20 - if (child_event->attr.inherit_stat) - perf_event_read_event(child_event, child); + if (child_event->attr.inherit_stat) { + struct task_struct *task =3D child_event->ctx->task; + + if (task && task !=3D TASK_TOMBSTONE) + perf_event_read_event(child_event, task); + } =20 child_val =3D perf_event_count(child_event); =20 @@ -12352,60 +12374,53 @@ static void sync_child_event(struct perf } =20 static void -perf_event_exit_event(struct perf_event *child_event, - struct perf_event_context *child_ctx, - struct task_struct *child) +perf_event_exit_event(struct perf_event *event, struct perf_event_context = *ctx) { - struct perf_event *parent_event =3D child_event->parent; + struct perf_event *parent_event =3D event->parent; + unsigned long detach_flags =3D 0; =20 - /* - * Do not destroy the 'original' grouping; because of the context - * switch optimization the original events could've ended up in a - * random child task. - * - * If we were to destroy the original group, all group related - * operations would cease to function properly after this random - * child dies. - * - * Do destroy all inherited groups, we don't care about those - * and being thorough is better. - */ - raw_spin_lock_irq(&child_ctx->lock); - WARN_ON_ONCE(child_ctx->is_active); + if (parent_event) { + /* + * Do not destroy the 'original' grouping; because of the + * context switch optimization the original events could've + * ended up in a random child task. + * + * If we were to destroy the original group, all group related + * operations would cease to function properly after this + * random child dies. + * + * Do destroy all inherited groups, we don't care about those + * and being thorough is better. + */ + detach_flags =3D DETACH_GROUP | DETACH_CHILD; + mutex_lock(&parent_event->child_mutex); + } =20 - if (parent_event) - perf_group_detach(child_event); - list_del_event(child_event, child_ctx); - perf_event_set_state(child_event, PERF_EVENT_STATE_EXIT); /* is_event_hup= () */ - raw_spin_unlock_irq(&child_ctx->lock); + perf_remove_from_context(event, detach_flags); + + raw_spin_lock_irq(&ctx->lock); + if (event->state > PERF_EVENT_STATE_EXIT) + perf_event_set_state(event, PERF_EVENT_STATE_EXIT); + raw_spin_unlock_irq(&ctx->lock); =20 /* - * Parent events are governed by their filedesc, retain them. + * Child events can be freed. */ - if (!parent_event) { - perf_event_wakeup(child_event); + if (parent_event) { + mutex_unlock(&parent_event->child_mutex); + /* + * Kick perf_poll() for is_event_hup(); + */ + perf_event_wakeup(parent_event); + free_event(event); + put_event(parent_event); return; } - /* - * Child events can be cleaned up. - */ - - sync_child_event(child_event, child); =20 /* - * Remove this event from the parent's list - */ - WARN_ON_ONCE(parent_event->ctx->parent_ctx); - mutex_lock(&parent_event->child_mutex); - list_del_init(&child_event->child_list); - mutex_unlock(&parent_event->child_mutex); - - /* - * Kick perf_poll() for is_event_hup(). + * Parent events are governed by their filedesc, retain them. */ - perf_event_wakeup(parent_event); - free_event(child_event); - put_event(parent_event); + perf_event_wakeup(event); } =20 static void perf_event_exit_task_context(struct task_struct *child, int ct= xn) @@ -12462,7 +12477,7 @@ static void perf_event_exit_task_context perf_event_task(child, child_ctx, 0); =20 list_for_each_entry_safe(child_event, next, &child_ctx->event_list, event= _entry) - perf_event_exit_event(child_event, child_ctx, child); + perf_event_exit_event(child_event, child_ctx); =20 mutex_unlock(&child_ctx->mutex); =20 @@ -12722,6 +12737,7 @@ inherit_event(struct perf_event *parent_ */ raw_spin_lock_irqsave(&child_ctx->lock, flags); add_event_to_ctx(child_event, child_ctx); + child_event->attach_state |=3D PERF_ATTACH_CHILD; raw_spin_unlock_irqrestore(&child_ctx->lock, flags); =20 /* From nobody Mon Jun 29 18:37: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 85222C433FE for ; Fri, 4 Feb 2022 09:23:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357867AbiBDJXX (ORCPT ); Fri, 4 Feb 2022 04:23:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357404AbiBDJW1 (ORCPT ); Fri, 4 Feb 2022 04:22:27 -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 75997C06177B; Fri, 4 Feb 2022 01:22:27 -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 EE1F9615F2; Fri, 4 Feb 2022 09:22:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3FFFC004E1; Fri, 4 Feb 2022 09:22:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966546; bh=6hLwUiBraFezqxX9zXLap+AGvcq0AkpuGNlQVDPofPA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ItO7gmOSB2qWWW5hq1Fudc4BEtVpjotCCayCwAZDgGbSPuSTZO0KtdwZGMNbjOBbR TBR3nL3ob9yxqe6GfYvDb+uaxOWCksbjg4TBpNfBvVtRNM2HbTmj4Jkic3Ns5C2Vr9 eIEd/CJaa039LKDoNkQcuIt65lNLTamMTQOaxS+M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Namhyung Kim , "Peter Zijlstra (Intel)" Subject: [PATCH 5.10 09/25] perf/core: Fix cgroup event list management Date: Fri, 4 Feb 2022 10:20:16 +0100 Message-Id: <20220204091914.594276962@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Namhyung Kim commit c5de60cd622a2607c043ba65e25a6e9998a369f9 upstream. The active cgroup events are managed in the per-cpu cgrp_cpuctx_list. This list is only accessed from current cpu and not protected by any locks. But from the commit ef54c1a476ae ("perf: Rework perf_event_exit_event()"), it's possible to access (actually modify) the list from another cpu. In the perf_remove_from_context(), it can remove an event from the context without an IPI when the context is not active. This is not safe with cgroup events which can have some active events in the context even if ctx->is_active is 0 at the moment. The target cpu might be in the middle of list iteration at the same time. If the event is enabled when it's about to be closed, it might call perf_cgroup_event_disable() and list_del() with the cgrp_cpuctx_list on a different cpu. This resulted in a crash due to an invalid list pointer access during the cgroup list traversal on the cpu which the event belongs to. Let's fallback to IPI to access the cgrp_cpuctx_list from that cpu. Similarly, perf_install_in_context() should use IPI for the cgroup events too. Fixes: ef54c1a476ae ("perf: Rework perf_event_exit_event()") Signed-off-by: Namhyung Kim Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220124195808.2252071-1-namhyung@kernel.org 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- kernel/events/core.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -2466,7 +2466,11 @@ static void perf_remove_from_context(str * event_function_call() user. */ raw_spin_lock_irq(&ctx->lock); - if (!ctx->is_active) { + /* + * Cgroup events are per-cpu events, and must IPI because of + * cgrp_cpuctx_list. + */ + if (!ctx->is_active && !is_cgroup_event(event)) { __perf_remove_from_context(event, __get_cpu_context(ctx), ctx, (void *)flags); raw_spin_unlock_irq(&ctx->lock); @@ -2899,11 +2903,14 @@ perf_install_in_context(struct perf_even * perf_event_attr::disabled events will not run and can be initialized * without IPI. Except when this is the first event for the context, in * that case we need the magic of the IPI to set ctx->is_active. + * Similarly, cgroup events for the context also needs the IPI to + * manipulate the cgrp_cpuctx_list. * * The IOC_ENABLE that is sure to follow the creation of a disabled * event will issue the IPI and reprogram the hardware. */ - if (__perf_effective_state(event) =3D=3D PERF_EVENT_STATE_OFF && ctx->nr_= events) { + if (__perf_effective_state(event) =3D=3D PERF_EVENT_STATE_OFF && + ctx->nr_events && !is_cgroup_event(event)) { raw_spin_lock_irq(&ctx->lock); if (ctx->task =3D=3D TASK_TOMBSTONE) { raw_spin_unlock_irq(&ctx->lock); From nobody Mon Jun 29 18:37: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 8984CC433F5 for ; Fri, 4 Feb 2022 09:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357436AbiBDJVa (ORCPT ); Fri, 4 Feb 2022 04:21:30 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:40582 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357426AbiBDJVM (ORCPT ); Fri, 4 Feb 2022 04:21: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 0A686615C6; Fri, 4 Feb 2022 09:21:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB6F1C004E1; Fri, 4 Feb 2022 09:21:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966471; bh=/Pp8SlxXCCL22wDsYOvb5Wwy21cTYp+xDoOEpKIfey4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WuWgvAN551pF9BCix1GuWjWh11JnHP5wskjyILmhWeRCuTSpbdtMDWsTDSJLse+4Q Rgoxmez7QZJSfzIufvE+b0WetHs0hoBOafO9wbVxRkSd0GDTovvlq87tzwQ6oqzSy7 RMedgktXlyH0m+2heMDIbOuAMuoK19Y5QGHW6syQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tony Luck , Ingo Molnar Subject: [PATCH 5.10 10/25] x86/mce: Add Xeon Sapphire Rapids to list of CPUs that support PPIN Date: Fri, 4 Feb 2022 10:20:17 +0100 Message-Id: <20220204091914.626046318@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Tony Luck commit a331f5fdd36dba1ffb0239a4dfaaf1df91ff1aab upstream. New CPU model, same MSRs to control and read the inventory number. Signed-off-by: Tony Luck Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210319173919.291428-1-tony.luck@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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- arch/x86/kernel/cpu/mce/intel.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/kernel/cpu/mce/intel.c +++ b/arch/x86/kernel/cpu/mce/intel.c @@ -486,6 +486,7 @@ static void intel_ppin_init(struct cpuin case INTEL_FAM6_BROADWELL_X: case INTEL_FAM6_SKYLAKE_X: case INTEL_FAM6_ICELAKE_X: + case INTEL_FAM6_SAPPHIRERAPIDS_X: case INTEL_FAM6_XEON_PHI_KNL: case INTEL_FAM6_XEON_PHI_KNM: =20 From nobody Mon Jun 29 18:37: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 75C38C433FE for ; Fri, 4 Feb 2022 09:21:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357533AbiBDJVp (ORCPT ); Fri, 4 Feb 2022 04:21:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357397AbiBDJVR (ORCPT ); Fri, 4 Feb 2022 04:21:17 -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 0B1E0C06174E; Fri, 4 Feb 2022 01:21: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 ams.source.kernel.org (Postfix) with ESMTPS id 836E9B836B9; Fri, 4 Feb 2022 09:21:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCF46C004E1; Fri, 4 Feb 2022 09:21:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966474; bh=Xg9f6CFllZYrzcO1n0gxcgeybqgoqA71gctmrnJvsx0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UrmFBJIpG5GcIC7LtQXTT/MRWa72iG23gBaV6NPvP8Z/Yl1RpDfGGQHpQGOwFOj8j v5xnAypoOnYXhtc5LQGzLz28S1n7HVaE/B086ZyXHdTA7Ws43IsP8kyD9zrNLeTetO arWLhWq1Tw7xVSFAGGNwQT7igH6FazFzu8F1bLhE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ailin Xu , Tony Luck , Borislav Petkov Subject: [PATCH 5.10 11/25] x86/cpu: Add Xeon Icelake-D to list of CPUs that support PPIN Date: Fri, 4 Feb 2022 10:20:18 +0100 Message-Id: <20220204091914.657258819@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Tony Luck commit e464121f2d40eabc7d11823fb26db807ce945df4 upstream. Missed adding the Icelake-D CPU to the list. It uses the same MSRs to control and read the inventory number as all the other models. Fixes: dc6b025de95b ("x86/mce: Add Xeon Icelake to list of CPUs that suppor= t PPIN") Reported-by: Ailin Xu Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: Link: https://lore.kernel.org/r/20220121174743.1875294-2-tony.luck@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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- arch/x86/kernel/cpu/mce/intel.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/kernel/cpu/mce/intel.c +++ b/arch/x86/kernel/cpu/mce/intel.c @@ -486,6 +486,7 @@ static void intel_ppin_init(struct cpuin case INTEL_FAM6_BROADWELL_X: case INTEL_FAM6_SKYLAKE_X: case INTEL_FAM6_ICELAKE_X: + case INTEL_FAM6_ICELAKE_D: case INTEL_FAM6_SAPPHIRERAPIDS_X: case INTEL_FAM6_XEON_PHI_KNL: case INTEL_FAM6_XEON_PHI_KNM: From nobody Mon Jun 29 18:37: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 E4A34C433EF for ; Fri, 4 Feb 2022 09:21:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357472AbiBDJVj (ORCPT ); Fri, 4 Feb 2022 04:21:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357476AbiBDJVS (ORCPT ); Fri, 4 Feb 2022 04:21:18 -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 A57E8C06173E; Fri, 4 Feb 2022 01:21: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 dfw.source.kernel.org (Postfix) with ESMTPS id 102A6615F4; Fri, 4 Feb 2022 09:21:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF1DEC004E1; Fri, 4 Feb 2022 09:21:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966477; bh=xSOtAzgdlU2pDUEzx3yAN0GwhWj6yoko8OJxHPZoVcI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fZCNFYk1fWYtLkJSuAfAL3ahAYR7DmS7PrBbXYUkGBKxLe5JN6IpYN/TWRCmeWjE/ cSanDzTDxPMK4UYwGbU7BM/hUEQwtEVYOMCxXTcFwjxw58mC8anISfBA5FYXogHMlE DBPGp/KF8yixfx55ZJA7c1mnIhlqnWyyKzRIaeeM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Stapelberg , Maxime Ripard Subject: [PATCH 5.10 12/25] drm/vc4: hdmi: Make sure the device is powered with CEC Date: Fri, 4 Feb 2022 10:20:19 +0100 Message-Id: <20220204091914.688259001@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Maxime Ripard Commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream. The original commit depended on a rework commit (724fc856c09e ("drm/vc4: hdmi: Split the CEC disable / enable functions in two")) that (rightfully) didn't reach stable. However, probably because the context changed, when the patch was applied to stable the pm_runtime_put called got moved to the end of the vc4_hdmi_cec_adap_enable function (that would have become vc4_hdmi_cec_disable with the rework) to vc4_hdmi_cec_init. This means that at probe time, we now drop our reference to the clocks and power domains and thus end up with a CPU hang when the CPU tries to access registers. The call to pm_runtime_resume_and_get() is also problematic since the .adap_enable CEC hook is called both to enable and to disable the controller. That means that we'll now call pm_runtime_resume_and_get() at disable time as well, messing with the reference counting. The behaviour we should have though would be to have pm_runtime_resume_and_get() called when the CEC controller is enabled, and pm_runtime_put when it's disabled. We need to move things around a bit to behave that way, but it aligns stable with upstream. Cc: # 5.10.x Cc: # 5.15.x Cc: # 5.16.x Reported-by: Michael Stapelberg Signed-off-by: Maxime Ripard 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/gpu/drm/vc4/vc4_hdmi.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1402,18 +1402,18 @@ static int vc4_hdmi_cec_adap_enable(stru u32 val; int ret; =20 - ret =3D pm_runtime_resume_and_get(&vc4_hdmi->pdev->dev); - if (ret) - return ret; - - val =3D HDMI_READ(HDMI_CEC_CNTRL_5); - val &=3D ~(VC4_HDMI_CEC_TX_SW_RESET | VC4_HDMI_CEC_RX_SW_RESET | - VC4_HDMI_CEC_CNT_TO_4700_US_MASK | - VC4_HDMI_CEC_CNT_TO_4500_US_MASK); - val |=3D ((4700 / usecs) << VC4_HDMI_CEC_CNT_TO_4700_US_SHIFT) | - ((4500 / usecs) << VC4_HDMI_CEC_CNT_TO_4500_US_SHIFT); - if (enable) { + ret =3D pm_runtime_resume_and_get(&vc4_hdmi->pdev->dev); + if (ret) + return ret; + + val =3D HDMI_READ(HDMI_CEC_CNTRL_5); + val &=3D ~(VC4_HDMI_CEC_TX_SW_RESET | VC4_HDMI_CEC_RX_SW_RESET | + VC4_HDMI_CEC_CNT_TO_4700_US_MASK | + VC4_HDMI_CEC_CNT_TO_4500_US_MASK); + val |=3D ((4700 / usecs) << VC4_HDMI_CEC_CNT_TO_4700_US_SHIFT) | + ((4500 / usecs) << VC4_HDMI_CEC_CNT_TO_4500_US_SHIFT); + HDMI_WRITE(HDMI_CEC_CNTRL_5, val | VC4_HDMI_CEC_TX_SW_RESET | VC4_HDMI_CEC_RX_SW_RESET); HDMI_WRITE(HDMI_CEC_CNTRL_5, val); @@ -1439,7 +1439,10 @@ static int vc4_hdmi_cec_adap_enable(stru HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, VC4_HDMI_CPU_CEC); HDMI_WRITE(HDMI_CEC_CNTRL_5, val | VC4_HDMI_CEC_TX_SW_RESET | VC4_HDMI_CEC_RX_SW_RESET); + + pm_runtime_put(&vc4_hdmi->pdev->dev); } + return 0; } =20 @@ -1531,8 +1534,6 @@ static int vc4_hdmi_cec_init(struct vc4_ if (ret < 0) goto err_delete_cec_adap; =20 - pm_runtime_put(&vc4_hdmi->pdev->dev); - return 0; =20 err_delete_cec_adap: From nobody Mon Jun 29 18:37: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 B8546C433F5 for ; Fri, 4 Feb 2022 09:21:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357547AbiBDJVr (ORCPT ); Fri, 4 Feb 2022 04:21:47 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:50622 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357496AbiBDJVX (ORCPT ); Fri, 4 Feb 2022 04:21:23 -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 00A0FB836EF; Fri, 4 Feb 2022 09:21:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B46FC004E1; Fri, 4 Feb 2022 09:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966480; bh=6WAZVQB1k7CL70Rc41o0FuDqh/twC+HshTlA9IRPVac=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BxfFHmUcOkcMcR8jEfF8rw/l+qJyZLOkYZZPp1yXVxCjdsob43U+TMj9/gbdl4RUP cE3Rv1zlEz/FZu+KeOeVPFZLnVRMPN8xx1m+dgA0LIqKwvugzOYL+UNbS0D02IG0Ap GxN1Qoj3YNsYsP1OGfBAPnw2f8kgGXP9dsaDXHAk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tabitha Sable , "Eric W. Biederman" , Tejun Heo Subject: [PATCH 5.10 13/25] cgroup-v1: Require capabilities to set release_agent Date: Fri, 4 Feb 2022 10:20:20 +0100 Message-Id: <20220204091914.718640241@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 W. Biederman commit 24f6008564183aa120d07c03d9289519c2fe02af upstream. The cgroup release_agent is called with call_usermodehelper. The function call_usermodehelper starts the release_agent with a full set fo capabilitie= s. Therefore require capabilities when setting the release_agaent. Reported-by: Tabitha Sable Tested-by: Tabitha Sable Fixes: 81a6a5cdd2c5 ("Task Control Groups: automatic userspace notification= of idle cgroups") Cc: stable@vger.kernel.org # v2.6.24+ Signed-off-by: "Eric W. Biederman" Signed-off-by: Tejun Heo 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- kernel/cgroup/cgroup-v1.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/kernel/cgroup/cgroup-v1.c +++ b/kernel/cgroup/cgroup-v1.c @@ -545,6 +545,14 @@ static ssize_t cgroup_release_agent_writ =20 BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX); =20 + /* + * Release agent gets called with all capabilities, + * require capabilities to set release agent. + */ + if ((of->file->f_cred->user_ns !=3D &init_user_ns) || + !capable(CAP_SYS_ADMIN)) + return -EPERM; + cgrp =3D cgroup_kn_lock_live(of->kn, false); if (!cgrp) return -ENODEV; @@ -958,6 +966,12 @@ int cgroup1_parse_param(struct fs_contex /* Specifying two release agents is forbidden */ if (ctx->release_agent) return invalfc(fc, "release_agent respecified"); + /* + * Release agent gets called with all capabilities, + * require capabilities to set release agent. + */ + if ((fc->user_ns !=3D &init_user_ns) || !capable(CAP_SYS_ADMIN)) + return invalfc(fc, "Setting release_agent not allowed"); ctx->release_agent =3D param->string; param->string =3D NULL; break; From nobody Mon Jun 29 18:37: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 61A72C4332F for ; Fri, 4 Feb 2022 09:21:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357446AbiBDJV5 (ORCPT ); Fri, 4 Feb 2022 04:21:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357425AbiBDJV3 (ORCPT ); Fri, 4 Feb 2022 04:21:29 -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 8F8F3C061769; Fri, 4 Feb 2022 01:21: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 4D12AB836EE; Fri, 4 Feb 2022 09:21:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EF58C004E1; Fri, 4 Feb 2022 09:21:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966484; bh=mXHryGW09fA1yrZtSbOXLAiQQeihs2gSPyR7qHrk/wI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mFQDoHAXbqg5nA/XCAP1ntNS4tefvvXx1YvGSDPXCI7FAuI6AfqHY8FxwDQ5ao9tp U4zTUVOn6g2dV9UnEc3A9FAxTAoEay39iZp/wcvp0IQ6mTemFaRENt7U0PKl+GgzMi 7k6r++oVI04Bpcp09/0ENNNjDqTZ9TE8fUMepa2Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maor Dickman , Roi Dayan , Saeed Mahameed Subject: [PATCH 5.10 14/25] net/mlx5e: Fix handling of wrong devices during bond netevent Date: Fri, 4 Feb 2022 10:20:21 +0100 Message-Id: <20220204091914.749913501@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Maor Dickman commit ec41332e02bd0acf1f24206867bb6a02f5877a62 upstream. Current implementation of bond netevent handler only check if the handled netdev is VF representor and it missing a check if the VF representor is on the same phys device of the bond handling the netevent. Fix by adding the missing check and optimizing the check if the netdev is VF representor so it will not access uninitialized private data and crashes. BUG: kernel NULL pointer dereference, address: 000000000000036c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Workqueue: eth3bond0 bond_mii_monitor [bonding] RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core] RSP: 0018:ffff88812d69fd60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000 RDX: ffff88812d69fe10 RSI: 000000000000001b RDI: ffff8881cf800880 RBP: ffff8881cf800000 R08: 00000445cabccf2b R09: 0000000000000008 R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10 R13: 00000000fffffffe R14: ffff88820c0f9000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88846fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036c CR3: 0000000103d80006 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core] mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core] mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core] raw_notifier_call_chain+0x41/0x60 call_netdevice_notifiers_info+0x34/0x80 netdev_lower_state_changed+0x4e/0xa0 bond_mii_monitor+0x56b/0x640 [bonding] process_one_work+0x1b9/0x390 worker_thread+0x4d/0x3d0 ? rescuer_thread+0x350/0x350 kthread+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 Fixes: 7e51891a237f ("net/mlx5e: Use netdev events to set/del egress acl fo= rward-to-vport rule") Signed-off-by: Maor Dickman Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ethernet/mellanox/mlx5/core/en/rep/bond.c | 32 +++++++------= ----- 1 file changed, 14 insertions(+), 18 deletions(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/bond.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/bond.c @@ -183,18 +183,7 @@ void mlx5e_rep_bond_unslave(struct mlx5_ =20 static bool mlx5e_rep_is_lag_netdev(struct net_device *netdev) { - struct mlx5e_rep_priv *rpriv; - struct mlx5e_priv *priv; - - /* A given netdev is not a representor or not a slave of LAG configuratio= n */ - if (!mlx5e_eswitch_rep(netdev) || !netif_is_lag_port(netdev)) - return false; - - priv =3D netdev_priv(netdev); - rpriv =3D priv->ppriv; - - /* Egress acl forward to vport is supported only non-uplink representor */ - return rpriv->rep->vport !=3D MLX5_VPORT_UPLINK; + return netif_is_lag_port(netdev) && mlx5e_eswitch_vf_rep(netdev); } =20 static void mlx5e_rep_changelowerstate_event(struct net_device *netdev, vo= id *ptr) @@ -210,9 +199,6 @@ static void mlx5e_rep_changelowerstate_e u16 fwd_vport_num; int err; =20 - if (!mlx5e_rep_is_lag_netdev(netdev)) - return; - info =3D ptr; lag_info =3D info->lower_state_info; /* This is not an event of a representor becoming active slave */ @@ -266,9 +252,6 @@ static void mlx5e_rep_changeupper_event( struct net_device *lag_dev; struct mlx5e_priv *priv; =20 - if (!mlx5e_rep_is_lag_netdev(netdev)) - return; - priv =3D netdev_priv(netdev); rpriv =3D priv->ppriv; lag_dev =3D info->upper_dev; @@ -293,6 +276,19 @@ static int mlx5e_rep_esw_bond_netevent(s unsigned long event, void *ptr) { struct net_device *netdev =3D netdev_notifier_info_to_dev(ptr); + struct mlx5e_rep_priv *rpriv; + struct mlx5e_rep_bond *bond; + struct mlx5e_priv *priv; + + if (!mlx5e_rep_is_lag_netdev(netdev)) + return NOTIFY_DONE; + + bond =3D container_of(nb, struct mlx5e_rep_bond, nb); + priv =3D netdev_priv(netdev); + rpriv =3D mlx5_eswitch_get_uplink_priv(priv->mdev->priv.eswitch, REP_ETH); + /* Verify VF representor is on the same device of the bond handling the n= etevent. */ + if (rpriv->uplink_priv.bond !=3D bond) + return NOTIFY_DONE; =20 switch (event) { case NETDEV_CHANGELOWERSTATE: From nobody Mon Jun 29 18:37: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 927AAC433FE for ; Fri, 4 Feb 2022 09:22:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357390AbiBDJWA (ORCPT ); Fri, 4 Feb 2022 04:22:00 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:50672 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357417AbiBDJVa (ORCPT ); Fri, 4 Feb 2022 04:21: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 ams.source.kernel.org (Postfix) with ESMTPS id BC71BB836E9; Fri, 4 Feb 2022 09:21:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4DEEC004E1; Fri, 4 Feb 2022 09:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966487; bh=FAjeDFHv7D9J2c8F4j6IzyeX2v7R5BW6Uj33dBF69mE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EbPFYiP5fV+bJeXrMgiUjPBFRwXJoq2JSWuD1hf6AMwwrkrHun5IKIrkHJ2/TdG84 7yK0lFoqepXpRpPq+1sSUjTXKdI6+AEzeohIhjfkXQAsD/7/mteLR7gf9fYdS7yw8/ 0WdNBLamBk1zger64x3AaZPPTJDeEcvqXOHw9XIs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maher Sanalla , Moshe Shemesh , Saeed Mahameed Subject: [PATCH 5.10 15/25] net/mlx5: Use del_timer_sync in fw reset flow of halting poll Date: Fri, 4 Feb 2022 10:20:22 +0100 Message-Id: <20220204091914.782500118@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Maher Sanalla commit 3c5193a87b0fea090aa3f769d020337662d87b5e upstream. Substitute del_timer() with del_timer_sync() in fw reset polling deactivation flow, in order to prevent a race condition which occurs when del_timer() is called and timer is deactivated while another process is handling the timer interrupt. A situation that led to the following call trace: RIP: 0010:run_timer_softirq+0x137/0x420 recalibrate_cpu_khz+0x10/0x10 ktime_get+0x3e/0xa0 ? sched_clock_cpu+0xb/0xc0 __do_softirq+0xf5/0x2ea irq_exit_rcu+0xc1/0xf0 sysvec_apic_timer_interrupt+0x9e/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 Fixes: 38b9f903f22b ("net/mlx5: Handle sync reset request event") Signed-off-by: Maher Sanalla Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c @@ -131,7 +131,7 @@ static void mlx5_stop_sync_reset_poll(st { struct mlx5_fw_reset *fw_reset =3D dev->priv.fw_reset; =20 - del_timer(&fw_reset->timer); + del_timer_sync(&fw_reset->timer); } =20 static void mlx5_sync_reset_clear_reset_requested(struct mlx5_core_dev *de= v, bool poll_health) From nobody Mon Jun 29 18:37: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 2F3A7C433EF for ; Fri, 4 Feb 2022 09:22:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357529AbiBDJWK (ORCPT ); Fri, 4 Feb 2022 04:22:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357453AbiBDJVe (ORCPT ); Fri, 4 Feb 2022 04:21: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 7F656C061401; Fri, 4 Feb 2022 01:21:33 -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 47E52B836EC; Fri, 4 Feb 2022 09:21:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D739C004E1; Fri, 4 Feb 2022 09:21:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966491; bh=t6fosH+/jo0oyk3kX5RJYCWAgBNoLIkcuTpouivDE3Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w4X6R4zdwaRWCPk7Q8xOtCXiduOiMqI2VYUPHPList7nq0c3KGulx7eYQUHtvP5Oe SF6mCeovVSYtNrMHUphXTPAjBsgRnoUa12chZompe4cestSKRhvHLISKfaLRbz5V1L Hl8ClXGJyqBoDZtmojec7hBK/TaHB8oRUcwhdcIk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maor Dickman , Roi Dayan , Saeed Mahameed Subject: [PATCH 5.10 16/25] net/mlx5: E-Switch, Fix uninitialized variable modact Date: Fri, 4 Feb 2022 10:20:23 +0100 Message-Id: <20220204091914.813309593@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Maor Dickman commit d8e5883d694bb053b19c4142a2d1f43a34f6fe2c upstream. The variable modact is not initialized before used in command modify header allocation which can cause command to fail. Fix by initializing modact with zeros. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 8f1e0b97cc70 ("net/mlx5: E-Switch, Mark miss packets with new chain = id mapping") Signed-off-by: Maor Dickman Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ethernet/mellanox/mlx5/core/lib/fs_chains.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/lib/fs_chains.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/fs_chains.c @@ -292,7 +292,7 @@ static int create_chain_restore(struct fs_chain *chain) { struct mlx5_eswitch *esw =3D chain->chains->dev->priv.eswitch; - char modact[MLX5_UN_SZ_BYTES(set_add_copy_action_in_auto)]; + u8 modact[MLX5_UN_SZ_BYTES(set_add_copy_action_in_auto)] =3D {}; struct mlx5_fs_chains *chains =3D chain->chains; enum mlx5e_tc_attr_to_reg chain_to_reg; struct mlx5_modify_hdr *mod_hdr; From nobody Mon Jun 29 18:37: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 4ABD5C433FE for ; Fri, 4 Feb 2022 09:22:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357600AbiBDJWG (ORCPT ); Fri, 4 Feb 2022 04:22:06 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:41052 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357460AbiBDJVf (ORCPT ); Fri, 4 Feb 2022 04:21: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 dfw.source.kernel.org (Postfix) with ESMTPS id CDE43615A5; Fri, 4 Feb 2022 09:21:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D956C004E1; Fri, 4 Feb 2022 09:21:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966494; bh=iaE1IqOh0EjTj9ysylMCuepe6iN/kPDrrbFWOLuRBw8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F18zXtQE3L8MHnGDNjXA1Z3UaDH/wTM2reJFWA9//DJ9GNJlIiUzVs6m53eBNdHHw YsV78MDQSpwW3eDUaZTS7pjDdYkExF37ZBvUmqmtpM1xwPPPM6deh5L0YEjM4CGtnz MhX7hpLaxNDh0vdFxeV6xkyjUtBn/xJIjHkMGy9I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Georgi Valkov , Jan Kiszka , Jakub Kicinski Subject: [PATCH 5.10 17/25] ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback Date: Fri, 4 Feb 2022 10:20:24 +0100 Message-Id: <20220204091914.844079408@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Georgi Valkov commit 63e4b45c82ed1bde979da7052229a4229ce9cabf upstream. When rx_buf is allocated we need to account for IPHETH_IP_ALIGN, which reduces the usable size by 2 bytes. Otherwise we have 1512 bytes usable instead of 1514, and if we receive more than 1512 bytes, ipheth_rcvbulk_callback is called with status -EOVERFLOW, after which the driver malfunctiones and all communication stops. Resolves ipheth 2-1:4.2: ipheth_rcvbulk_callback: urb status: -75 Fixes: f33d9e2b48a3 ("usbnet: ipheth: fix connectivity with iOS 14") Signed-off-by: Georgi Valkov Tested-by: Jan Kiszka Link: https://lore.kernel.org/all/B60B8A4B-92A0-49B3-805D-809A2433B46C@abv.= bg/ Link: https://lore.kernel.org/all/24851bd2769434a5fc24730dce8e8a984c5a4505.= 1643699778.git.jan.kiszka@siemens.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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/usb/ipheth.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/usb/ipheth.c +++ b/drivers/net/usb/ipheth.c @@ -121,7 +121,7 @@ static int ipheth_alloc_urbs(struct iphe if (tx_buf =3D=3D NULL) goto free_rx_urb; =20 - rx_buf =3D usb_alloc_coherent(iphone->udev, IPHETH_BUF_SIZE, + rx_buf =3D usb_alloc_coherent(iphone->udev, IPHETH_BUF_SIZE + IPHETH_IP_A= LIGN, GFP_KERNEL, &rx_urb->transfer_dma); if (rx_buf =3D=3D NULL) goto free_tx_buf; @@ -146,7 +146,7 @@ error_nomem: =20 static void ipheth_free_urbs(struct ipheth_device *iphone) { - usb_free_coherent(iphone->udev, IPHETH_BUF_SIZE, iphone->rx_buf, + usb_free_coherent(iphone->udev, IPHETH_BUF_SIZE + IPHETH_IP_ALIGN, iphone= ->rx_buf, iphone->rx_urb->transfer_dma); usb_free_coherent(iphone->udev, IPHETH_BUF_SIZE, iphone->tx_buf, iphone->tx_urb->transfer_dma); @@ -317,7 +317,7 @@ static int ipheth_rx_submit(struct iphet =20 usb_fill_bulk_urb(dev->rx_urb, udev, usb_rcvbulkpipe(udev, dev->bulk_in), - dev->rx_buf, IPHETH_BUF_SIZE, + dev->rx_buf, IPHETH_BUF_SIZE + IPHETH_IP_ALIGN, ipheth_rcvbulk_callback, dev); dev->rx_urb->transfer_flags |=3D URB_NO_TRANSFER_DMA_MAP; From nobody Mon Jun 29 18:37: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 1C8B9C433EF for ; Fri, 4 Feb 2022 09:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357542AbiBDJWP (ORCPT ); Fri, 4 Feb 2022 04:22:15 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:41128 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357438AbiBDJVi (ORCPT ); Fri, 4 Feb 2022 04:21: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 dfw.source.kernel.org (Postfix) with ESMTPS id 37746615F5; Fri, 4 Feb 2022 09:21:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED55CC004E1; Fri, 4 Feb 2022 09:21:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966497; bh=QrZLry4insApv+gQ37l7e+SnTkVoC6w8ESMnHsJwm00=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZoGcCk+W/tnNCPg7SWwRYNSTKhiCPh4pa875AK0QEI47Ro7F3DtA0PzxFOBum7b8Q LqIO3brlTMQkstwaHwxe/4vr9R+XsX/uhmzuPa1tYrxXzxJJgPKH7tfCEh2cj8VkTV AwVNHAqS7GXMAuTeJVwOhXWyH3nq5p3k6MhMRJos= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sudheesh Mavila , Raju Rangoju , Tom Lendacky , Jakub Kicinski Subject: [PATCH 5.10 18/25] net: amd-xgbe: ensure to reset the tx_timer_active flag Date: Fri, 4 Feb 2022 10:20:25 +0100 Message-Id: <20220204091914.874394809@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Raju Rangoju commit 7674b7b559b683478c3832527c59bceb169e701d upstream. Ensure to reset the tx_timer_active flag in xgbe_stop(), otherwise a port restart may result in tx timeout due to uncleared flag. Fixes: c635eaacbf77 ("amd-xgbe: Remove Tx coalescing") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Raju Rangoju Acked-by: Tom Lendacky Link: https://lore.kernel.org/r/20220127060222.453371-1-Raju.Rangoju@amd.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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c @@ -721,7 +721,9 @@ static void xgbe_stop_timers(struct xgbe if (!channel->tx_ring) break; =20 + /* Deactivate the Tx timer */ del_timer_sync(&channel->tx_timer); + channel->tx_timer_active =3D 0; } } =20 From nobody Mon Jun 29 18:37: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 8D5C2C433EF for ; Fri, 4 Feb 2022 09:22:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357642AbiBDJWT (ORCPT ); Fri, 4 Feb 2022 04:22:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357509AbiBDJVn (ORCPT ); Fri, 4 Feb 2022 04:21: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 2BD35C061751; Fri, 4 Feb 2022 01:21: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 DC68AB836EF; Fri, 4 Feb 2022 09:21:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AB67C004E1; Fri, 4 Feb 2022 09:21:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966500; bh=qOJ6whip6kE3To8wzXTaEVKxv041YSfcDKIcXA478C0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XBnACFGs3XAOEW8a8qCbWIT7YclBO9g3tXa98psrSj4HzmzD9qDILTU5pEgXYGEt+ o8dVvxwwr1cTvfJc4aLglO8V+PWiRtbXpYrqNlf7XaSziY/KZHmOZYQrnjynCMMrPc l7QgdaijPMN9Wo66T40+ZwFyy/wb/ApdmXi6atzI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tom Lendacky , Shyam Sundar S K , Jakub Kicinski Subject: [PATCH 5.10 19/25] net: amd-xgbe: Fix skb data length underflow Date: Fri, 4 Feb 2022 10:20:26 +0100 Message-Id: <20220204091914.902444262@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Shyam Sundar S K commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee upstream. There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. Fixes: 622c36f143fc ("amd-xgbe: Fix jumbo MTU processing on newer hardware") Suggested-by: Tom Lendacky Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Link: https://lore.kernel.org/r/20220127092003.2812745-1-Shyam-sundar.S-k@a= md.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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c @@ -2559,6 +2559,14 @@ read_again: buf2_len =3D xgbe_rx_buf2_len(rdata, packet, len); len +=3D buf2_len; =20 + if (buf2_len > rdata->rx.buf.dma_len) { + /* Hardware inconsistency within the descriptors + * that has resulted in a length underflow. + */ + error =3D 1; + goto skip_data; + } + if (!skb) { skb =3D xgbe_create_skb(pdata, napi, rdata, buf1_len); @@ -2588,8 +2596,10 @@ skip_data: if (!last || context_next) goto read_again; =20 - if (!skb) + if (!skb || error) { + dev_kfree_skb(skb); goto next_packet; + } =20 /* Be sure we don't exceed the configured MTU */ max_len =3D netdev->mtu + ETH_HLEN; From nobody Mon Jun 29 18:37: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 4ABC2C433EF for ; Fri, 4 Feb 2022 09:22:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357558AbiBDJWW (ORCPT ); Fri, 4 Feb 2022 04:22:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357549AbiBDJVs (ORCPT ); Fri, 4 Feb 2022 04:21: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 8DB76C06176E; Fri, 4 Feb 2022 01:21:48 -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 38D31B836ED; Fri, 4 Feb 2022 09:21:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7547DC004E1; Fri, 4 Feb 2022 09:21:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966507; bh=QxDpZTI1T/K786gFZQxlq1ZSoTSFEF/Vn8/D4xcS44c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=URPHy5IoTX2oI7bxOzQTf3yjKRCC9jG62/PjrOEuVPZMxk0a7H+5Z/0I2bzjbBbiT MUhtlAPnaCVlBDT+hoA7scMDIgBKi74ZuihiP3/uQjpDyvloHooqPFyxXtV5JlBaSi c78r17kPmkWf+pg5UX6mmSGYCApHYohp1+nPafK0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Mathias Krause , Jan Kara Subject: [PATCH 5.10 20/25] fanotify: Fix stale file descriptor in copy_event_to_user() Date: Fri, 4 Feb 2022 10:20:27 +0100 Message-Id: <20220204091914.933296036@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dan Carpenter commit ee12595147ac1fbfb5bcb23837e26dd58d94b15d upstream. This code calls fd_install() which gives the userspace access to the fd. Then if copy_info_records_to_user() fails it calls put_unused_fd(fd) but that will not release it and leads to a stale entry in the file descriptor table. Generally you can't trust the fd after a call to fd_install(). The fix is to delay the fd_install() until everything else has succeeded. Fortunately it requires CAP_SYS_ADMIN to reach this code so the security impact is less. Fixes: f644bc449b37 ("fanotify: fix copy_event_to_user() fid error clean up= ") Link: https://lore.kernel.org/r/20220128195656.GA26981@kili Signed-off-by: Dan Carpenter Reviewed-by: Mathias Krause 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- fs/notify/fanotify/fanotify_user.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -366,9 +366,6 @@ static ssize_t copy_event_to_user(struct if (fanotify_is_perm_event(event->mask)) FANOTIFY_PERM(event)->fd =3D fd; =20 - if (f) - fd_install(fd, f); - /* Event info records order is: dir fid + name, child fid */ if (fanotify_event_dir_fh_len(event)) { info_type =3D info->name_len ? FAN_EVENT_INFO_TYPE_DFID_NAME : @@ -432,6 +429,9 @@ static ssize_t copy_event_to_user(struct count -=3D ret; } =20 + if (f) + fd_install(fd, f); + return metadata.event_len; =20 out_close_fd: From nobody Mon Jun 29 18:37: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 72223C4332F for ; Fri, 4 Feb 2022 09:22:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353231AbiBDJWa (ORCPT ); Fri, 4 Feb 2022 04:22:30 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51236 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357559AbiBDJVx (ORCPT ); Fri, 4 Feb 2022 04:21: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 C638BB836EB; Fri, 4 Feb 2022 09:21:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5D6EC004E1; Fri, 4 Feb 2022 09:21:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966510; bh=+Pv1FuRGxt3k16ZdKof5rg/7o8X8DuDo1eHRGdIY4TY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Urx6dZWLdV/vHOH9kx/B0jkQnkKzg/seV5UHbElAVORuyK0Z5Zqe7/JLqrWk3A0zb 14WpoaM+uFPtLOfpELs5a2YcRkW/Qu7FwfvestXovBN/iOXuP/02SuYfUm+EJ0YZu+ nsZ4MpcGekuXTp8uy/I3rYk+VKIlO3vi+Lik6I6c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Vlad Buslov , Jiri Pirko , Cong Wang , syzbot , Jakub Kicinski Subject: [PATCH 5.10 21/25] net: sched: fix use-after-free in tc_new_tfilter() Date: Fri, 4 Feb 2022 10:20:28 +0100 Message-Id: <20220204091914.963217690@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5 upstream. Whenever tc_new_tfilter() jumps back to replay: label, we need to make sure @q and @chain local variables are cleared again, or risk use-after-free as in [1] For consistency, apply the same fix in tc_ctl_chain() BUG: KASAN: use-after-free in mini_qdisc_pair_swap+0x1b9/0x1f0 net/sched/sc= h_generic.c:1581 Write of size 8 at addr ffff8880985c4b08 by task syz-executor.4/1945 CPU: 0 PID: 1945 Comm: syz-executor.4 Not tainted 5.17.0-rc1-syzkaller-0049= 5-gff58831fa02d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 mini_qdisc_pair_swap+0x1b9/0x1f0 net/sched/sch_generic.c:1581 tcf_chain_head_change_item net/sched/cls_api.c:372 [inline] tcf_chain0_head_change.isra.0+0xb9/0x120 net/sched/cls_api.c:386 tcf_chain_tp_insert net/sched/cls_api.c:1657 [inline] tcf_chain_tp_insert_unique net/sched/cls_api.c:1707 [inline] tc_new_tfilter+0x1e67/0x2350 net/sched/cls_api.c:2086 rtnetlink_rcv_msg+0x80d/0xb80 net/core/rtnetlink.c:5583 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:725 ____sys_sendmsg+0x331/0x810 net/socket.c:2413 ___sys_sendmsg+0xf3/0x170 net/socket.c:2467 __sys_sendmmsg+0x195/0x470 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f2647172059 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 = 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff f= f 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2645aa5168 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f2647285100 RCX: 00007f2647172059 RDX: 040000000000009f RSI: 00000000200002c0 RDI: 0000000000000006 RBP: 00007f26471cc08d R08: 0000000000000000 R09: 0000000000000000 R10: 9e00000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffb3f7f02f R14: 00007f2645aa5300 R15: 0000000000022000 Allocated by task 1944: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:436 [inline] ____kasan_kmalloc mm/kasan/common.c:515 [inline] ____kasan_kmalloc mm/kasan/common.c:474 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:524 kmalloc_node include/linux/slab.h:604 [inline] kzalloc_node include/linux/slab.h:726 [inline] qdisc_alloc+0xac/0xa10 net/sched/sch_generic.c:941 qdisc_create.constprop.0+0xce/0x10f0 net/sched/sch_api.c:1211 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5592 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:725 ____sys_sendmsg+0x331/0x810 net/socket.c:2413 ___sys_sendmsg+0xf3/0x170 net/socket.c:2467 __sys_sendmmsg+0x195/0x470 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 3609: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free+0x130/0x160 mm/kasan/common.c:328 kasan_slab_free include/linux/kasan.h:236 [inline] slab_free_hook mm/slub.c:1728 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1754 slab_free mm/slub.c:3509 [inline] kfree+0xcb/0x280 mm/slub.c:4562 rcu_do_batch kernel/rcu/tree.c:2527 [inline] rcu_core+0x7b8/0x1540 kernel/rcu/tree.c:2778 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 Last potentially related work creation: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 __kasan_record_aux_stack+0xbe/0xd0 mm/kasan/generic.c:348 __call_rcu kernel/rcu/tree.c:3026 [inline] call_rcu+0xb1/0x740 kernel/rcu/tree.c:3106 qdisc_put_unlocked+0x6f/0x90 net/sched/sch_generic.c:1109 tcf_block_release+0x86/0x90 net/sched/cls_api.c:1238 tc_new_tfilter+0xc0d/0x2350 net/sched/cls_api.c:2148 rtnetlink_rcv_msg+0x80d/0xb80 net/core/rtnetlink.c:5583 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:725 ____sys_sendmsg+0x331/0x810 net/socket.c:2413 ___sys_sendmsg+0xf3/0x170 net/socket.c:2467 __sys_sendmmsg+0x195/0x470 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff8880985c4800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 776 bytes inside of 1024-byte region [ffff8880985c4800, ffff8880985c4c00) The buggy address belongs to the page: page:ffffea0002617000 refcount:1 mapcount:0 mapping:0000000000000000 index:= 0x0 pfn:0x985c0 head:ffffea0002617000 order:3 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=3D0|zone=3D1|lastcpupid=3D0x7ff) raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888010c41dc0 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1d20c0(_= _GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__G= FP_HARDWALL), pid 1941, ts 1038999441284, free_ts 1033444432829 prep_new_page mm/page_alloc.c:2434 [inline] get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389 alloc_pages+0x1aa/0x310 mm/mempolicy.c:2271 alloc_slab_page mm/slub.c:1799 [inline] allocate_slab mm/slub.c:1944 [inline] new_slab+0x28a/0x3b0 mm/slub.c:2004 ___slab_alloc+0x87c/0xe90 mm/slub.c:3018 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3105 slab_alloc_node mm/slub.c:3196 [inline] slab_alloc mm/slub.c:3238 [inline] __kmalloc+0x2fb/0x340 mm/slub.c:4420 kmalloc include/linux/slab.h:586 [inline] kzalloc include/linux/slab.h:715 [inline] __register_sysctl_table+0x112/0x1090 fs/proc/proc_sysctl.c:1335 neigh_sysctl_register+0x2c8/0x5e0 net/core/neighbour.c:3787 devinet_sysctl_register+0xb1/0x230 net/ipv4/devinet.c:2618 inetdev_init+0x286/0x580 net/ipv4/devinet.c:278 inetdev_event+0xa8a/0x15d0 net/ipv4/devinet.c:1532 notifier_call_chain+0xb5/0x200 kernel/notifier.c:84 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1919 call_netdevice_notifiers_extack net/core/dev.c:1931 [inline] call_netdevice_notifiers net/core/dev.c:1945 [inline] register_netdevice+0x1073/0x1500 net/core/dev.c:9698 veth_newlink+0x59c/0xa90 drivers/net/veth.c:1722 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1352 [inline] free_pcp_prepare+0x374/0x870 mm/page_alloc.c:1404 free_unref_page_prepare mm/page_alloc.c:3325 [inline] free_unref_page+0x19/0x690 mm/page_alloc.c:3404 release_pages+0x748/0x1220 mm/swap.c:956 tlb_batch_pages_flush mm/mmu_gather.c:50 [inline] tlb_flush_mmu_free mm/mmu_gather.c:243 [inline] tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:250 zap_pte_range mm/memory.c:1441 [inline] zap_pmd_range mm/memory.c:1490 [inline] zap_pud_range mm/memory.c:1519 [inline] zap_p4d_range mm/memory.c:1540 [inline] unmap_page_range+0x1d1d/0x2a30 mm/memory.c:1561 unmap_single_vma+0x198/0x310 mm/memory.c:1606 unmap_vmas+0x16b/0x2f0 mm/memory.c:1638 exit_mmap+0x201/0x670 mm/mmap.c:3178 __mmput+0x122/0x4b0 kernel/fork.c:1114 mmput+0x56/0x60 kernel/fork.c:1135 exit_mm kernel/exit.c:507 [inline] do_exit+0xa3c/0x2a30 kernel/exit.c:793 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 __do_sys_exit_group kernel/exit.c:946 [inline] __se_sys_exit_group kernel/exit.c:944 [inline] __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:944 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Memory state around the buggy address: ffff8880985c4a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880985c4a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880985c4b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880985c4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880985c4c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 470502de5bdb ("net: sched: unlock rules update API") Signed-off-by: Eric Dumazet Cc: Vlad Buslov Cc: Jiri Pirko Cc: Cong Wang Reported-by: syzbot Link: https://lore.kernel.org/r/20220131172018.3704490-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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- net/sched/cls_api.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/net/sched/cls_api.c +++ b/net/sched/cls_api.c @@ -1954,9 +1954,9 @@ static int tc_new_tfilter(struct sk_buff bool prio_allocate; u32 parent; u32 chain_index; - struct Qdisc *q =3D NULL; + struct Qdisc *q; struct tcf_chain_info chain_info; - struct tcf_chain *chain =3D NULL; + struct tcf_chain *chain; struct tcf_block *block; struct tcf_proto *tp; unsigned long cl; @@ -1984,6 +1984,8 @@ replay: tp =3D NULL; cl =3D 0; block =3D NULL; + q =3D NULL; + chain =3D NULL; =20 if (prio =3D=3D 0) { /* If no priority is provided by the user, @@ -2804,8 +2806,8 @@ static int tc_ctl_chain(struct sk_buff * struct tcmsg *t; u32 parent; u32 chain_index; - struct Qdisc *q =3D NULL; - struct tcf_chain *chain =3D NULL; + struct Qdisc *q; + struct tcf_chain *chain; struct tcf_block *block; unsigned long cl; int err; @@ -2815,6 +2817,7 @@ static int tc_ctl_chain(struct sk_buff * return -EPERM; =20 replay: + q =3D NULL; err =3D nlmsg_parse_deprecated(n, sizeof(*t), tca, TCA_MAX, rtm_tca_policy, extack); if (err < 0) From nobody Mon Jun 29 18:37: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 E2577C433F5 for ; Fri, 4 Feb 2022 09:22:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357714AbiBDJWk (ORCPT ); Fri, 4 Feb 2022 04:22:40 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:41442 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357363AbiBDJVy (ORCPT ); Fri, 4 Feb 2022 04:21: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 91A1A615C6; Fri, 4 Feb 2022 09:21:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47521C004E1; Fri, 4 Feb 2022 09:21:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966514; bh=9F8kMDKRv1Lq670/0FmIy6Ok2qsiVmZa1gKHzQJ6pSA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kCG3FHi62peTJXCb+LJCttx+B64kcelHgiTOPZOTVe+dAhSwDX0CR0fQYoiPmORT1 /p7wikWfr81aVSb4IvosPWNgtoomAmYAUmm0CA7cQuPWdNrl9DpXJgHnWtse+e3IVY B95d7gmy+m4xhCtQDIZOEV9tNBmhAPdwGxLZ5x2g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Jiri Pirko , Jakub Kicinski Subject: [PATCH 5.10 22/25] rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() Date: Fri, 4 Feb 2022 10:20:29 +0100 Message-Id: <20220204091914.991840217@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 c6f6f2444bdbe0079e41914a35081530d0409963 upstream. While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it. Fixes: ba7d49b1f0f8 ("rtnetlink: provide api for getting and setting slave = info") Signed-off-by: Eric Dumazet Cc: Jiri Pirko Link: https://lore.kernel.org/r/20220201012106.216495-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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- net/core/rtnetlink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -3238,8 +3238,8 @@ static int __rtnl_newlink(struct sk_buff struct nlattr *slave_attr[RTNL_SLAVE_MAX_TYPE + 1]; unsigned char name_assign_type =3D NET_NAME_USER; struct nlattr *linkinfo[IFLA_INFO_MAX + 1]; - const struct rtnl_link_ops *m_ops =3D NULL; - struct net_device *master_dev =3D NULL; + const struct rtnl_link_ops *m_ops; + struct net_device *master_dev; struct net *net =3D sock_net(skb->sk); const struct rtnl_link_ops *ops; struct nlattr *tb[IFLA_MAX + 1]; @@ -3277,6 +3277,8 @@ replay: else dev =3D NULL; =20 + master_dev =3D NULL; + m_ops =3D NULL; if (dev) { master_dev =3D netdev_master_upper_dev_get(dev); if (master_dev) From nobody Mon Jun 29 18:37: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 BF5C3C433F5 for ; Fri, 4 Feb 2022 09:22:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357470AbiBDJWe (ORCPT ); Fri, 4 Feb 2022 04:22:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357357AbiBDJWA (ORCPT ); Fri, 4 Feb 2022 04:22:00 -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 F1C00C06173E; Fri, 4 Feb 2022 01:21:59 -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 AD286B836E9; Fri, 4 Feb 2022 09:21:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3473C004E1; Fri, 4 Feb 2022 09:21:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966517; bh=duE5cVD0v/NhLLLIKg+vu31OPK5Dw4QswnAwnZG/I6Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cobli1cUtX0NT13fDyrCbn1BR6ODOEuhqOOOB2+N4eOKpp+ALTfmWH7RtjCzIkiiE 9QISR/kQwRTujwlLCQzuSH3Cf799KdlRGZNcW5vyqDA+ltstELXPXpaUgiWsDvd6j0 wv5lAe2EPx1s1Sosi2qb26l4fJbap4UznttvffFg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tianchen Ding , Waiman Long , Tejun Heo Subject: [PATCH 5.10 23/25] cpuset: Fix the bug that subpart_cpus updated wrongly in update_cpumask() Date: Fri, 4 Feb 2022 10:20:30 +0100 Message-Id: <20220204091915.021807911@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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: Tianchen Ding commit c80d401c52a2d1baf2a5afeb06f0ffe678e56d23 upstream. subparts_cpus should be limited as a subset of cpus_allowed, but it is updated wrongly by using cpumask_andnot(). Use cpumask_and() instead to fix it. Fixes: ee8dde0cd2ce ("cpuset: Add new v2 cpuset.sched.partition flag") Signed-off-by: Tianchen Ding Reviewed-by: Waiman Long Signed-off-by: Tejun Heo 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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- kernel/cgroup/cpuset.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1566,8 +1566,7 @@ static int update_cpumask(struct cpuset * Make sure that subparts_cpus is a subset of cpus_allowed. */ if (cs->nr_subparts_cpus) { - cpumask_andnot(cs->subparts_cpus, cs->subparts_cpus, - cs->cpus_allowed); + cpumask_and(cs->subparts_cpus, cs->subparts_cpus, cs->cpus_allowed); cs->nr_subparts_cpus =3D cpumask_weight(cs->subparts_cpus); } spin_unlock_irq(&callback_lock); From nobody Mon Jun 29 18:37: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 80140C433F5 for ; Fri, 4 Feb 2022 09:22:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357692AbiBDJWh (ORCPT ); Fri, 4 Feb 2022 04:22:37 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:41570 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357454AbiBDJWB (ORCPT ); Fri, 4 Feb 2022 04:22: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 dfw.source.kernel.org (Postfix) with ESMTPS id 2AC94615A5; Fri, 4 Feb 2022 09:22:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 044DDC004E1; Fri, 4 Feb 2022 09:21:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966520; bh=WtUnsIowSOuclbckqnxSLZcqZaZoUTFVywie3dgBHjo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=smN5LBfPGk+qSnd2YqIN7DA8/bTaAsiczTZgTccEQqat+qBP4Ms/BCp31Lu74lxRh 15L4Yi85QtiDIrIup2YeaUFJ0PFSw6VX/1S9Jn99AKYX6G7Ns1UlpLVpmB3U/JjeQf rKcmOyP64HQKZuRZAgn+dhz9LIhfjvcxeDBQK7Og= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Willem de Bruijn , syzbot , Jakub Kicinski Subject: [PATCH 5.10 24/25] af_packet: fix data-race in packet_setsockopt / packet_setsockopt Date: Fri, 4 Feb 2022 10:20:31 +0100 Message-Id: <20220204091915.056231349@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 e42e70ad6ae2ae511a6143d2e8da929366e58bd9 upstream. When packet_setsockopt( PACKET_FANOUT_DATA ) reads po->fanout, no lock is held, meaning that another thread can change po->fanout. Given that po->fanout can only be set once during the socket lifetime (it is only cleared from fanout_release()), we can use READ_ONCE()/WRITE_ONCE() to document the race. BUG: KCSAN: data-race in packet_setsockopt / packet_setsockopt write to 0xffff88813ae8e300 of 8 bytes by task 14653 on cpu 0: fanout_add net/packet/af_packet.c:1791 [inline] packet_setsockopt+0x22fe/0x24a0 net/packet/af_packet.c:3931 __sys_setsockopt+0x209/0x2a0 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188 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 0xffff88813ae8e300 of 8 bytes by task 14654 on cpu 1: packet_setsockopt+0x691/0x24a0 net/packet/af_packet.c:3935 __sys_setsockopt+0x209/0x2a0 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188 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: 0x0000000000000000 -> 0xffff888106f8c000 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 14654 Comm: syz-executor.3 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 Fixes: 47dceb8ecdc1 ("packet: add classic BPF fanout mode") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Reported-by: syzbot Link: https://lore.kernel.org/r/20220201022358.330621-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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- net/packet/af_packet.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -1750,7 +1750,10 @@ static int fanout_add(struct sock *sk, s err =3D -ENOSPC; if (refcount_read(&match->sk_ref) < match->max_num_members) { __dev_remove_pack(&po->prot_hook); - po->fanout =3D match; + + /* Paired with packet_setsockopt(PACKET_FANOUT_DATA) */ + WRITE_ONCE(po->fanout, match); + po->rollover =3D rollover; rollover =3D NULL; refcount_set(&match->sk_ref, refcount_read(&match->sk_ref) + 1); @@ -3906,7 +3909,8 @@ packet_setsockopt(struct socket *sock, i } case PACKET_FANOUT_DATA: { - if (!po->fanout) + /* Paired with the WRITE_ONCE() in fanout_add() */ + if (!READ_ONCE(po->fanout)) return -EINVAL; =20 return fanout_set_data(po, optval, optlen); From nobody Mon Jun 29 18:37: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 7019BC433F5 for ; Fri, 4 Feb 2022 09:22:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357607AbiBDJWn (ORCPT ); Fri, 4 Feb 2022 04:22:43 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:51402 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357592AbiBDJWG (ORCPT ); Fri, 4 Feb 2022 04:22: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 1ADF5B836F1; Fri, 4 Feb 2022 09:22:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F869C004E1; Fri, 4 Feb 2022 09:22:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643966524; bh=KwSx78kgBSkfwQnzakgw/kHlw0YgW+uZsnXilQghTBY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=irTwuUejgrHR3KysG1pWcUaSUYzpkaWuR6tNwMtpXKavNy9Yz0GkBc/wRyzmLkvk8 2v1pnVWjGOdd8ZJh7+rRz849SiegozvfxwizANpFBe/AC5Z++jITe2tHhcrkhBx3bj 371JvSR6+0TmkxVXEl8nYUfGrhS3WELxGl8eWyu4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Mat Martineau , Talal Ahmad , Arjun Roy , Willem de Bruijn , Soheil Hassas Yeganeh , Paolo Abeni , Jakub Kicinski Subject: [PATCH 5.10 25/25] tcp: add missing tcp_skb_can_collapse() test in tcp_shift_skb_data() Date: Fri, 4 Feb 2022 10:20:32 +0100 Message-Id: <20220204091915.087224273@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220204091914.280602669@linuxfoundation.org> References: <20220204091914.280602669@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 b67985be400969578d4d4b17299714c0e5d2c07b upstream. tcp_shift_skb_data() might collapse three packets into a larger one. P_A, P_B, P_C -> P_ABC Historically, it used a single tcp_skb_can_collapse_to(P_A) call, because it was enough. In commit 85712484110d ("tcp: coalesce/collapse must respect MPTCP extensio= ns"), this call was replaced by a call to tcp_skb_can_collapse(P_A, P_B) But the now needed test over P_C has been missed. This probably broke MPTCP. Then later, commit 9b65b17db723 ("net: avoid double accounting for pure zer= ocopy skbs") added an extra condition to tcp_skb_can_collapse(), but the missing call from tcp_shift_skb_data() is also breaking TCP zerocopy, because P_A and P_C might have different skb_zcopy_pure() status. Fixes: 85712484110d ("tcp: coalesce/collapse must respect MPTCP extensions") Fixes: 9b65b17db723 ("net: avoid double accounting for pure zerocopy skbs") Signed-off-by: Eric Dumazet Cc: Mat Martineau Cc: Talal Ahmad Cc: Arjun Roy Cc: Willem de Bruijn Acked-by: Soheil Hassas Yeganeh Acked-by: Paolo Abeni Link: https://lore.kernel.org/r/20220201184640.756716-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: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Slade Watkins --- net/ipv4/tcp_input.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -1620,6 +1620,8 @@ static struct sk_buff *tcp_shift_skb_dat (mss !=3D tcp_skb_seglen(skb))) goto out; =20 + if (!tcp_skb_can_collapse(prev, skb)) + goto out; len =3D skb->len; pcount =3D tcp_skb_pcount(skb); if (tcp_skb_shift(prev, skb, pcount, len))