From patchwork Tue Feb 18 19:54:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231084 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2EFDC34049 for ; Tue, 18 Feb 2020 20:08:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A09AF24125 for ; Tue, 18 Feb 2020 20:08:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056530; bh=5BanddPanjla8ZTGWbfTE9JVb11UW/XRK0aZm0tPR+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=IX51n0WTeG/J2heyUSOSmXjmtUDQ+ZT3N5ufLaF74e5Xb//0W/NX+RzS8xqoe0/4B b5ixDqOxVpS2V8EO/zjbU2V1R6FK1smAUNwtUHBrVRPg2MgpevcIUjkSgfS8OzpFgT 4ZBOK2nWAyS34AUQ0KsArtrCKTX34uq5DnupHKKA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726620AbgBRUIm (ORCPT ); Tue, 18 Feb 2020 15:08:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:35044 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727987AbgBRT5j (ORCPT ); Tue, 18 Feb 2020 14:57:39 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 726EA24670; Tue, 18 Feb 2020 19:57:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055858; bh=5BanddPanjla8ZTGWbfTE9JVb11UW/XRK0aZm0tPR+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0joDewAIV3Qy/VVyN1o3iAKPjNjt3XXr/YGXcPkx5Q7CpkA3OIfSdXAkQgu+M5tcy MIiwMO7DLy1G8/Firtf9wYE7Qv/ovTaQCab92jZAHfZoAfa1eK7f9+ebEYM8CqTt3W 7km0dsRL45tuvuZ0tg+qAmUxpwH6rMNWNneJolGc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Gaurav Agrawal , Dmitry Torokhov Subject: [PATCH 5.4 02/66] Input: synaptics - enable SMBus on ThinkPad L470 Date: Tue, 18 Feb 2020 20:54:29 +0100 Message-Id: <20200218190428.289430191@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Gaurav Agrawal commit b8a3d819f872e0a3a0a6db0dbbcd48071042fb98 upstream. Add touchpad LEN2044 to the list, as it is capable of working with psmouse.synaptics_intertouch=1 Signed-off-by: Gaurav Agrawal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/CADdtggVzVJq5gGNmFhKSz2MBwjTpdN5YVOdr4D3Hkkv=KZRc9g@mail.gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman --- drivers/input/mouse/synaptics.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -180,6 +180,7 @@ static const char * const smbus_pnp_ids[ "LEN0097", /* X280 -> ALPS trackpoint */ "LEN009b", /* T580 */ "LEN200f", /* T450s */ + "LEN2044", /* L470 */ "LEN2054", /* E480 */ "LEN2055", /* E580 */ "SYN3052", /* HP EliteBook 840 G4 */ From patchwork Tue Feb 18 19:54:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231156 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F5BFC34026 for ; Tue, 18 Feb 2020 19:57:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 79C0824673 for ; Tue, 18 Feb 2020 19:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055863; bh=alfaClgMPQx9gqsYJzeSw3F99GdWFoISOuD0fIcZiQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=bOtDvwo4EhlGGyXlzFGrUilwkAWCD9U4Nmcq1koFLG//ImXgnnSd0vprU0flIB1AS 4AZjIJ5VyGjhUxYjeMAUfMclxsQz85FNbXROMiLcqM3cpEPUn05A96q/EDIfL4jyTG Nhv1kuu3IB9LAhnRvwWHztNMvoyZX3NO0uXXQ4MY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726808AbgBRT5m (ORCPT ); Tue, 18 Feb 2020 14:57:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:35092 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726911AbgBRT5l (ORCPT ); Tue, 18 Feb 2020 14:57:41 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DD24024655; Tue, 18 Feb 2020 19:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055861; bh=alfaClgMPQx9gqsYJzeSw3F99GdWFoISOuD0fIcZiQU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wh0Kj+PI/NPO72b7UZemIrKnd4jCOqa13GE2qXg2/BPHyuQXrUL6+AFRezp/vBC9Z sSKdcaG8zS13HHEHEyF60EE0sLgplBBSFZxh8LxUXLUspNvHii0xDEBMj/cnpgq/xS THB+aLjBKa+mdPnrQVPe/4y1kssU4+cc2wQ2/B8I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Benjamin Tissoires , Dmitry Torokhov Subject: [PATCH 5.4 03/66] Input: synaptics - remove the LEN0049 dmi id from topbuttonpad list Date: Tue, 18 Feb 2020 20:54:30 +0100 Message-Id: <20200218190428.388256110@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Benjamin Tissoires commit 5179a9dfa9440c1781816e2c9a183d1d2512dc61 upstream. The Yoga 11e is using LEN0049, but it doesn't have a trackstick. Thus, there is no need to create a software top buttons row. However, it seems that the device works under SMBus, so keep it as part of the smbus_pnp_ids. Signed-off-by: Benjamin Tissoires Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200115013023.9710-1-benjamin.tissoires@redhat.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman --- drivers/input/mouse/synaptics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -146,7 +146,6 @@ static const char * const topbuttonpad_p "LEN0042", /* Yoga */ "LEN0045", "LEN0047", - "LEN0049", "LEN2000", /* S540 */ "LEN2001", /* Edge E431 */ "LEN2002", /* Edge E531 */ @@ -166,6 +165,7 @@ static const char * const smbus_pnp_ids[ /* all of the topbuttonpad_pnp_ids are valid, we just add some extras */ "LEN0048", /* X1 Carbon 3 */ "LEN0046", /* X250 */ + "LEN0049", /* Yoga 11e */ "LEN004a", /* W541 */ "LEN005b", /* P50 */ "LEN005e", /* T560 */ From patchwork Tue Feb 18 19:54:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231085 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E9CCC34047 for ; Tue, 18 Feb 2020 20:08:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E32624125 for ; Tue, 18 Feb 2020 20:08:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056515; bh=iaLubHGPgPk7jIXL2erHvzW0+SkVMmcTvq40jqMmVM8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=q4XgewyK2zusHupZoz9bvWps1GehdEjlabTazO0KeFLVOACBzVnnp+CV2xTWuIFV7 WH5dpkus4ONJ+HMdixztTQwr3UiEuF/JHszFRKF0sZxG3aCloVAjL6VsNLGbPjb72Y MV5DWuAqW7gi5gatInY5JZ43dNAaU/V7J9s3PdRM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728042AbgBRT5u (ORCPT ); Tue, 18 Feb 2020 14:57:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:35260 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727135AbgBRT5t (ORCPT ); Tue, 18 Feb 2020 14:57:49 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A6CFD20659; Tue, 18 Feb 2020 19:57:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055869; bh=iaLubHGPgPk7jIXL2erHvzW0+SkVMmcTvq40jqMmVM8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RhHxImfknJQQiYWnO00o4WDz2hXMXboXfaCA1NW2pgTMOHtNn/WkA1bJLX4iN860B +vlkdfX7T8iK/JhNe3m8y9Le0PoS5MLk3jfVIqUGeez8V/+sdqOzlVnCGIAc66L7w1 +FSXCA6tAoeayOgToD/Xf38AL250zsiq05TXw8sE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Takashi Iwai Subject: [PATCH 5.4 06/66] ALSA: hda/realtek - Fix silent output on MSI-GL73 Date: Tue, 18 Feb 2020 20:54:33 +0100 Message-Id: <20200218190428.702286805@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Takashi Iwai commit 7dafba3762d6c0083ded00a48f8c1a158bc86717 upstream. MSI-GL73 laptop with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204159 Cc: Link: https://lore.kernel.org/r/20200212081047.27727-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -2447,6 +2447,7 @@ static const struct snd_pci_quirk alc882 SND_PCI_QUIRK(0x1071, 0x8258, "Evesham Voyaeger", ALC882_FIXUP_EAPD), SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte EP45-DS3/Z87X-UD3H", ALC889_FIXUP_FRONT_HP_NO_PRESENCE), SND_PCI_QUIRK(0x1458, 0xa0b8, "Gigabyte AZ370-Gaming", ALC1220_FIXUP_GB_DUAL_CODECS), + SND_PCI_QUIRK(0x1462, 0x1276, "MSI-GL73", ALC1220_FIXUP_CLEVO_P950), SND_PCI_QUIRK(0x1462, 0x7350, "MSI-7350", ALC889_FIXUP_CD), SND_PCI_QUIRK(0x1462, 0xda57, "MSI Z270-Gaming", ALC1220_FIXUP_GB_DUAL_CODECS), SND_PCI_QUIRK_VENDOR(0x1462, "MSI", ALC882_FIXUP_GPIO3), From patchwork Tue Feb 18 19:54:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231155 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73FD0C34049 for ; Tue, 18 Feb 2020 19:57:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3B1FC2468B for ; Tue, 18 Feb 2020 19:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055874; bh=889FUsw8ToFo6ZuKe4T1rsGGm3hUcVkaCHLutHExmao=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=bhPy3Rknpr/YumISaigWrjmTsn+icHCqdR5grlM4r2hMyNTHmCzu/0H79WWF/WpSz GtHGelWFOuWg3eYMCYOOuNFYhGD29kK0s23dsbHanODE9k7IbCD7f3h4hHj/nwBxqo AruMcl4IUSTU7Y0trmiu4aM5r1le0KV3JNqmIsSw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728055AbgBRT5x (ORCPT ); Tue, 18 Feb 2020 14:57:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:35314 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728051AbgBRT5w (ORCPT ); Tue, 18 Feb 2020 14:57:52 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2FFF220659; Tue, 18 Feb 2020 19:57:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055871; bh=889FUsw8ToFo6ZuKe4T1rsGGm3hUcVkaCHLutHExmao=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UpccIs2f0uS4UrTYRhY5+3hYhTvou+H6w5zXCTJhOQ1BKPRpN5dP7ePu/ozgBvbJi uLZyEIpTmHumsg8m5wFR/Dxs+08Xv9vk3ygNhWRd0e9/AV0GpBkzsbN76rJvlxvUze OnS0Y+7qhqYS+dMJ59eCnX2FlNeYoI3jOXagGiPA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arvind Sankar , Takashi Iwai Subject: [PATCH 5.4 07/66] ALSA: usb-audio: Apply sample rate quirk for Audioengine D1 Date: Tue, 18 Feb 2020 20:54:34 +0100 Message-Id: <20200218190428.788565639@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Arvind Sankar commit 93f9d1a4ac5930654c17412e3911b46ece73755a upstream. The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate, but it returns the rate in byte-reversed order. When setting sampling rate, the driver produces these warning messages: [168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100 [168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000 [168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000 As can be seen from the hexadecimal conversion, the current rate read back is byte-reversed from the rate that was set. 44100 == 0x00ac44, 4500480 == 0x44ac00 48000 == 0x00bb80, 8436480 == 0x80bb00 96000 == 0x017700, 30465 == 0x007701 Rather than implementing a new quirk to reverse the order, just skip checking the rate to avoid spamming the log. Signed-off-by: Arvind Sankar Cc: Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.edu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+) --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1402,6 +1402,7 @@ bool snd_usb_get_sample_rate_quirk(struc case USB_ID(0x1395, 0x740a): /* Sennheiser DECT */ case USB_ID(0x1901, 0x0191): /* GE B850V3 CP2114 audio interface */ case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */ + case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */ return true; } From patchwork Tue Feb 18 19:54:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231086 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28BBBC34047 for ; Tue, 18 Feb 2020 20:08:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 001F02067D for ; Tue, 18 Feb 2020 20:08:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056513; bh=EmGc26XpQQJRxz7sKbnLLn5rH2g2hZ9Ry83rw/3dFPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=NANiNtBJeT5Jo4CJd7tN8f156YFUIf4JTv7GdYpoepYbhvEg9LrU/lNH1+KPi+uJI W5BHdBW6ziwEFCH/77JvevzYmXr/DJjXQIJSFydBzDF6DTBI1N4UnXQCXEddkR3QTe NK6e0jSRmrnAHfNi5zzhmXBqDD/XK8WCOauSZN3E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726817AbgBRUI2 (ORCPT ); Tue, 18 Feb 2020 15:08:28 -0500 Received: from mail.kernel.org ([198.145.29.99]:35402 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727232AbgBRT55 (ORCPT ); Tue, 18 Feb 2020 14:57:57 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8F9F620659; Tue, 18 Feb 2020 19:57:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055877; bh=EmGc26XpQQJRxz7sKbnLLn5rH2g2hZ9Ry83rw/3dFPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hlKd5mHPugw/zUM+17umTO3ti0f2tBr3lQNfVDrouSFlyRUTO4hUgR83F4VslJ2Gn TfdKnEzrCTspaRdcOXkPYZmWUVce6ADaEDOUKeAsvDCD3yRwN0zebUCWjxvtrMbYw/ oTwDqpoC4oeQ71eUro6F6Iobi68r15K5OsEzMfI0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Rafael J. Wysocki" Subject: [PATCH 5.4 09/66] ACPI: PM: s2idle: Avoid possible race related to the EC GPE Date: Tue, 18 Feb 2020 20:54:36 +0100 Message-Id: <20200218190428.963951947@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Rafael J. Wysocki commit e3728b50cd9be7d4b1469447cdf1feb93e3b7adb upstream. It is theoretically possible for the ACPI EC GPE to be set after the s2idle_ops->wake() called from s2idle_loop() has returned and before the subsequent pm_wakeup_pending() check is carried out. If that happens, the resulting wakeup event will cause the system to resume even though it may be a spurious one. To avoid that race, first make the ->wake() callback in struct platform_s2idle_ops return a bool value indicating whether or not to let the system resume and rearrange s2idle_loop() to use that value instad of the direct pm_wakeup_pending() call if ->wake() is present. Next, rework acpi_s2idle_wake() to process EC events and check pm_wakeup_pending() before re-arming the SCI for system wakeup to prevent it from triggering prematurely and add comments to that function to explain the rationale for the new code flow. Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman --- drivers/acpi/sleep.c | 46 ++++++++++++++++++++++++++++++++-------------- include/linux/suspend.h | 2 +- kernel/power/suspend.c | 9 +++++---- 3 files changed, 38 insertions(+), 19 deletions(-) --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -977,21 +977,28 @@ static int acpi_s2idle_prepare_late(void return 0; } -static void acpi_s2idle_wake(void) +static bool acpi_s2idle_wake(void) { - /* - * If IRQD_WAKEUP_ARMED is set for the SCI at this point, the SCI has - * not triggered while suspended, so bail out. - */ - if (!acpi_sci_irq_valid() || - irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_irq))) - return; - - /* - * If there are EC events to process, the wakeup may be a spurious one - * coming from the EC. - */ - if (acpi_ec_dispatch_gpe()) { + if (!acpi_sci_irq_valid()) + return pm_wakeup_pending(); + + while (pm_wakeup_pending()) { + /* + * If IRQD_WAKEUP_ARMED is set for the SCI at this point, the + * SCI has not triggered while suspended, so bail out (the + * wakeup is pending anyway and the SCI is not the source of + * it). + */ + if (irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_irq))) + return true; + + /* + * If there are no EC events to process, the wakeup is regarded + * as a genuine one. + */ + if (!acpi_ec_dispatch_gpe()) + return true; + /* * Cancel the wakeup and process all pending events in case * there are any wakeup ones in there. @@ -1009,8 +1016,19 @@ static void acpi_s2idle_wake(void) acpi_ec_flush_work(); acpi_os_wait_events_complete(); /* synchronize Notify handling */ + /* + * The SCI is in the "suspended" state now and it cannot produce + * new wakeup events till the rearming below, so if any of them + * are pending here, they must be resulting from the processing + * of EC events above or coming from somewhere else. + */ + if (pm_wakeup_pending()) + return true; + rearm_wake_irq(acpi_sci_irq); } + + return false; } static void acpi_s2idle_restore_early(void) --- a/include/linux/suspend.h +++ b/include/linux/suspend.h @@ -191,7 +191,7 @@ struct platform_s2idle_ops { int (*begin)(void); int (*prepare)(void); int (*prepare_late)(void); - void (*wake)(void); + bool (*wake)(void); void (*restore_early)(void); void (*restore)(void); void (*end)(void); --- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -131,11 +131,12 @@ static void s2idle_loop(void) * to avoid them upfront. */ for (;;) { - if (s2idle_ops && s2idle_ops->wake) - s2idle_ops->wake(); - - if (pm_wakeup_pending()) + if (s2idle_ops && s2idle_ops->wake) { + if (s2idle_ops->wake()) + break; + } else if (pm_wakeup_pending()) { break; + } pm_wakeup_clear(false); From patchwork Tue Feb 18 19:54:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231099 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8460DC34026 for ; Tue, 18 Feb 2020 20:07:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 57E6822B48 for ; Tue, 18 Feb 2020 20:07:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056421; bh=EwYfUOnmtfFffy16it4zCFunWeADkB2Shz4MSOMEUtc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=m8DfyknhE0LuJLe3KSB8YxjIx3tGiSpewDM1qhazg0itwe1I1rgMuVOT5u0n4zeit kCFsviUCcReuumku6vwD+EDOVV2hktU6AU1FT9vYVAT2svlWEgzzRPnV5ASWjp7Ei0 4cnVN/GnDoR+l7xGarXuy0WU+eMwEbIK8aMzKsgs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726652AbgBRT7b (ORCPT ); Tue, 18 Feb 2020 14:59:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:38236 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728436AbgBRT7b (ORCPT ); Tue, 18 Feb 2020 14:59:31 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AFC8A2464E; Tue, 18 Feb 2020 19:59:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055971; bh=EwYfUOnmtfFffy16it4zCFunWeADkB2Shz4MSOMEUtc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h+IAVcipXO4JaUnSaSMJyxEZUxq52poX48mKF39s7HStkUaBirQk9lnKUhGwXyJne CeydVvy+lDBxfqh9p9Mt5ZFnNFb9+u4zqfSv4xAmUdusUUX6tiwYTOsUAqzBYS/q4g 4LK3IIPzWSkH1fr9BLQ0VoOaHreVWNUGLHiFr83w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andreas Dilger , Theodore Tso , stable@kernel.org Subject: [PATCH 5.4 14/66] ext4: dont assume that mmp_nodename/bdevname have NUL Date: Tue, 18 Feb 2020 20:54:41 +0100 Message-Id: <20200218190429.416968691@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Andreas Dilger commit 14c9ca0583eee8df285d68a0e6ec71053efd2228 upstream. Don't assume that the mmp_nodename and mmp_bdevname strings are NUL terminated, since they are filled in by snprintf(), which is not guaranteed to do so. Link: https://lore.kernel.org/r/1580076215-1048-1-git-send-email-adilger@dilger.ca Signed-off-by: Andreas Dilger Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/mmp.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/fs/ext4/mmp.c +++ b/fs/ext4/mmp.c @@ -120,10 +120,10 @@ void __dump_mmp_msg(struct super_block * { __ext4_warning(sb, function, line, "%s", msg); __ext4_warning(sb, function, line, - "MMP failure info: last update time: %llu, last update " - "node: %s, last update device: %s", - (long long unsigned int) le64_to_cpu(mmp->mmp_time), - mmp->mmp_nodename, mmp->mmp_bdevname); + "MMP failure info: last update time: %llu, last update node: %.*s, last update device: %.*s", + (unsigned long long)le64_to_cpu(mmp->mmp_time), + (int)sizeof(mmp->mmp_nodename), mmp->mmp_nodename, + (int)sizeof(mmp->mmp_bdevname), mmp->mmp_bdevname); } /* @@ -154,6 +154,7 @@ static int kmmpd(void *data) mmp_check_interval = max(EXT4_MMP_CHECK_MULT * mmp_update_interval, EXT4_MMP_MIN_CHECK_INTERVAL); mmp->mmp_check_interval = cpu_to_le16(mmp_check_interval); + BUILD_BUG_ON(sizeof(mmp->mmp_bdevname) < BDEVNAME_SIZE); bdevname(bh->b_bdev, mmp->mmp_bdevname); memcpy(mmp->mmp_nodename, init_utsname()->nodename, @@ -375,7 +376,8 @@ skip: /* * Start a kernel thread to update the MMP block periodically. */ - EXT4_SB(sb)->s_mmp_tsk = kthread_run(kmmpd, mmpd_data, "kmmpd-%s", + EXT4_SB(sb)->s_mmp_tsk = kthread_run(kmmpd, mmpd_data, "kmmpd-%.*s", + (int)sizeof(mmp->mmp_bdevname), bdevname(bh->b_bdev, mmp->mmp_bdevname)); if (IS_ERR(EXT4_SB(sb)->s_mmp_tsk)) { From patchwork Tue Feb 18 19:54:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231150 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFD4FC3404B for ; Tue, 18 Feb 2020 19:59:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C93592465A for ; Tue, 18 Feb 2020 19:59:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055976; bh=TQmI2Xi+jSe1xvgDZog4lmUKoHRkgibmTGpmbV6sHn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=FjACSRhQ4UKmKXGoFk9GEJBnnNPtTjTskVaymEcXd7MXTyBGD9YXcWQRL/o7Hj3Hf QZeo7qZbs4hWq0LOopk1dzqVQmFC/i8CkEbGYZISS83ee4ngzr0J2OElVRf53Bo8CM rySL+AqZk3M2HBauij1zepzoLuz+BbDo9NSXZVdc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727928AbgBRT7g (ORCPT ); Tue, 18 Feb 2020 14:59:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:38308 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727976AbgBRT7e (ORCPT ); Tue, 18 Feb 2020 14:59:34 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3BB9420659; Tue, 18 Feb 2020 19:59:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055973; bh=TQmI2Xi+jSe1xvgDZog4lmUKoHRkgibmTGpmbV6sHn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UjC2lSJELTUhYUDXbL8s1Xy6eUJsH1BINZPznLm7dQnPH2fQoo9u+tiZvfuhuGG81 gRgfydxDyxRL6lGm2h6lA998lkr7trugYaYEg4i/45/clDvDOg5O6E7aKSQbByOu9R cSS2P1ftQNE8cjQSqPfSAPxvdNe3+qv6H06jdANY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Herbert Poetzl , Theodore Tso , stable@kernel.org Subject: [PATCH 5.4 15/66] ext4: fix support for inode sizes > 1024 bytes Date: Tue, 18 Feb 2020 20:54:42 +0100 Message-Id: <20200218190429.495896795@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Theodore Ts'o commit 4f97a68192bd33b9963b400759cef0ca5963af00 upstream. A recent commit, 9803387c55f7 ("ext4: validate the debug_want_extra_isize mount option at parse time"), moved mount-time checks around. One of those changes moved the inode size check before the blocksize variable was set to the blocksize of the file system. After 9803387c55f7 was set to the minimum allowable blocksize, which in practice on most systems would be 1024 bytes. This cuased file systems with inode sizes larger than 1024 bytes to be rejected with a message: EXT4-fs (sdXX): unsupported inode size: 4096 Fixes: 9803387c55f7 ("ext4: validate the debug_want_extra_isize mount option at parse time") Link: https://lore.kernel.org/r/20200206225252.GA3673@mit.edu Reported-by: Herbert Poetzl Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/super.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3765,6 +3765,15 @@ static int ext4_fill_super(struct super_ */ sbi->s_li_wait_mult = EXT4_DEF_LI_WAIT_MULT; + blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size); + if (blocksize < EXT4_MIN_BLOCK_SIZE || + blocksize > EXT4_MAX_BLOCK_SIZE) { + ext4_msg(sb, KERN_ERR, + "Unsupported filesystem blocksize %d (%d log_block_size)", + blocksize, le32_to_cpu(es->s_log_block_size)); + goto failed_mount; + } + if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV) { sbi->s_inode_size = EXT4_GOOD_OLD_INODE_SIZE; sbi->s_first_ino = EXT4_GOOD_OLD_FIRST_INO; @@ -3782,6 +3791,7 @@ static int ext4_fill_super(struct super_ ext4_msg(sb, KERN_ERR, "unsupported inode size: %d", sbi->s_inode_size); + ext4_msg(sb, KERN_ERR, "blocksize: %d", blocksize); goto failed_mount; } /* @@ -3985,14 +3995,6 @@ static int ext4_fill_super(struct super_ if (!ext4_feature_set_ok(sb, (sb_rdonly(sb)))) goto failed_mount; - blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size); - if (blocksize < EXT4_MIN_BLOCK_SIZE || - blocksize > EXT4_MAX_BLOCK_SIZE) { - ext4_msg(sb, KERN_ERR, - "Unsupported filesystem blocksize %d (%d log_block_size)", - blocksize, le32_to_cpu(es->s_log_block_size)); - goto failed_mount; - } if (le32_to_cpu(es->s_log_block_size) > (EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) { ext4_msg(sb, KERN_ERR, From patchwork Tue Feb 18 19:54:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231100 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BFE6C34049 for ; Tue, 18 Feb 2020 20:06:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6638621D56 for ; Tue, 18 Feb 2020 20:06:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056416; bh=ctiJ5QklUUUiqbxfDM/aAC6O/xND98Ys7P27q8+cOqc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=ol0pKjoAn5BBMTIHUGbOGFWetyuzYJI8T8FGHkvVEsHe+bMEDhFf0rZW/YDf2sC3S AiFrY1BCfAOYQ4zemPHMMQKsmqiQ85YHfmCNP4ja39Z4bLDcptWv9xiMZ0XTSPqGP/ w7fEQXlywl2SRpNtozdDnCsaA0cqvKn2A2gwb6Rk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728451AbgBRT7k (ORCPT ); Tue, 18 Feb 2020 14:59:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:38450 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726632AbgBRT7j (ORCPT ); Tue, 18 Feb 2020 14:59:39 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8C26020659; Tue, 18 Feb 2020 19:59:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055979; bh=ctiJ5QklUUUiqbxfDM/aAC6O/xND98Ys7P27q8+cOqc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BG+WAOCv4OPHH5ji/qhBLAOyVVUoNJol26aLaQ9k6VpBryoXHpG31lURKiEygD+NX 6AxdhQK0HRI16vk5rrlcwj6gdZXHEeJURuZOcrqsWWqpqiGdYVLGE5C+Q9bk3Ya0yw 2drj2BYlzHrG/VyB6Jy1RUPb47nhuiR86y0GndPs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jan Kara , Shijie Luo , Theodore Tso , stable@kernel.org Subject: [PATCH 5.4 17/66] ext4: add cond_resched() to ext4_protect_reserved_inode Date: Tue, 18 Feb 2020 20:54:44 +0100 Message-Id: <20200218190429.681173507@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Shijie Luo commit af133ade9a40794a37104ecbcc2827c0ea373a3c upstream. When journal size is set too big by "mkfs.ext4 -J size=", or when we mount a crafted image to make journal inode->i_size too big, the loop, "while (i < num)", holds cpu too long. This could cause soft lockup. [ 529.357541] Call trace: [ 529.357551] dump_backtrace+0x0/0x198 [ 529.357555] show_stack+0x24/0x30 [ 529.357562] dump_stack+0xa4/0xcc [ 529.357568] watchdog_timer_fn+0x300/0x3e8 [ 529.357574] __hrtimer_run_queues+0x114/0x358 [ 529.357576] hrtimer_interrupt+0x104/0x2d8 [ 529.357580] arch_timer_handler_virt+0x38/0x58 [ 529.357584] handle_percpu_devid_irq+0x90/0x248 [ 529.357588] generic_handle_irq+0x34/0x50 [ 529.357590] __handle_domain_irq+0x68/0xc0 [ 529.357593] gic_handle_irq+0x6c/0x150 [ 529.357595] el1_irq+0xb8/0x140 [ 529.357599] __ll_sc_atomic_add_return_acquire+0x14/0x20 [ 529.357668] ext4_map_blocks+0x64/0x5c0 [ext4] [ 529.357693] ext4_setup_system_zone+0x330/0x458 [ext4] [ 529.357717] ext4_fill_super+0x2170/0x2ba8 [ext4] [ 529.357722] mount_bdev+0x1a8/0x1e8 [ 529.357746] ext4_mount+0x44/0x58 [ext4] [ 529.357748] mount_fs+0x50/0x170 [ 529.357752] vfs_kern_mount.part.9+0x54/0x188 [ 529.357755] do_mount+0x5ac/0xd78 [ 529.357758] ksys_mount+0x9c/0x118 [ 529.357760] __arm64_sys_mount+0x28/0x38 [ 529.357764] el0_svc_common+0x78/0x130 [ 529.357766] el0_svc_handler+0x38/0x78 [ 529.357769] el0_svc+0x8/0xc [ 541.356516] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [mount:18674] Link: https://lore.kernel.org/r/20200211011752.29242-1-luoshijie1@huawei.com Reviewed-by: Jan Kara Signed-off-by: Shijie Luo Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/block_validity.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/block_validity.c +++ b/fs/ext4/block_validity.c @@ -203,6 +203,7 @@ static int ext4_protect_reserved_inode(s return PTR_ERR(inode); num = (inode->i_size + sb->s_blocksize - 1) >> sb->s_blocksize_bits; while (i < num) { + cond_resched(); map.m_lblk = i; map.m_len = num - i; n = ext4_map_blocks(NULL, inode, &map, 0); From patchwork Tue Feb 18 19:54:46 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231101 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4DCCC34047 for ; Tue, 18 Feb 2020 20:06:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F81222B48 for ; Tue, 18 Feb 2020 20:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056413; bh=RrjwY8iUS2uLbXYQfD3W83BApgHzmS8EhIQvGuq9OQg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=OVf6+smNbdaBO5l7y5jE8fFJvrepLaYGbYmMyWXlFrHIqOYtsY7gYBgEXks2lx6fg RUwvV5l7Wsb+Eo/SGBe7uNtkC+Iuxdp6Md0igexK8jqp2lWbbULgTILq0PJiAGr/vD pIAHpwt1iEhcHYD7075mxShJUQMa7842o5R6gyFA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727935AbgBRT7q (ORCPT ); Tue, 18 Feb 2020 14:59:46 -0500 Received: from mail.kernel.org ([198.145.29.99]:38596 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726680AbgBRT7p (ORCPT ); Tue, 18 Feb 2020 14:59:45 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 04FA424655; Tue, 18 Feb 2020 19:59:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055984; bh=RrjwY8iUS2uLbXYQfD3W83BApgHzmS8EhIQvGuq9OQg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kwN8qoER9LXBTKVaZr5JtgP+LPxvAk/a4glzRnAO6qPbdzzGf6eRpuWd4DNIRlDue T3OT5RnQH26CXxvQonnz3ifWaw301CbZ5CkTw01cPV+C9lqgrtj+MpOJA2dC4W482V ixZ8E3VZGHlzhvE34iJV8rTlF9pODhyYmAQOePFQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, ryusuke1925 , Koki Mitani , Josef Bacik , Filipe Manana , David Sterba Subject: [PATCH 5.4 19/66] Btrfs: fix race between using extent maps and merging them Date: Tue, 18 Feb 2020 20:54:46 +0100 Message-Id: <20200218190429.869894993@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Filipe Manana commit ac05ca913e9f3871126d61da275bfe8516ff01ca upstream. We have a few cases where we allow an extent map that is in an extent map tree to be merged with other extents in the tree. Such cases include the unpinning of an extent after the respective ordered extent completed or after logging an extent during a fast fsync. This can lead to subtle and dangerous problems because when doing the merge some other task might be using the same extent map and as consequence see an inconsistent state of the extent map - for example sees the new length but has seen the old start offset. With luck this triggers a BUG_ON(), and not some silent bug, such as the following one in __do_readpage(): $ cat -n fs/btrfs/extent_io.c 3061 static int __do_readpage(struct extent_io_tree *tree, 3062 struct page *page, (...) 3127 em = __get_extent_map(inode, page, pg_offset, cur, 3128 end - cur + 1, get_extent, em_cached); 3129 if (IS_ERR_OR_NULL(em)) { 3130 SetPageError(page); 3131 unlock_extent(tree, cur, end); 3132 break; 3133 } 3134 extent_offset = cur - em->start; 3135 BUG_ON(extent_map_end(em) <= cur); (...) Consider the following example scenario, where we end up hitting the BUG_ON() in __do_readpage(). We have an inode with a size of 8KiB and 2 extent maps: extent A: file offset 0, length 4KiB, disk_bytenr = X, persisted on disk by a previous transaction extent B: file offset 4KiB, length 4KiB, disk_bytenr = X + 4KiB, not yet persisted but writeback started for it already. The extent map is pinned since there's writeback and an ordered extent in progress, so it can not be merged with extent map A yet The following sequence of steps leads to the BUG_ON(): 1) The ordered extent for extent B completes, the respective page gets its writeback bit cleared and the extent map is unpinned, at that point it is not yet merged with extent map A because it's in the list of modified extents; 2) Due to memory pressure, or some other reason, the MM subsystem releases the page corresponding to extent B - btrfs_releasepage() is called and returns 1, meaning the page can be released as it's not dirty, not under writeback anymore and the extent range is not locked in the inode's iotree. However the extent map is not released, either because we are not in a context that allows memory allocations to block or because the inode's size is smaller than 16MiB - in this case our inode has a size of 8KiB; 3) Task B needs to read extent B and ends up __do_readpage() through the btrfs_readpage() callback. At __do_readpage() it gets a reference to extent map B; 4) Task A, doing a fast fsync, calls clear_em_loggin() against extent map B while holding the write lock on the inode's extent map tree - this results in try_merge_map() being called and since it's possible to merge extent map B with extent map A now (the extent map B was removed from the list of modified extents), the merging begins - it sets extent map B's start offset to 0 (was 4KiB), but before it increments the map's length to 8KiB (4kb + 4KiB), task A is at: BUG_ON(extent_map_end(em) <= cur); The call to extent_map_end() sees the extent map has a start of 0 and a length still at 4KiB, so it returns 4KiB and 'cur' is 4KiB, so the BUG_ON() is triggered. So it's dangerous to modify an extent map that is in the tree, because some other task might have got a reference to it before and still using it, and needs to see a consistent map while using it. Generally this is very rare since most paths that lookup and use extent maps also have the file range locked in the inode's iotree. The fsync path is pretty much the only exception where we don't do it to avoid serialization with concurrent reads. Fix this by not allowing an extent map do be merged if if it's being used by tasks other then the one attempting to merge the extent map (when the reference count of the extent map is greater than 2). Reported-by: ryusuke1925 Reported-by: Koki Mitani Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206211 CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/extent_map.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/fs/btrfs/extent_map.c +++ b/fs/btrfs/extent_map.c @@ -233,6 +233,17 @@ static void try_merge_map(struct extent_ struct extent_map *merge = NULL; struct rb_node *rb; + /* + * We can't modify an extent map that is in the tree and that is being + * used by another task, as it can cause that other task to see it in + * inconsistent state during the merging. We always have 1 reference for + * the tree and 1 for this task (which is unpinning the extent map or + * clearing the logging flag), so anything > 2 means it's being used by + * other tasks too. + */ + if (refcount_read(&em->refs) > 2) + return; + if (em->start != 0) { rb = rb_prev(&em->rb_node); if (rb) From patchwork Tue Feb 18 19:54:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231087 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3AD6C34026 for ; Tue, 18 Feb 2020 20:08:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AD11622B48 for ; Tue, 18 Feb 2020 20:08:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056503; bh=oHjNPYRc6V5pjSMnY/9ywhh4+Sjp1tPVDNCkJphgWzo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=ggsgKm5BKByyhOmIzTQrA4k34DGzon0PU0M4WMmFebb0S26DhTcZp01SmC7UnbqCY z0UZ55RGTENI087rq844nioNnPDlvz1Y+ien+Dy9owFHwdWiLNncGtY87D/BIOPeyo /LX5QdHU2P2kLH37R+N/OrTALdMhRK/EwIdUTWGo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726521AbgBRUIS (ORCPT ); Tue, 18 Feb 2020 15:08:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:35576 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727280AbgBRT6F (ORCPT ); Tue, 18 Feb 2020 14:58:05 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2902A20659; Tue, 18 Feb 2020 19:58:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055884; bh=oHjNPYRc6V5pjSMnY/9ywhh4+Sjp1tPVDNCkJphgWzo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I8TIB41JmU6qtIbsyR7mUY64+5j+yc4hMJmjPn1DNDf+JEqHMxqFkQuMChHWkLxS/ krgUJk1y8VAIflV/juorxwxpNwisW47haMnn9nALQSFP8sSsDQ0Ylh+oEC1o2l/fV9 lnEY1WCO3iQfGcdPfgolpzz/pm//USZw9MRcmIsg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Wenwen Wang , David Sterba Subject: [PATCH 5.4 20/66] btrfs: ref-verify: fix memory leaks Date: Tue, 18 Feb 2020 20:54:47 +0100 Message-Id: <20200218190429.964168504@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Wenwen Wang commit f311ade3a7adf31658ed882aaab9f9879fdccef7 upstream. In btrfs_ref_tree_mod(), 'ref' and 'ra' are allocated through kzalloc() and kmalloc(), respectively. In the following code, if an error occurs, the execution will be redirected to 'out' or 'out_unlock' and the function will be exited. However, on some of the paths, 'ref' and 'ra' are not deallocated, leading to memory leaks. For example, if 'action' is BTRFS_ADD_DELAYED_EXTENT, add_block_entry() will be invoked. If the return value indicates an error, the execution will be redirected to 'out'. But, 'ref' is not deallocated on this path, causing a memory leak. To fix the above issues, deallocate both 'ref' and 'ra' before exiting from the function when an error is encountered. CC: stable@vger.kernel.org # 4.15+ Signed-off-by: Wenwen Wang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/ref-verify.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/btrfs/ref-verify.c +++ b/fs/btrfs/ref-verify.c @@ -744,6 +744,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i */ be = add_block_entry(fs_info, bytenr, num_bytes, ref_root); if (IS_ERR(be)) { + kfree(ref); kfree(ra); ret = PTR_ERR(be); goto out; @@ -757,6 +758,8 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i "re-allocated a block that still has references to it!"); dump_block_entry(fs_info, be); dump_ref_action(fs_info, ra); + kfree(ref); + kfree(ra); goto out_unlock; } @@ -819,6 +822,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i "dropping a ref for a existing root that doesn't have a ref on the block"); dump_block_entry(fs_info, be); dump_ref_action(fs_info, ra); + kfree(ref); kfree(ra); goto out_unlock; } @@ -834,6 +838,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i "attempting to add another ref for an existing ref on a tree block"); dump_block_entry(fs_info, be); dump_ref_action(fs_info, ra); + kfree(ref); kfree(ra); goto out_unlock; } From patchwork Tue Feb 18 19:54:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231088 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6E51C34026 for ; Tue, 18 Feb 2020 20:08:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 801472067D for ; Tue, 18 Feb 2020 20:08:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056497; bh=KpYOPciSmTWjaph1IG5iXug5PcvcPFkmcNBP0aZpfJI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=RJPvV3f4ZNSxTR2bJX6WMkiVjiZ6aKSOcO5TfyX5ewHV2ECH4dM/jRurQTgTtznVq DirFTePCPE9aqavMz0iM2FwyZkU/aI58xJ4o1Rw0pMBXURJevyJc5mCetpcNAQWPYJ CTOVjwA0eWYAznrfkjVE06Et1rBJ1i6A3dXhbvXQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728133AbgBRT6K (ORCPT ); Tue, 18 Feb 2020 14:58:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:35672 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728128AbgBRT6J (ORCPT ); Tue, 18 Feb 2020 14:58:09 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1E05520659; Tue, 18 Feb 2020 19:58:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055889; bh=KpYOPciSmTWjaph1IG5iXug5PcvcPFkmcNBP0aZpfJI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S5cSV8CucBJTs/ZHKVWKF2218QqpXEbK/iGDuy4FjPX5SU+ulO8iMU230gFviN8zQ 5aTWDELlW0hX6nzc2eJBueHvOxxgLlB9S9CrgePpIW9H+NMN10DH8IsWPS4L3EpD2C 4QKlisyOnh03QQe8oahTlBdJH3iP74i3tB4RDPEM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Anand Jain , Johannes Thumshirn , David Sterba Subject: [PATCH 5.4 22/66] btrfs: log message when rw remount is attempted with unclean tree-log Date: Tue, 18 Feb 2020 20:54:49 +0100 Message-Id: <20200218190430.142378570@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: David Sterba commit 10a3a3edc5b89a8cd095bc63495fb1e0f42047d9 upstream. A remount to a read-write filesystem is not safe when there's tree-log to be replayed. Files that could be opened until now might be affected by the changes in the tree-log. A regular mount is needed to replay the log so the filesystem presents the consistent view with the pending changes included. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Anand Jain Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/super.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -1804,6 +1804,8 @@ static int btrfs_remount(struct super_bl } if (btrfs_super_log_root(fs_info->super_copy) != 0) { + btrfs_warn(fs_info, + "mount required to replay tree-log, cannot remount read-write"); ret = -EINVAL; goto restore; } From patchwork Tue Feb 18 19:54:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231154 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4797BC34047 for ; Tue, 18 Feb 2020 19:58:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 17EC720659 for ; Tue, 18 Feb 2020 19:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055899; bh=H+16V16wnbDW8zmH8rcsA0BqL7v9Yl6dcr/5UjFg3Lo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=KZo9KEyigBUtk+wnhop/0Ggn/Z3suYb6Ubj7R6kQdHTc08TvodfemsGEdVV356eak OfknTYnrFvcPTX3ZdPW2Lzn9QZG5Bv4A4YMZvhBwaoWIGl6YFsijrIerdh2rXi9L4i qYihW2DYuW6GvcmIC5iMHZemruTePBHb4x0DTYTo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727503AbgBRT6R (ORCPT ); Tue, 18 Feb 2020 14:58:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:35838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726557AbgBRT6R (ORCPT ); Tue, 18 Feb 2020 14:58:17 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 95E5120659; Tue, 18 Feb 2020 19:58:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055897; bh=H+16V16wnbDW8zmH8rcsA0BqL7v9Yl6dcr/5UjFg3Lo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YdgTQ3ZBwScOVtJztE0X2dbQJeDgmOB7AoCVmw8XL8QmshWpE+in1uiEBi3MXaxcP disaFRD28+GhuqiyKUQC/BceeCzDAKkToBingA+g4iYFyP7rT4GljScBQLKmY3DdJ4 zCRguthQfgnljs3INktzFC4mch1gDDpSpnGcuzMg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Krzysztof Kozlowski , Olof Johansson Subject: [PATCH 5.4 23/66] ARM: npcm: Bring back GPIOLIB support Date: Tue, 18 Feb 2020 20:54:50 +0100 Message-Id: <20200218190430.231827471@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Krzysztof Kozlowski commit e383e871ab54f073c2a798a9e0bde7f1d0528de8 upstream. The CONFIG_ARCH_REQUIRE_GPIOLIB is gone since commit 65053e1a7743 ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB") and all platforms should explicitly select GPIOLIB to have it. Link: https://lore.kernel.org/r/20200130195525.4525-1-krzk@kernel.org Cc: Fixes: 65053e1a7743 ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman --- arch/arm/mach-npcm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/mach-npcm/Kconfig +++ b/arch/arm/mach-npcm/Kconfig @@ -11,7 +11,7 @@ config ARCH_NPCM7XX depends on ARCH_MULTI_V7 select PINCTRL_NPCM7XX select NPCM7XX_TIMER - select ARCH_REQUIRE_GPIOLIB + select GPIOLIB select CACHE_L2X0 select ARM_GIC select HAVE_ARM_TWD if SMP From patchwork Tue Feb 18 19:54:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231089 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59985C34026 for ; Tue, 18 Feb 2020 20:08:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 288802067D for ; Tue, 18 Feb 2020 20:08:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056494; bh=gXlqe2ZJceVqgHl8SGNURvfC+AiCU2Ij8n9ZA2sMH2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=I7v7xZYP/ykhH5R0HXAYphnXdy07+vWWIgfseM2Qy6mENEMOBcCihKF6LW724+/Aq BxMJudZEjQvn1TlDqqD9ldzFgpZU7xgANK4ycHOLIymdUZs5VHQqbcL9AXkJi5KYWZ ASRYoBu6Q2IXaIDGokVVNHeMrAsc2D5iPG2Sn7sY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728174AbgBRT6X (ORCPT ); Tue, 18 Feb 2020 14:58:23 -0500 Received: from mail.kernel.org ([198.145.29.99]:35994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728172AbgBRT6X (ORCPT ); Tue, 18 Feb 2020 14:58:23 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8DEDF20659; Tue, 18 Feb 2020 19:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055902; bh=gXlqe2ZJceVqgHl8SGNURvfC+AiCU2Ij8n9ZA2sMH2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2v3n3+xh+ipNTB3YVRB0WslaaMrjJ8h1bJZdS/vD1b/ha/MCHH4LWpvQfDgd/meT5 8RMQuuB/kx2fJPK+OJBtQjlj5Iwj/lRzF2ZpfK3SEQwVLvLi3D7da9kWP8uthWO7fd F9j2Xx44sL+Y5f+7fY1TKX19jBfsxyhYbEoncAIQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , Srinivas Ramana , Marc Zyngier , Will Deacon Subject: [PATCH 5.4 25/66] arm64: ssbs: Fix context-switch when SSBS is present on all CPUs Date: Tue, 18 Feb 2020 20:54:52 +0100 Message-Id: <20200218190430.404051028@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Will Deacon commit fca3d33d8ad61eb53eca3ee4cac476d1e31b9008 upstream. When all CPUs in the system implement the SSBS extension, the SSBS field in PSTATE is the definitive indication of the mitigation state. Further, when the CPUs implement the SSBS manipulation instructions (advertised to userspace via an HWCAP), EL0 can toggle the SSBS field directly and so we cannot rely on any shadow state such as TIF_SSBD at all. Avoid forcing the SSBS field in context-switch on such a system, and simply rely on the PSTATE register instead. Cc: Cc: Catalin Marinas Cc: Srinivas Ramana Fixes: cbdf8a189a66 ("arm64: Force SSBS on context switch") Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -466,6 +466,13 @@ static void ssbs_thread_switch(struct ta if (unlikely(next->flags & PF_KTHREAD)) return; + /* + * If all CPUs implement the SSBS extension, then we just need to + * context-switch the PSTATE field. + */ + if (cpu_have_feature(cpu_feature(SSBS))) + return; + /* If the mitigation is enabled, then we leave SSBS clear. */ if ((arm64_get_ssbd_state() == ARM64_SSBD_FORCE_ENABLE) || test_tsk_thread_flag(next, TIF_SSBD)) From patchwork Tue Feb 18 19:54:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231153 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8282C34049 for ; Tue, 18 Feb 2020 19:58:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B207D2465D for ; Tue, 18 Feb 2020 19:58:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055914; bh=yYZKeSyGawqNcMCw4ypNqgx7uLhMIDMRc5yLeMvZ3TI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=KuWYpMQpATdbaonq+UADcYuR5ZWGpXXDIktEGl9wSc4m+k9kzugBAacaG+/OYEHsA /mHp8oIGzPjA5jop4hCDO4YNybpID831qn6MxQF/BgVO1o/YmeK3Cn7wq3ZzC8WDXK L/X2+3hGhaf3XgIE3pBM0/HobaZ01LGPYbgc8AL8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728216AbgBRT6e (ORCPT ); Tue, 18 Feb 2020 14:58:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:36222 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728203AbgBRT6a (ORCPT ); Tue, 18 Feb 2020 14:58:30 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 424F424125; Tue, 18 Feb 2020 19:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055909; bh=yYZKeSyGawqNcMCw4ypNqgx7uLhMIDMRc5yLeMvZ3TI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TgSRUfSvXZQtBz3N0gnamkpv9aczV4NUZZN4LtnNT5uww8UyQWeX45UnFx7M/DHz6 NFsg2SSYguua6Euk7c1AR0bcQQe3aVEkcCzTl8o14sUip203ao6hk6+E9k3EDVKWOj dt4gPXeR1ddcTN8zSB+SAkWqPyNQ0NxVJHDVX2yY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Richter , Borislav Petkov , John Garry Subject: [PATCH 5.4 28/66] EDAC/sysfs: Remove csrow objects on errors Date: Tue, 18 Feb 2020 20:54:55 +0100 Message-Id: <20200218190430.669318831@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Robert Richter commit 4d59588c09f2a2daedad2a544d4d1b602ab3a8af upstream. All created csrow objects must be removed in the error path of edac_create_csrow_objects(). The objects have been added as devices. They need to be removed by doing a device_del() *and* put_device() call to also free their memory. The missing put_device() leaves a memory leak. Use device_unregister() instead of device_del() which properly unregisters the device doing both. Fixes: 7adc05d2dc3a ("EDAC/sysfs: Drop device references properly") Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Tested-by: John Garry Cc: Link: https://lkml.kernel.org/r/20200212120340.4764-4-rrichter@marvell.com Signed-off-by: Greg Kroah-Hartman --- drivers/edac/edac_mc_sysfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/edac/edac_mc_sysfs.c +++ b/drivers/edac/edac_mc_sysfs.c @@ -447,8 +447,7 @@ error: csrow = mci->csrows[i]; if (!nr_pages_per_csrow(csrow)) continue; - - device_del(&mci->csrows[i]->dev); + device_unregister(&mci->csrows[i]->dev); } return err; From patchwork Tue Feb 18 19:54:56 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231090 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CED1AC34026 for ; Tue, 18 Feb 2020 20:08:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A14B42067D for ; Tue, 18 Feb 2020 20:08:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056490; bh=Y+p35oZA6EvXFtibK1QrYEqzN/+CJYN7+vX9iMq7Tys=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=JHcG5RNwoZEfGUHwQvj2H3TSoIZY4UJE5OE7XGzKpxBQQI1rtQDqYDOM80Oz2yEb8 LgnIscYKv9f0eMvJ3ZPF1CtPnQWXTCuZd3Y+TGQmg7g2A/McdQwFYlr5TxpnmdGjsn kRcq5jIFhaKOsJwnSf1HRqwS4hhv0KZw7fi4z2rI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727838AbgBRT6d (ORCPT ); Tue, 18 Feb 2020 14:58:33 -0500 Received: from mail.kernel.org ([198.145.29.99]:36312 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728183AbgBRT6d (ORCPT ); Tue, 18 Feb 2020 14:58:33 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B716B20659; Tue, 18 Feb 2020 19:58:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055912; bh=Y+p35oZA6EvXFtibK1QrYEqzN/+CJYN7+vX9iMq7Tys=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JkXCc2aIfH9EbQUvsYiICsXriwLBb9Lio+4K/M12/NWdpbW3l8OQgiE/QAcOBShZK XUtSAbb/a6k0F4wXC1MLfI8yEgLdUq+cbYD8cnGb0bI5CoyRmvJ0orCdQEmGC/mhnB kzbYceKrCbjIl8oWJ5awuw87uTuxyJVrw74xB/3U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, John Garry , Robert Richter , Borislav Petkov Subject: [PATCH 5.4 29/66] EDAC/mc: Fix use-after-free and memleaks during device removal Date: Tue, 18 Feb 2020 20:54:56 +0100 Message-Id: <20200218190430.757292618@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Robert Richter commit 216aa145aaf379a50b17afc812db71d893bd6683 upstream. A test kernel with the options DEBUG_TEST_DRIVER_REMOVE, KASAN and DEBUG_KMEMLEAK set, revealed several issues when removing an mci device: 1) Use-after-free: On 27.11.19 17:07:33, John Garry wrote: > [ 22.104498] BUG: KASAN: use-after-free in > edac_remove_sysfs_mci_device+0x148/0x180 The use-after-free is caused by the mci_for_each_dimm() macro called in edac_remove_sysfs_mci_device(). The iterator was introduced with c498afaf7df8 ("EDAC: Introduce an mci_for_each_dimm() iterator"). The iterator loop calls device_unregister(&dimm->dev), which removes the sysfs entry of the device, but also frees the dimm struct in dimm_attr_release(). When incrementing the loop in mci_for_each_dimm(), the dimm struct is accessed again, after having been freed already. The fix is to free all the mci device's subsequent dimm and csrow objects at a later point, in _edac_mc_free(), when the mci device itself is being freed. This keeps the data structures intact and the mci device can be fully used until its removal. The change allows the safe usage of mci_for_each_dimm() to release dimm devices from sysfs. 2) Memory leaks: Following memory leaks have been detected: # grep edac /sys/kernel/debug/kmemleak | sort | uniq -c 1 [<000000003c0f58f9>] edac_mc_alloc+0x3bc/0x9d0 # mci->csrows 16 [<00000000bb932dc0>] edac_mc_alloc+0x49c/0x9d0 # csr->channels 16 [<00000000e2734dba>] edac_mc_alloc+0x518/0x9d0 # csr->channels[chn] 1 [<00000000eb040168>] edac_mc_alloc+0x5c8/0x9d0 # mci->dimms 34 [<00000000ef737c29>] ghes_edac_register+0x1c8/0x3f8 # see edac_mc_alloc() All leaks are from memory allocated by edac_mc_alloc(). Note: The test above shows that edac_mc_alloc() was called here from ghes_edac_register(), thus both functions show up in the stack trace but the module causing the leaks is edac_mc. The comments with the data structures involved were made manually by analyzing the objdump. The data structures listed above and created by edac_mc_alloc() are not properly removed during device removal, which is done in edac_mc_free(). There are two paths implemented to remove the device depending on device registration, _edac_mc_free() is called if the device is not registered and edac_unregister_sysfs() otherwise. The implemenations differ. For the sysfs case, the mci device removal lacks the removal of subsequent data structures (csrows, channels, dimms). This causes the memory leaks (see mci_attr_release()). [ bp: Massage commit message. ] Fixes: c498afaf7df8 ("EDAC: Introduce an mci_for_each_dimm() iterator") Fixes: faa2ad09c01c ("edac_mc: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs.") Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device") Reported-by: John Garry Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Tested-by: John Garry Cc: Link: https://lkml.kernel.org/r/20200212120340.4764-3-rrichter@marvell.com Signed-off-by: Greg Kroah-Hartman --- drivers/edac/edac_mc.c | 12 +++--------- drivers/edac/edac_mc_sysfs.c | 15 +++------------ 2 files changed, 6 insertions(+), 21 deletions(-) --- a/drivers/edac/edac_mc.c +++ b/drivers/edac/edac_mc.c @@ -503,16 +503,10 @@ void edac_mc_free(struct mem_ctl_info *m { edac_dbg(1, "\n"); - /* If we're not yet registered with sysfs free only what was allocated - * in edac_mc_alloc(). - */ - if (!device_is_registered(&mci->dev)) { - _edac_mc_free(mci); - return; - } + if (device_is_registered(&mci->dev)) + edac_unregister_sysfs(mci); - /* the mci instance is freed here, when the sysfs object is dropped */ - edac_unregister_sysfs(mci); + _edac_mc_free(mci); } EXPORT_SYMBOL_GPL(edac_mc_free); --- a/drivers/edac/edac_mc_sysfs.c +++ b/drivers/edac/edac_mc_sysfs.c @@ -276,10 +276,7 @@ static const struct attribute_group *csr static void csrow_attr_release(struct device *dev) { - struct csrow_info *csrow = container_of(dev, struct csrow_info, dev); - - edac_dbg(1, "device %s released\n", dev_name(dev)); - kfree(csrow); + /* release device with _edac_mc_free() */ } static const struct device_type csrow_attr_type = { @@ -619,10 +616,7 @@ static const struct attribute_group *dim static void dimm_attr_release(struct device *dev) { - struct dimm_info *dimm = container_of(dev, struct dimm_info, dev); - - edac_dbg(1, "device %s released\n", dev_name(dev)); - kfree(dimm); + /* release device with _edac_mc_free() */ } static const struct device_type dimm_attr_type = { @@ -905,10 +899,7 @@ static const struct attribute_group *mci static void mci_attr_release(struct device *dev) { - struct mem_ctl_info *mci = container_of(dev, struct mem_ctl_info, dev); - - edac_dbg(1, "device %s released\n", dev_name(dev)); - kfree(mci); + /* release device with _edac_mc_free() */ } static const struct device_type mci_attr_type = { From patchwork Tue Feb 18 19:54:58 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231091 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAB8BC34047 for ; Tue, 18 Feb 2020 20:07:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C56FE22B48 for ; Tue, 18 Feb 2020 20:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056478; bh=nqHU8jXhun/Vp7ATeVmn5fPoMWew8sVRoYGpt1T47a4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=CJLZVcJIfbeEFVxxBjitDxHVHhL4t0wiSPG7x8mPxqnbhjHkRj5uDl/FSchCC7CIw THvr9MDhbn32glj50Vx/22WeaSWY7b5T5Ge+oOrE7HeKA7tnsZNA+j+MoFzAa/+kWA CMw+WUlNHcGdjxko7gmigXmakZBlWsOsVbzg/WNQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728248AbgBRT6l (ORCPT ); Tue, 18 Feb 2020 14:58:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:36520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728243AbgBRT6k (ORCPT ); Tue, 18 Feb 2020 14:58:40 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A14CF24125; Tue, 18 Feb 2020 19:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055920; bh=nqHU8jXhun/Vp7ATeVmn5fPoMWew8sVRoYGpt1T47a4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QmDIRf4P+RGpeCiNM9/rSQ3TUciYEiYq8TPwzukSSCb+NPhseIl3AhCPzYFcnh2Tw K/yG/Prgz2TE8MlucO8nbFu9f12rS8+6mQGZudE/XhirA8TvK9uLBz5AU/3SyJ4hBF gYg7poKiC+ftPUX0H58AkBf1byelIaI6LAWPBtSw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Babu Moger , Kim Phillips , "Peter Zijlstra (Intel)" , Ingo Molnar Subject: [PATCH 5.4 31/66] perf/x86/amd: Add missing L2 misses event spec to AMD Family 17hs event map Date: Tue, 18 Feb 2020 20:54:58 +0100 Message-Id: <20200218190430.947195319@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kim Phillips commit 25d387287cf0330abf2aad761ce6eee67326a355 upstream. Commit 3fe3331bb285 ("perf/x86/amd: Add event map for AMD Family 17h"), claimed L2 misses were unsupported, due to them not being found in its referenced documentation, whose link has now moved [1]. That old documentation listed PMCx064 unit mask bit 3 as: "LsRdBlkC: LS Read Block C S L X Change to X Miss." and bit 0 as: "IcFillMiss: IC Fill Miss" We now have new public documentation [2] with improved descriptions, that clearly indicate what events those unit mask bits represent: Bit 3 now clearly states: "LsRdBlkC: Data Cache Req Miss in L2 (all types)" and bit 0 is: "IcFillMiss: Instruction Cache Req Miss in L2." So we can now add support for L2 misses in perf's genericised events as PMCx064 with both the above unit masks. [1] The commit's original documentation reference, "Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision B1 Processors", originally available here: https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf is now available here: https://developer.amd.com/wordpress/media/2017/11/54945_PPR_Family_17h_Models_00h-0Fh.pdf [2] "Processor Programming Reference (PPR) for Family 17h Model 31h, Revision B0 Processors", available here: https://developer.amd.com/wp-content/resources/55803_0.54-PUB.pdf Fixes: 3fe3331bb285 ("perf/x86/amd: Add event map for AMD Family 17h") Reported-by: Babu Moger Signed-off-by: Kim Phillips Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Tested-by: Babu Moger Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200121171232.28839-1-kim.phillips@amd.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/events/amd/core.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -246,6 +246,7 @@ static const u64 amd_f17h_perfmon_event_ [PERF_COUNT_HW_CPU_CYCLES] = 0x0076, [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0, [PERF_COUNT_HW_CACHE_REFERENCES] = 0xff60, + [PERF_COUNT_HW_CACHE_MISSES] = 0x0964, [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x00c2, [PERF_COUNT_HW_BRANCH_MISSES] = 0x00c3, [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x0287, From patchwork Tue Feb 18 19:55:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231092 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D756BC34026 for ; Tue, 18 Feb 2020 20:07:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B1E0C22B48 for ; Tue, 18 Feb 2020 20:07:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056469; bh=VlYFbi8R93NZ9MLjbFG8aNwqFw6eH/NfQOSq89lK47Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=SLyiNp/q0o/RM4WhnnKwFmSR1o7YPTgkp9Nlel2zjTTf7JcyRao/+im/Z/LeALgJx HpZHbbGe6QCLS1k2axoM7rEt8ogSLRSmpVFqaHkk2Khy7+CC43fAWLEclNc5cyE6Rk p1+RymePQCzvz0QyWoZjSY6ISVxVviaosP8RfD/s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728278AbgBRT6p (ORCPT ); Tue, 18 Feb 2020 14:58:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:36610 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727906AbgBRT6p (ORCPT ); Tue, 18 Feb 2020 14:58:45 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A697D24125; Tue, 18 Feb 2020 19:58:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055925; bh=VlYFbi8R93NZ9MLjbFG8aNwqFw6eH/NfQOSq89lK47Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p6SGSzlpgKfY/jGyPrOwXRrMLNgI8WfnIQjdj2w0rePmUxUZL9L8bof2yUJco4OFA WibSeljLZK7UhI0S2VZ81ohep/G2jsrIYiwQrKb2iQGOifT/01rGeJT+D1pSM564rl QZnNfLF8tXqcDhsqsqCXT6HdYAOSOo7mtWRnoq3Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Cornelia Huck , Christian Borntraeger , Vasily Gorbik Subject: [PATCH 5.4 33/66] s390/uv: Fix handling of length extensions Date: Tue, 18 Feb 2020 20:55:00 +0100 Message-Id: <20200218190431.133878860@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Christian Borntraeger commit 27dc0700c3be7c681cea03c5230b93d02f623492 upstream. The query parameter block might contain additional information and can be extended in the future. If the size of the block does not suffice we get an error code of rc=0x100. The buffer will contain all information up to the specified size and the hypervisor/guest simply do not need the additional information as they do not know about the new data. That means that we can (and must) accept rc=0x100 as success. Cc: stable@vger.kernel.org Reviewed-by: Cornelia Huck Fixes: 5abb9351dfd9 ("s390/uv: introduce guest side ultravisor code") Signed-off-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman --- arch/s390/boot/uv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/s390/boot/uv.c +++ b/arch/s390/boot/uv.c @@ -15,7 +15,8 @@ void uv_query_info(void) if (!test_facility(158)) return; - if (uv_call(0, (uint64_t)&uvcb)) + /* rc==0x100 means that there is additional data we do not process */ + if (uv_call(0, (uint64_t)&uvcb) && uvcb.header.rc != 0x100) return; if (test_bit_inv(BIT_UVC_CMD_SET_SHARED_ACCESS, (unsigned long *)uvcb.inst_calls_list) && From patchwork Tue Feb 18 19:55:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231152 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41DD2C34049 for ; Tue, 18 Feb 2020 19:58:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1B5A324670 for ; Tue, 18 Feb 2020 19:58:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055930; bh=lUIPdkq7OTx62a3ygJyQLftVTpwgspHMoLu7DyEpkQc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=upFgYaTfjbibaekvhVLPZFR9qiz/NR/VpMQQ/xjlNPrLEy4dr1KwPbAQUuRC87YRV vn26Mcp16gRfb9pRECNWDQ2PvI15A/KhwJV3wHEcp69P0UIenwvnB2HYRD0QqTAl6a 6on7drw4YK0Wr70hpguSc6qK0gjqMxQH6vqRAI+U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727906AbgBRT6s (ORCPT ); Tue, 18 Feb 2020 14:58:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:36646 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728288AbgBRT6s (ORCPT ); Tue, 18 Feb 2020 14:58:48 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEED420659; Tue, 18 Feb 2020 19:58:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055927; bh=lUIPdkq7OTx62a3ygJyQLftVTpwgspHMoLu7DyEpkQc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wz44PmpY9iMbWkLduWBuJT3Yf+0zDWXPDpvKLgIzIawnp8zw+h1YlwcVc9avLUY5O V5P76uepln9sINVeYtnK0oGUmR+RsxgOLobGjYmeF4EyNd9R3CR4S+wj/FDvU1qvMI 05ACJKVy9l9JxfARDyCk06ILzRUt7JsauAFwlLn4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dan Carpenter , Hillf Danton , syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com, Emil Velikov , Daniel Vetter , Sean Paul , Chris Wilson , Eric Anholt , Sam Ravnborg , Rob Clark , Daniel Vetter Subject: [PATCH 5.4 34/66] drm/vgem: Close use-after-free race in vgem_gem_create Date: Tue, 18 Feb 2020 20:55:01 +0100 Message-Id: <20200218190431.217621623@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Daniel Vetter commit 4b848f20eda5974020f043ca14bacf7a7e634fc8 upstream. There's two references floating around here (for the object reference, not the handle_count reference, that's a different thing): - The temporary reference held by vgem_gem_create, acquired by creating the object and released by calling drm_gem_object_put_unlocked. - The reference held by the object handle, created by drm_gem_handle_create. This one generally outlives the function, except if a 2nd thread races with a GEM_CLOSE ioctl call. So usually everything is correct, except in that race case, where the access to gem_object->size could be looking at freed data already. Which again isn't a real problem (userspace shot its feet off already with the race, we could return garbage), but maybe someone can exploit this as an information leak. Cc: Dan Carpenter Cc: Hillf Danton Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Emil Velikov Cc: Daniel Vetter Cc: Sean Paul Cc: Chris Wilson Cc: Eric Anholt Cc: Sam Ravnborg Cc: Rob Clark Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200202132133.1891846-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_c return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->base, handle); - drm_gem_object_put_unlocked(&obj->base); - if (ret) + if (ret) { + drm_gem_object_put_unlocked(&obj->base); return ERR_PTR(ret); + } return &obj->base; } @@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct d args->size = gem_object->size; args->pitch = pitch; - DRM_DEBUG("Created object of size %lld\n", size); + drm_gem_object_put_unlocked(gem_object); + + DRM_DEBUG("Created object of size %llu\n", args->size); return 0; } From patchwork Tue Feb 18 19:55:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231093 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 818A2C34049 for ; Tue, 18 Feb 2020 20:07:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4D9FE22B48 for ; Tue, 18 Feb 2020 20:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056460; bh=QmdDR5zvXy6PIgNyuxthXmWql3YpnD4Coiu30lyUMZg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=VB6sR9JFrsLNB47udo//MfegWCtWpLW6QOoeNHl7VUXzl5aOaL/pfMXC+NRGZWJlS PD5KRvtMLE6mNAW21oVXO85YKKAnleojxl1nnhiBdglXaqeYUo95ftuNq23gZMWAAV jxUs8E1rNGtmregHqUllDioLyqcwtkJc43OYcH/Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728334AbgBRT64 (ORCPT ); Tue, 18 Feb 2020 14:58:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:36894 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728324AbgBRT64 (ORCPT ); Tue, 18 Feb 2020 14:58:56 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D524320659; Tue, 18 Feb 2020 19:58:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055935; bh=QmdDR5zvXy6PIgNyuxthXmWql3YpnD4Coiu30lyUMZg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lzJHH1+ejCf+/Tc7XqRpp20l0Rd/jqov1XetEG6IhPqjyY9DazpPuklycpcsYOwtG CQCfrKMPBrBUYeGd5uoZMJTYVHoH7dJJyf5sexafXlpRPQ6d0sJ9S+576myuLJWqZg IwP1sPolQegwBIHYr0apSG1cVNHq4rA/+Ok+p/Ps= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sujith Pandel , David Milburn , Yi Zhang , Keith Busch , Jens Axboe Subject: [PATCH 5.4 37/66] nvme: fix the parameter order for nvme_get_log in nvme_get_fw_slot_info Date: Tue, 18 Feb 2020 20:55:04 +0100 Message-Id: <20200218190431.468890354@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Yi Zhang commit f25372ffc3f6c2684b57fb718219137e6ee2b64c upstream. nvme fw-activate operation will get bellow warning log, fix it by update the parameter order [ 113.231513] nvme nvme0: Get FW SLOT INFO log error Fixes: 0e98719b0e4b ("nvme: simplify the API for getting log pages") Reported-by: Sujith Pandel Reviewed-by: David Milburn Signed-off-by: Yi Zhang Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- drivers/nvme/host/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -3853,7 +3853,7 @@ static void nvme_get_fw_slot_info(struct if (!log) return; - if (nvme_get_log(ctrl, NVME_NSID_ALL, 0, NVME_LOG_FW_SLOT, log, + if (nvme_get_log(ctrl, NVME_NSID_ALL, NVME_LOG_FW_SLOT, 0, log, sizeof(*log), 0)) dev_warn(ctrl->device, "Get FW SLOT INFO log error\n"); kfree(log); From patchwork Tue Feb 18 19:55:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231094 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7160C34049 for ; Tue, 18 Feb 2020 20:07:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B3C2E2067D for ; Tue, 18 Feb 2020 20:07:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056451; bh=RYYN5qTMyBY+8UgtW3B8zXLXW/ynPsVz+QuTgD0qJfo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=e5NDVEzcQybcHOOkTJakwJM35oveD+D0I0wYF48z7yfF6arPuM0SupDEmJwM4006z 826TmL/nrDwPG5gDm3HE9TfdVedLDQ40mlTnxCv1XZygB0gFt6FH5iOffWTO5OxoPk giHwtnoqAiaISKDYQqBvyeOPckpHKksMUXjqYg/o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727780AbgBRT7C (ORCPT ); Tue, 18 Feb 2020 14:59:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:37078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727941AbgBRT7B (ORCPT ); Tue, 18 Feb 2020 14:59:01 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 382BD24670; Tue, 18 Feb 2020 19:59:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055940; bh=RYYN5qTMyBY+8UgtW3B8zXLXW/ynPsVz+QuTgD0qJfo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SqTfjeyHi+XqbafnW7bjPAgWstaq3BnKGRHp15YebTX9Xn5twkGE+ICPbXKvKI7ak /G3SwaZ2PHpvrIRQvj1Q35kGfxnwQZe1d906kBWZpEPmjlvasNwN9Od2zHqyJTCX/L 4996ofg+IUW6Aw5qLoZuGeOWBzCMdQn7S08LEST8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Zhang , Maor Gottlieb , Leon Romanovsky , Jason Gunthorpe Subject: [PATCH 5.4 39/66] IB/mlx5: Return failure when rts2rts_qp_counters_set_id is not supported Date: Tue, 18 Feb 2020 20:55:06 +0100 Message-Id: <20200218190431.636036146@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mark Zhang commit 10189e8e6fe8dcde13435f9354800429c4474fb1 upstream. When binding a QP with a counter and the QP state is not RESET, return failure if the rts2rts_qp_counters_set_id is not supported by the device. This is to prevent cases like manual bind for Connect-IB devices from returning success when the feature is not supported. Fixes: d14133dd4161 ("IB/mlx5: Support set qp counter") Link: https://lore.kernel.org/r/20200126171708.5167-1-leon@kernel.org Signed-off-by: Mark Zhang Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/hw/mlx5/qp.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/infiniband/hw/mlx5/qp.c +++ b/drivers/infiniband/hw/mlx5/qp.c @@ -3391,9 +3391,6 @@ static int __mlx5_ib_qp_set_counter(stru struct mlx5_ib_qp_base *base; u32 set_id; - if (!MLX5_CAP_GEN(dev->mdev, rts2rts_qp_counters_set_id)) - return 0; - if (counter) set_id = counter->id; else @@ -6503,6 +6500,7 @@ void mlx5_ib_drain_rq(struct ib_qp *qp) */ int mlx5_ib_qp_set_counter(struct ib_qp *qp, struct rdma_counter *counter) { + struct mlx5_ib_dev *dev = to_mdev(qp->device); struct mlx5_ib_qp *mqp = to_mqp(qp); int err = 0; @@ -6512,6 +6510,11 @@ int mlx5_ib_qp_set_counter(struct ib_qp goto out; } + if (!MLX5_CAP_GEN(dev->mdev, rts2rts_qp_counters_set_id)) { + err = -EOPNOTSUPP; + goto out; + } + if (mqp->state == IB_QPS_RTS) { err = __mlx5_ib_qp_set_counter(qp, counter); if (!err) From patchwork Tue Feb 18 19:55:07 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231151 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 748E0C34047 for ; Tue, 18 Feb 2020 19:59:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4EE3824676 for ; Tue, 18 Feb 2020 19:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055948; bh=D35N25K8N/+3qxxU6oWsd/VcsaIY+YrZgEa17lB9r1M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=BNUmoOdLBHtbmtkTYeeyUxAJDJo4PbImL+vv9gEuoHyaZdmrjaieytGIaIPB9Aa26 VCs2kr+P/3WgK0VpMVsovdivvIlO1e1eWrRNC5NAuVQl9TyR/zhpXVrXynroTfc6GI 7zT8vr7P+hGtyD7UmE2Xn3Vi8wwAtOpXTELnmnrk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728365AbgBRT7G (ORCPT ); Tue, 18 Feb 2020 14:59:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:37342 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728362AbgBRT7G (ORCPT ); Tue, 18 Feb 2020 14:59:06 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3511924670; Tue, 18 Feb 2020 19:59:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055945; bh=D35N25K8N/+3qxxU6oWsd/VcsaIY+YrZgEa17lB9r1M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qyQQxqazUKBSx9OZF4Pu9rxvakeWA7MrQSSAwFr17MTICyMlAJ5pt6uImYcxa+P17 ryZTlkocLoZs8gujTIJCkT7v0zUhudJyBUiwV5/npbD5iiZlFsaR280/reod8bWQT1 tKrxJ4ttLl9Z/Se0Y8/OWYL1QIfVWCFJdeI1iVWU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mike Marciniszyn , Kaike Wan , Dennis Dalessandro , Jason Gunthorpe Subject: [PATCH 5.4 40/66] IB/hfi1: Acquire lock to release TID entries when user file is closed Date: Tue, 18 Feb 2020 20:55:07 +0100 Message-Id: <20200218190431.721981574@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kaike Wan commit a70ed0f2e6262e723ae8d70accb984ba309eacc2 upstream. Each user context is allocated a certain number of RcvArray (TID) entries and these entries are managed through TID groups. These groups are put into one of three lists in each user context: tid_group_list, tid_used_list, and tid_full_list, depending on the number of used TID entries within each group. When TID packets are expected, one or more TID groups will be allocated. After the packets are received, the TID groups will be freed. Since multiple user threads may access the TID groups simultaneously, a mutex exp_mutex is used to synchronize the access. However, when the user file is closed, it tries to release all TID groups without acquiring the mutex first, which risks a race condition with another thread that may be releasing its TID groups, leading to data corruption. This patch addresses the issue by acquiring the mutex first before releasing the TID groups when the file is closed. Fixes: 3abb33ac6521 ("staging/hfi1: Add TID cache receive init and free funcs") Link: https://lore.kernel.org/r/20200210131026.87408.86853.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/hw/hfi1/user_exp_rcv.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c +++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c @@ -165,10 +165,12 @@ void hfi1_user_exp_rcv_free(struct hfi1_ if (fd->handler) { hfi1_mmu_rb_unregister(fd->handler); } else { + mutex_lock(&uctxt->exp_mutex); if (!EXP_TID_SET_EMPTY(uctxt->tid_full_list)) unlock_exp_tids(uctxt, &uctxt->tid_full_list, fd); if (!EXP_TID_SET_EMPTY(uctxt->tid_used_list)) unlock_exp_tids(uctxt, &uctxt->tid_used_list, fd); + mutex_unlock(&uctxt->exp_mutex); } kfree(fd->invalid_tids); From patchwork Tue Feb 18 19:55:08 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231095 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2006FC34026 for ; Tue, 18 Feb 2020 20:07:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DB1A722B48 for ; Tue, 18 Feb 2020 20:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056440; bh=VZaFhbyqZVjgg1Hs17nbz6lWJ5OAO/E4RIy5utauwsg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=xDPlWbFPE+i1BBJwQfFoqBgBT/8boyAcsL5mDLheV7Hi91UzxcEWsFnYwyAQze2Py USqemhCdZKbCrKTflb+MnchZPBZ2B5D59zxVigARo28CxiEKHYml0R3S+DXkJHAws+ BsFk+Qxh0T7qrrIt1fYRHMyNdVQ8djQ8u40suEjU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728373AbgBRT7J (ORCPT ); Tue, 18 Feb 2020 14:59:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:37438 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728364AbgBRT7J (ORCPT ); Tue, 18 Feb 2020 14:59:09 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ACFB424125; Tue, 18 Feb 2020 19:59:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055948; bh=VZaFhbyqZVjgg1Hs17nbz6lWJ5OAO/E4RIy5utauwsg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RTpLzEGW/fYv6r7izPTiuy4z1r4KUkWU7A9S5oC/8R0wTa1NysdDBJKnyAruUv5I0 4u21zBfuvKTVuobbHs6JvUGFzpB4DXGONBvtvxRf1QO3e5pLXNO+IEYXYsnUwpe22B vY2uEykstqoHHoeDQqNblJjFHXa1aZ9dV7SSBnAI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kaike Wan , Mike Marciniszyn , Dennis Dalessandro , Jason Gunthorpe Subject: [PATCH 5.4 41/66] IB/hfi1: Close window for pq and request coliding Date: Tue, 18 Feb 2020 20:55:08 +0100 Message-Id: <20200218190431.806057757@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Marciniszyn commit be8638344c70bf492963ace206a9896606b6922d upstream. Cleaning up a pq can result in the following warning and panic: WARNING: CPU: 52 PID: 77418 at lib/list_debug.c:53 __list_del_entry+0x63/0xd0 list_del corruption, ffff88cb2c6ac068->next is LIST_POISON1 (dead000000000100) Modules linked in: mmfs26(OE) mmfslinux(OE) tracedev(OE) 8021q garp mrp ib_isert iscsi_target_mod target_core_mod crc_t10dif crct10dif_generic opa_vnic rpcrdma ib_iser libiscsi scsi_transport_iscsi ib_ipoib(OE) bridge stp llc iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crct10dif_pclmul crct10dif_common crc32_pclmul ghash_clmulni_intel ast aesni_intel ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect sysimgblt fb_sys_fops drm pcspkr joydev lpc_ich mei_me drm_panel_orientation_quirks i2c_i801 mei wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_pad hfi1(OE) rdmavt(OE) rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_core binfmt_misc numatools(OE) xpmem(OE) ip_tables nfsv3 nfs_acl nfs lockd grace sunrpc fscache igb ahci i2c_algo_bit libahci dca ptp libata pps_core crc32c_intel [last unloaded: i2c_algo_bit] CPU: 52 PID: 77418 Comm: pvbatch Kdump: loaded Tainted: G OE ------------ 3.10.0-957.38.3.el7.x86_64 #1 Hardware name: HPE.COM HPE SGI 8600-XA730i Gen10/X11DPT-SB-SG007, BIOS SBED1229 01/22/2019 Call Trace: [] dump_stack+0x19/0x1b [] __warn+0xd8/0x100 [] warn_slowpath_fmt+0x5f/0x80 [] __list_del_entry+0x63/0xd0 [] list_del+0xd/0x30 [] kmem_cache_destroy+0x50/0x110 [] hfi1_user_sdma_free_queues+0xf0/0x200 [hfi1] [] hfi1_file_close+0x70/0x1e0 [hfi1] [] __fput+0xec/0x260 [] ____fput+0xe/0x10 [] task_work_run+0xbb/0xe0 [] do_notify_resume+0xa5/0xc0 [] int_signal+0x12/0x17 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [] kmem_cache_close+0x7e/0x300 PGD 2cdab19067 PUD 2f7bfdb067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: mmfs26(OE) mmfslinux(OE) tracedev(OE) 8021q garp mrp ib_isert iscsi_target_mod target_core_mod crc_t10dif crct10dif_generic opa_vnic rpcrdma ib_iser libiscsi scsi_transport_iscsi ib_ipoib(OE) bridge stp llc iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crct10dif_pclmul crct10dif_common crc32_pclmul ghash_clmulni_intel ast aesni_intel ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect sysimgblt fb_sys_fops drm pcspkr joydev lpc_ich mei_me drm_panel_orientation_quirks i2c_i801 mei wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_pad hfi1(OE) rdmavt(OE) rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_core binfmt_misc numatools(OE) xpmem(OE) ip_tables nfsv3 nfs_acl nfs lockd grace sunrpc fscache igb ahci i2c_algo_bit libahci dca ptp libata pps_core crc32c_intel [last unloaded: i2c_algo_bit] CPU: 52 PID: 77418 Comm: pvbatch Kdump: loaded Tainted: G W OE ------------ 3.10.0-957.38.3.el7.x86_64 #1 Hardware name: HPE.COM HPE SGI 8600-XA730i Gen10/X11DPT-SB-SG007, BIOS SBED1229 01/22/2019 task: ffff88cc26db9040 ti: ffff88b5393a8000 task.ti: ffff88b5393a8000 RIP: 0010:[] [] kmem_cache_close+0x7e/0x300 RSP: 0018:ffff88b5393abd60 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffff88cb2c6ac000 RCX: 0000000000000003 RDX: 0000000000000400 RSI: 0000000000000400 RDI: ffffffff9095b800 RBP: ffff88b5393abdb0 R08: ffffffff9095b808 R09: ffffffff8ff77c19 R10: ffff88b73ce1f160 R11: ffffddecddde9800 R12: ffff88cb2c6ac000 R13: 000000000000000c R14: ffff88cf3fdca780 R15: 0000000000000000 FS: 00002aaaaab52500(0000) GS:ffff88b73ce00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000002d27664000 CR4: 00000000007607e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: [] __kmem_cache_shutdown+0x14/0x80 [] kmem_cache_destroy+0x58/0x110 [] hfi1_user_sdma_free_queues+0xf0/0x200 [hfi1] [] hfi1_file_close+0x70/0x1e0 [hfi1] [] __fput+0xec/0x260 [] ____fput+0xe/0x10 [] task_work_run+0xbb/0xe0 [] do_notify_resume+0xa5/0xc0 [] int_signal+0x12/0x17 Code: 00 00 ba 00 04 00 00 0f 4f c2 3d 00 04 00 00 89 45 bc 0f 84 e7 01 00 00 48 63 45 bc 49 8d 04 c4 48 89 45 b0 48 8b 80 c8 00 00 00 <48> 8b 78 10 48 89 45 c0 48 83 c0 10 48 89 45 d0 48 8b 17 48 39 RIP [] kmem_cache_close+0x7e/0x300 RSP CR2: 0000000000000010 The panic is the result of slab entries being freed during the destruction of the pq slab. The code attempts to quiesce the pq, but looking for n_req == 0 doesn't account for new requests. Fix the issue by using SRCU to get a pq pointer and adjust the pq free logic to NULL the fd pq pointer prior to the quiesce. Fixes: e87473bc1b6c ("IB/hfi1: Only set fd pointer when base context is completely initialized") Link: https://lore.kernel.org/r/20200210131033.87408.81174.stgit@awfm-01.aw.intel.com Reviewed-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/hw/hfi1/file_ops.c | 52 ++++++++++++++++++------------ drivers/infiniband/hw/hfi1/hfi.h | 5 ++ drivers/infiniband/hw/hfi1/user_exp_rcv.c | 3 - drivers/infiniband/hw/hfi1/user_sdma.c | 17 ++++++--- 4 files changed, 48 insertions(+), 29 deletions(-) --- a/drivers/infiniband/hw/hfi1/file_ops.c +++ b/drivers/infiniband/hw/hfi1/file_ops.c @@ -200,23 +200,24 @@ static int hfi1_file_open(struct inode * fd = kzalloc(sizeof(*fd), GFP_KERNEL); - if (fd) { - fd->rec_cpu_num = -1; /* no cpu affinity by default */ - fd->mm = current->mm; - mmgrab(fd->mm); - fd->dd = dd; - kobject_get(&fd->dd->kobj); - fp->private_data = fd; - } else { - fp->private_data = NULL; - - if (atomic_dec_and_test(&dd->user_refcount)) - complete(&dd->user_comp); - - return -ENOMEM; - } - + if (!fd || init_srcu_struct(&fd->pq_srcu)) + goto nomem; + spin_lock_init(&fd->pq_rcu_lock); + spin_lock_init(&fd->tid_lock); + spin_lock_init(&fd->invalid_lock); + fd->rec_cpu_num = -1; /* no cpu affinity by default */ + fd->mm = current->mm; + mmgrab(fd->mm); + fd->dd = dd; + kobject_get(&fd->dd->kobj); + fp->private_data = fd; return 0; +nomem: + kfree(fd); + fp->private_data = NULL; + if (atomic_dec_and_test(&dd->user_refcount)) + complete(&dd->user_comp); + return -ENOMEM; } static long hfi1_file_ioctl(struct file *fp, unsigned int cmd, @@ -301,21 +302,30 @@ static long hfi1_file_ioctl(struct file static ssize_t hfi1_write_iter(struct kiocb *kiocb, struct iov_iter *from) { struct hfi1_filedata *fd = kiocb->ki_filp->private_data; - struct hfi1_user_sdma_pkt_q *pq = fd->pq; + struct hfi1_user_sdma_pkt_q *pq; struct hfi1_user_sdma_comp_q *cq = fd->cq; int done = 0, reqs = 0; unsigned long dim = from->nr_segs; + int idx; - if (!cq || !pq) + idx = srcu_read_lock(&fd->pq_srcu); + pq = srcu_dereference(fd->pq, &fd->pq_srcu); + if (!cq || !pq) { + srcu_read_unlock(&fd->pq_srcu, idx); return -EIO; + } - if (!iter_is_iovec(from) || !dim) + if (!iter_is_iovec(from) || !dim) { + srcu_read_unlock(&fd->pq_srcu, idx); return -EINVAL; + } trace_hfi1_sdma_request(fd->dd, fd->uctxt->ctxt, fd->subctxt, dim); - if (atomic_read(&pq->n_reqs) == pq->n_max_reqs) + if (atomic_read(&pq->n_reqs) == pq->n_max_reqs) { + srcu_read_unlock(&fd->pq_srcu, idx); return -ENOSPC; + } while (dim) { int ret; @@ -333,6 +343,7 @@ static ssize_t hfi1_write_iter(struct ki reqs++; } + srcu_read_unlock(&fd->pq_srcu, idx); return reqs; } @@ -707,6 +718,7 @@ done: if (atomic_dec_and_test(&dd->user_refcount)) complete(&dd->user_comp); + cleanup_srcu_struct(&fdata->pq_srcu); kfree(fdata); return 0; } --- a/drivers/infiniband/hw/hfi1/hfi.h +++ b/drivers/infiniband/hw/hfi1/hfi.h @@ -1436,10 +1436,13 @@ struct mmu_rb_handler; /* Private data for file operations */ struct hfi1_filedata { + struct srcu_struct pq_srcu; struct hfi1_devdata *dd; struct hfi1_ctxtdata *uctxt; struct hfi1_user_sdma_comp_q *cq; - struct hfi1_user_sdma_pkt_q *pq; + /* update side lock for SRCU */ + spinlock_t pq_rcu_lock; + struct hfi1_user_sdma_pkt_q __rcu *pq; u16 subctxt; /* for cpu affinity; -1 if none */ int rec_cpu_num; --- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c +++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c @@ -90,9 +90,6 @@ int hfi1_user_exp_rcv_init(struct hfi1_f struct hfi1_devdata *dd = uctxt->dd; int ret = 0; - spin_lock_init(&fd->tid_lock); - spin_lock_init(&fd->invalid_lock); - fd->entry_to_rb = kcalloc(uctxt->expected_count, sizeof(struct rb_node *), GFP_KERNEL); --- a/drivers/infiniband/hw/hfi1/user_sdma.c +++ b/drivers/infiniband/hw/hfi1/user_sdma.c @@ -179,7 +179,6 @@ int hfi1_user_sdma_alloc_queues(struct h pq = kzalloc(sizeof(*pq), GFP_KERNEL); if (!pq) return -ENOMEM; - pq->dd = dd; pq->ctxt = uctxt->ctxt; pq->subctxt = fd->subctxt; @@ -236,7 +235,7 @@ int hfi1_user_sdma_alloc_queues(struct h goto pq_mmu_fail; } - fd->pq = pq; + rcu_assign_pointer(fd->pq, pq); fd->cq = cq; return 0; @@ -264,8 +263,14 @@ int hfi1_user_sdma_free_queues(struct hf trace_hfi1_sdma_user_free_queues(uctxt->dd, uctxt->ctxt, fd->subctxt); - pq = fd->pq; + spin_lock(&fd->pq_rcu_lock); + pq = srcu_dereference_check(fd->pq, &fd->pq_srcu, + lockdep_is_held(&fd->pq_rcu_lock)); if (pq) { + rcu_assign_pointer(fd->pq, NULL); + spin_unlock(&fd->pq_rcu_lock); + synchronize_srcu(&fd->pq_srcu); + /* at this point there can be no more new requests */ if (pq->handler) hfi1_mmu_rb_unregister(pq->handler); iowait_sdma_drain(&pq->busy); @@ -277,7 +282,8 @@ int hfi1_user_sdma_free_queues(struct hf kfree(pq->req_in_use); kmem_cache_destroy(pq->txreq_cache); kfree(pq); - fd->pq = NULL; + } else { + spin_unlock(&fd->pq_rcu_lock); } if (fd->cq) { vfree(fd->cq->comps); @@ -321,7 +327,8 @@ int hfi1_user_sdma_process_request(struc { int ret = 0, i; struct hfi1_ctxtdata *uctxt = fd->uctxt; - struct hfi1_user_sdma_pkt_q *pq = fd->pq; + struct hfi1_user_sdma_pkt_q *pq = + srcu_dereference(fd->pq, &fd->pq_srcu); struct hfi1_user_sdma_comp_q *cq = fd->cq; struct hfi1_devdata *dd = pq->dd; unsigned long idx = 0; From patchwork Tue Feb 18 19:55:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231096 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B92BC34047 for ; Tue, 18 Feb 2020 20:07:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 44EE121D56 for ; Tue, 18 Feb 2020 20:07:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056436; bh=O9r5i8nqHSQAto/Wve6Tojb8JBvbpPLEf6XmOAKP9Mk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=pRz3q7mH/9d58yJcVRo7gWQ3aPRQYHZsrHPZXuCzEL9q1AI5udXPqxlLJ5nwUbYTw 87PpmdOGBfAW/1RtQgaXsOfV0us0kxalXmTjINEAiHiCXDRX/l4Yp3+p4BzmqJocP7 t1b6UyvnGf9HYryZYAIkGkCNpA1VFbdwG9uEx/jk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728047AbgBRT7R (ORCPT ); Tue, 18 Feb 2020 14:59:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:37608 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728385AbgBRT7N (ORCPT ); Tue, 18 Feb 2020 14:59:13 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 95E0124670; Tue, 18 Feb 2020 19:59:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055953; bh=O9r5i8nqHSQAto/Wve6Tojb8JBvbpPLEf6XmOAKP9Mk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WfY9SxpW+upfvyEsxi7Rd9qcjEXaYWCaPFNm0LK6k+zU7t+1yuxc0QVYJL9M506ug PUzTpoVykBaw+2/Sf1o1yBQgYfTRB92AnO2H0NwcgDPMExXzTzxbtLBCmUwqmn2SOj UZIwTsvcKxQN6unb/jHM0Hj/rvOI3Cw4S/CzMiJA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yonatan Cohen , Leon Romanovsky , Jason Gunthorpe Subject: [PATCH 5.4 43/66] IB/umad: Fix kernel crash while unloading ib_umad Date: Tue, 18 Feb 2020 20:55:10 +0100 Message-Id: <20200218190431.979466384@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Yonatan Cohen commit 9ea04d0df6e6541c6736b43bff45f1e54875a1db upstream. When disassociating a device from umad we must ensure that the sysfs access is prevented before blocking the fops, otherwise assumptions in syfs don't hold: CPU0 CPU1 ib_umad_kill_port() ibdev_show() port->ib_dev = NULL dev_name(port->ib_dev) The prior patch made an error in moving the device_destroy(), it should have been split into device_del() (above) and put_device() (below). At this point we already have the split, so move the device_del() back to its original place. kernel stack PF: error_code(0x0000) - not-present page Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI RIP: 0010:ibdev_show+0x18/0x50 [ib_umad] RSP: 0018:ffffc9000097fe40 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa0441120 RCX: ffff8881df514000 RDX: ffff8881df514000 RSI: ffffffffa0441120 RDI: ffff8881df1e8870 RBP: ffffffff81caf000 R08: ffff8881df1e8870 R09: 0000000000000000 R10: 0000000000001000 R11: 0000000000000003 R12: ffff88822f550b40 R13: 0000000000000001 R14: ffffc9000097ff08 R15: ffff8882238bad58 FS: 00007f1437ff3740(0000) GS:ffff888236940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000004e8 CR3: 00000001e0dfc001 CR4: 00000000001606e0 Call Trace: dev_attr_show+0x15/0x50 sysfs_kf_seq_show+0xb8/0x1a0 seq_read+0x12d/0x350 vfs_read+0x89/0x140 ksys_read+0x55/0xd0 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9: Fixes: cf7ad3030271 ("IB/umad: Avoid destroying device while it is accessed") Link: https://lore.kernel.org/r/20200212072635.682689-9-leon@kernel.org Signed-off-by: Yonatan Cohen Signed-off-by: Leon Romanovsky Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/core/user_mad.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -1312,6 +1312,9 @@ static void ib_umad_kill_port(struct ib_ struct ib_umad_file *file; int id; + cdev_device_del(&port->sm_cdev, &port->sm_dev); + cdev_device_del(&port->cdev, &port->dev); + mutex_lock(&port->file_mutex); /* Mark ib_dev NULL and block ioctl or other file ops to progress @@ -1331,8 +1334,6 @@ static void ib_umad_kill_port(struct ib_ mutex_unlock(&port->file_mutex); - cdev_device_del(&port->sm_cdev, &port->sm_dev); - cdev_device_del(&port->cdev, &port->dev); ida_free(&umad_ida, port->dev_num); /* balances device_initialize() */ From patchwork Tue Feb 18 19:55:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231097 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C9F2C34026 for ; Tue, 18 Feb 2020 20:07:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D63DB22B48 for ; Tue, 18 Feb 2020 20:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056434; bh=6DlsMtUAQvpGL98hwpqKAjqCQIqpEYmenz0309Qh9LE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=SV2WNIiVtCtry+eh7fIvg41jBO0wqFrIB0RhgWwkRKNrGPVb9CleyCluEdseUCBS0 n1wQ9+9bFKIs/wLzGBiCEzfZEyjZa9LL81QL+pZta0iCbfmquN0V34L0KMhOLG415e 0lmTPRl/sl1EW/AT8jsQ+bZE5+e20peCe6yduV/g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727184AbgBRUHK (ORCPT ); Tue, 18 Feb 2020 15:07:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:37880 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727815AbgBRT7V (ORCPT ); Tue, 18 Feb 2020 14:59:21 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E2C3E24655; Tue, 18 Feb 2020 19:59:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055961; bh=6DlsMtUAQvpGL98hwpqKAjqCQIqpEYmenz0309Qh9LE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XcTBMtq4vx2CwZ5/Rwe20tSIwbyNnR4CSneyINUhh2Xjyg+9mzgX5KXZHI6+24Nps eXeokfxO3SwiOUCKxJRuv5EtImQ8KiBqDlSPoZ0CLQzIOBYuJywpFOuiVgiTRpeLbn y13+uf4XZFp6fcvfOP2YrzAXF+YcKH5zTE1r6gWk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kamal Heib , Dennis Dalessandro , Jason Gunthorpe Subject: [PATCH 5.4 46/66] RDMA/hfi1: Fix memory leak in _dev_comp_vect_mappings_create Date: Tue, 18 Feb 2020 20:55:13 +0100 Message-Id: <20200218190432.267767795@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kamal Heib commit 8a4f300b978edbbaa73ef9eca660e45eb9f13873 upstream. Make sure to free the allocated cpumask_var_t's to avoid the following reported memory leak by kmemleak: $ cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8897f812d6a8 (size 8): comm "kworker/1:1", pid 347, jiffies 4294751400 (age 101.703s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [<00000000bff49664>] alloc_cpumask_var_node+0x4c/0xb0 [<0000000075d3ca81>] hfi1_comp_vectors_set_up+0x20f/0x800 [hfi1] [<0000000098d420df>] hfi1_init_dd+0x3311/0x4960 [hfi1] [<0000000071be7e52>] init_one+0x25e/0xf10 [hfi1] [<000000005483d4c2>] local_pci_probe+0xd4/0x180 [<000000007c3cbc6e>] work_for_cpu_fn+0x51/0xa0 [<000000001d626905>] process_one_work+0x8f0/0x17b0 [<000000007e569e7e>] worker_thread+0x536/0xb50 [<00000000fd39a4a5>] kthread+0x30c/0x3d0 [<0000000056f2edb3>] ret_from_fork+0x3a/0x50 Fixes: 5d18ee67d4c1 ("IB/{hfi1, rdmavt, qib}: Implement CQ completion vector support") Link: https://lore.kernel.org/r/20200205110530.12129-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Reviewed-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/hw/hfi1/affinity.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/hw/hfi1/affinity.c +++ b/drivers/infiniband/hw/hfi1/affinity.c @@ -479,6 +479,8 @@ static int _dev_comp_vect_mappings_creat rvt_get_ibdev_name(&(dd)->verbs_dev.rdi), i, cpu); } + free_cpumask_var(available_cpus); + free_cpumask_var(non_intr_cpus); return 0; fail: From patchwork Tue Feb 18 19:55:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231098 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2139FC34026 for ; Tue, 18 Feb 2020 20:07:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA3BA21D56 for ; Tue, 18 Feb 2020 20:07:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056425; bh=lutRwWS5W6gYIXHi+dRkJ/tOgWhUnRLe5E0U6N0S5Ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=q71/apHtapqd4utinyDCGU3tlkmXBsECInVJW9OvBdFaTOUekIO6OPvXk4XMLLNyC UtIhtm9WiA/av8JEvVEgecLLOehRnbMMsX1xkGIkT8DJhRqiuZSzxLyjKiJ8XoMRYU HuPh7q2wGprdSkVmWiDAsTrfrNf8eogxk89/f0sU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726401AbgBRUHE (ORCPT ); Tue, 18 Feb 2020 15:07:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:38032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727662AbgBRT71 (ORCPT ); Tue, 18 Feb 2020 14:59:27 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C353124655; Tue, 18 Feb 2020 19:59:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055966; bh=lutRwWS5W6gYIXHi+dRkJ/tOgWhUnRLe5E0U6N0S5Ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e0qzvQ5ZiMHGUA0addeCAJ48aoikomkfkMzX6qnoj5tWH+tOd69bcygNq+W9M54B5 E4dOcs3KAGHNpePEv6K5V+A95d+BQPXcYuMNfomQSXiglcs12HWbKPYF55D9PvvX8U nrYDjtDb6FxzB/RBZMzIfU/YLOw2jsYBoNclBh6c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maor Gottlieb , Leon Romanovsky Subject: [PATCH 5.4 48/66] RDMA/core: Fix protection fault in get_pkey_idx_qp_list Date: Tue, 18 Feb 2020 20:55:15 +0100 Message-Id: <20200218190432.467397153@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Leon Romanovsky commit 1dd017882e01d2fcd9c5dbbf1eb376211111c393 upstream. We don't need to set pkey as valid in case that user set only one of pkey index or port number, otherwise it will be resulted in NULL pointer dereference while accessing to uninitialized pkey list. The following crash from Syzkaller revealed it. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 14753 Comm: syz-executor.2 Not tainted 5.5.0-rc5 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:get_pkey_idx_qp_list+0x161/0x2d0 Code: 01 00 00 49 8b 5e 20 4c 39 e3 0f 84 b9 00 00 00 e8 e4 42 6e fe 48 8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 01 0f 8e d0 00 00 00 48 8d 7d 04 48 b8 RSP: 0018:ffffc9000bc6f950 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff82c8bdec RDX: 0000000000000002 RSI: ffffc900030a8000 RDI: 0000000000000010 RBP: ffff888112c8ce80 R08: 0000000000000004 R09: fffff5200178df1f R10: 0000000000000001 R11: fffff5200178df1f R12: ffff888115dc4430 R13: ffff888115da8498 R14: ffff888115dc4410 R15: ffff888115da8000 FS: 00007f20777de700(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2f721000 CR3: 00000001173ca002 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: port_pkey_list_insert+0xd7/0x7c0 ib_security_modify_qp+0x6fa/0xfc0 _ib_modify_qp+0x8c4/0xbf0 modify_qp+0x10da/0x16d0 ib_uverbs_modify_qp+0x9a/0x100 ib_uverbs_write+0xaa5/0xdf0 __vfs_write+0x7c/0x100 vfs_write+0x168/0x4a0 ksys_write+0xc8/0x200 do_syscall_64+0x9c/0x390 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: d291f1a65232 ("IB/core: Enforce PKey security on QPs") Link: https://lore.kernel.org/r/20200212080651.GB679970@unreal Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Message-Id: <20200212080651.GB679970@unreal> Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/core/security.c | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) --- a/drivers/infiniband/core/security.c +++ b/drivers/infiniband/core/security.c @@ -339,22 +339,16 @@ static struct ib_ports_pkeys *get_new_pp if (!new_pps) return NULL; - if (qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) { - if (!qp_pps) { - new_pps->main.port_num = qp_attr->port_num; - new_pps->main.pkey_index = qp_attr->pkey_index; - } else { - new_pps->main.port_num = (qp_attr_mask & IB_QP_PORT) ? - qp_attr->port_num : - qp_pps->main.port_num; - - new_pps->main.pkey_index = - (qp_attr_mask & IB_QP_PKEY_INDEX) ? - qp_attr->pkey_index : - qp_pps->main.pkey_index; - } + if (qp_attr_mask & IB_QP_PORT) + new_pps->main.port_num = + (qp_pps) ? qp_pps->main.port_num : qp_attr->port_num; + if (qp_attr_mask & IB_QP_PKEY_INDEX) + new_pps->main.pkey_index = (qp_pps) ? qp_pps->main.pkey_index : + qp_attr->pkey_index; + if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask & IB_QP_PORT)) new_pps->main.state = IB_PORT_PKEY_VALID; - } else if (qp_pps) { + + if (!(qp_attr_mask & (IB_QP_PKEY_INDEX || IB_QP_PORT)) && qp_pps) { new_pps->main.port_num = qp_pps->main.port_num; new_pps->main.pkey_index = qp_pps->main.pkey_index; if (qp_pps->main.state != IB_PORT_PKEY_NOT_VALID) From patchwork Tue Feb 18 19:55:18 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231149 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AF9EC34047 for ; Tue, 18 Feb 2020 19:59:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 115A224125 for ; Tue, 18 Feb 2020 19:59:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055993; bh=KDjerKczOZHWwPnuBGNxgXOG0D9QiJQCmyfpxvInpYo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=JkuavL7SQov/GxMcnBeSjVUZaPWaUQWhb8LtgIwtViAtDvgkbthGdtFqpxyok51Ta anGq6geHOFT0cFTVM/0dV1y93oTa+9GD91CNYGiXMDq6jM7plk113clwkBmDtcaeJ8 4fzrdh3P3ycB27tscoHENQ/pxr3F74EnyPktKovc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727668AbgBRT7v (ORCPT ); Tue, 18 Feb 2020 14:59:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:38722 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728483AbgBRT7u (ORCPT ); Tue, 18 Feb 2020 14:59:50 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EB1072464E; Tue, 18 Feb 2020 19:59:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055989; bh=KDjerKczOZHWwPnuBGNxgXOG0D9QiJQCmyfpxvInpYo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tOtbGxPjdKhJeRJh5hreSYAfyyVGSpXTYcffSic8TIGxPoJjrqJeVEslpUoKfl9/b W8TnXGLwUjLTpVaRvHNMKmwuyQNB0GoLdvzhZpfrvyGa6zJkk+8LXItK0tgKpCNJuA owOVZaW3/Xtukmd+wPRb4Pl47mmXByT4/tiyBiq4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Douglas Anderson , Brian Masney , Lina Iyer , Maulik Shah , Bjorn Andersson , Stephen Boyd , Linus Walleij Subject: [PATCH 5.4 51/66] spmi: pmic-arb: Set lockdep class for hierarchical irq domains Date: Tue, 18 Feb 2020 20:55:18 +0100 Message-Id: <20200218190432.763926947@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Stephen Boyd commit 2d5a2f913b658a7ae984773a63318ed4daadf4af upstream. I see the following lockdep splat in the qcom pinctrl driver when attempting to suspend the device. WARNING: possible recursive locking detected 5.4.11 #3 Tainted: G W -------------------------------------------- cat/3074 is trying to acquire lock: ffffff81f49804c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 but task is already holding lock: ffffff81f1cc10c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by cat/3074: #0: ffffff81f01d9420 (sb_writers#7){.+.+}, at: vfs_write+0xd0/0x1a4 #1: ffffff81bd7d2080 (&of->mutex){+.+.}, at: kernfs_fop_write+0x12c/0x1fc #2: ffffff81f4c322f0 (kn->count#337){.+.+}, at: kernfs_fop_write+0x134/0x1fc #3: ffffffe411a41d60 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x348 #4: ffffff81f1c5e970 (&dev->mutex){....}, at: __device_suspend+0x168/0x41c #5: ffffff81f1cc10c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 stack backtrace: CPU: 5 PID: 3074 Comm: cat Tainted: G W 5.4.11 #3 Hardware name: Google Cheza (rev3+) (DT) Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xc8/0x124 __lock_acquire+0x460/0x2388 lock_acquire+0x1cc/0x210 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 qpnpint_irq_set_wake+0x28/0x34 set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 pm8941_pwrkey_suspend+0x34/0x44 platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x310/0x41c dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x620 pm_suspend+0x210/0x348 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x15c/0x1fc __vfs_write+0x54/0x18c vfs_write+0xe4/0x1a4 ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_handler+0x7c/0x98 el0_svc+0x8/0xc Set a lockdep class when we map the irq so that irq_set_wake() doesn't warn about a lockdep bug that doesn't exist. Fixes: 12a9eeaebba3 ("spmi: pmic-arb: convert to v2 irq interfaces to support hierarchical IRQ chips") Cc: Douglas Anderson Cc: Brian Masney Cc: Lina Iyer Cc: Maulik Shah Cc: Bjorn Andersson Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20200121183748.68662-1-swboyd@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman --- drivers/spmi/spmi-pmic-arb.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/spmi/spmi-pmic-arb.c +++ b/drivers/spmi/spmi-pmic-arb.c @@ -731,6 +731,7 @@ static int qpnpint_irq_domain_translate( return 0; } +static struct lock_class_key qpnpint_irq_lock_class, qpnpint_irq_request_class; static void qpnpint_irq_domain_map(struct spmi_pmic_arb *pmic_arb, struct irq_domain *domain, unsigned int virq, @@ -746,6 +747,9 @@ static void qpnpint_irq_domain_map(struc else handler = handle_level_irq; + + irq_set_lockdep_class(virq, &qpnpint_irq_lock_class, + &qpnpint_irq_request_class); irq_domain_set_info(domain, virq, hwirq, &pmic_arb_irqchip, pmic_arb, handler, NULL, NULL); } From patchwork Tue Feb 18 19:55:19 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231147 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AD4DC34026 for ; Tue, 18 Feb 2020 20:00:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E614024655 for ; Tue, 18 Feb 2020 20:00:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056012; bh=wAdqqFi0pp9/8Gp8KwrMsD1sYSgVs/A5mAIDtyCLqwg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=tZzlkoK8KxMbmy/Ke42gGURKyvHKl2gEjtq184PcQ4K8cM39VO37JhMv6sExUXdSs qIlzc3hx6k8SNR4vjWsKSgeJR7uPzWhYopsWI6rcqm4Ej2SBdlt9x7n6V1fQM6Xswh zI2ZG9QF8IL1NZGjBeWTHmogRN95/vhCTzRUptCg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728299AbgBRUAL (ORCPT ); Tue, 18 Feb 2020 15:00:11 -0500 Received: from mail.kernel.org ([198.145.29.99]:39276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728286AbgBRUAK (ORCPT ); Tue, 18 Feb 2020 15:00:10 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9AE8424125; Tue, 18 Feb 2020 20:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056010; bh=wAdqqFi0pp9/8Gp8KwrMsD1sYSgVs/A5mAIDtyCLqwg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C8C2+HZLQU+ku5DKTjUe/SZ82C9+dNg5ZpxctsK1qTylvHwW/umCaSNhUxytnrNdg c0oTvrmGH6TuVeXoedQDiaTcJJEj+q6RQjX9f2v9PN7a23syqZecGsLUlzJ38L0F92 zpzLklOaL3jh+MX8Z58/wOWmPskyn/gZ1tIP87W8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kan Liang , "Peter Zijlstra (Intel)" , Ingo Molnar Subject: [PATCH 5.4 52/66] perf/x86/intel: Fix inaccurate period in context switch for auto-reload Date: Tue, 18 Feb 2020 20:55:19 +0100 Message-Id: <20200218190432.866086714@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kan Liang commit f861854e1b435b27197417f6f90d87188003cb24 upstream. Perf doesn't take the left period into account when auto-reload is enabled with fixed period sampling mode in context switch. Here is the MSR trace of the perf command as below. (The MSR trace is simplified from a ftrace log.) #perf record -e cycles:p -c 2000000 -- ./triad_loop //The MSR trace of task schedule out //perf disable all counters, disable PEBS, disable GP counter 0, //read GP counter 0, and re-enable all counters. //The counter 0 stops at 0xfffffff82840 write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 0 write_msr: MSR_IA32_PEBS_ENABLE(3f1), value 0 write_msr: MSR_P6_EVNTSEL0(186), value 40003003c rdpmc: 0, value fffffff82840 write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value f000000ff //The MSR trace of the same task schedule in again //perf disable all counters, enable and set GP counter 0, //enable PEBS, and re-enable all counters. //0xffffffe17b80 (-2000000) is written to GP counter 0. write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 0 write_msr: MSR_IA32_PMC0(4c1), value ffffffe17b80 write_msr: MSR_P6_EVNTSEL0(186), value 40043003c write_msr: MSR_IA32_PEBS_ENABLE(3f1), value 1 write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value f000000ff When the same task schedule in again, the counter should starts from previous left. However, it starts from the fixed period -2000000 again. A special variant of intel_pmu_save_and_restart() is used for auto-reload, which doesn't update the hwc->period_left. When the monitored task schedules in again, perf doesn't know the left period. The fixed period is used, which is inaccurate. With auto-reload, the counter always has a negative counter value. So the left period is -value. Update the period_left in intel_pmu_save_and_restart_reload(). With the patch: //The MSR trace of task schedule out write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 0 write_msr: MSR_IA32_PEBS_ENABLE(3f1), value 0 write_msr: MSR_P6_EVNTSEL0(186), value 40003003c rdpmc: 0, value ffffffe25cbc write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value f000000ff //The MSR trace of the same task schedule in again write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 0 write_msr: MSR_IA32_PMC0(4c1), value ffffffe25cbc write_msr: MSR_P6_EVNTSEL0(186), value 40043003c write_msr: MSR_IA32_PEBS_ENABLE(3f1), value 1 write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value f000000ff Fixes: d31fc13fdcb2 ("perf/x86/intel: Fix event update for auto-reload") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20200121190125.3389-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman --- arch/x86/events/intel/ds.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1713,6 +1713,8 @@ intel_pmu_save_and_restart_reload(struct old = ((s64)(prev_raw_count << shift) >> shift); local64_add(new - old + count * period, &event->count); + local64_set(&hwc->period_left, -new); + perf_event_update_userpage(event); return 0; From patchwork Tue Feb 18 19:55:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231103 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C80F5C34026 for ; Tue, 18 Feb 2020 20:06:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93E0B22B48 for ; Tue, 18 Feb 2020 20:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056400; bh=us2hgAvUzqAPptOOCH7doagG3AK8HtWXYp9L9PEzMC8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=pTa28LUeNOhgHv+HsIIJwvD6+dU6ynhSwcR3wwfqvm7/cswcUPz8UQjGFgtsygUs/ +mNCzXkc2Zg6swUkD/ssHNZbXDBvZ4Hh3eINi1GSCcnoJYCndb4qtxMtoivMQxFpl5 oLOJSegFlwJA2cjFJgNw9JEWNsX/Ozq0QwmlZxzA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727103AbgBRUAN (ORCPT ); Tue, 18 Feb 2020 15:00:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:39358 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726620AbgBRUAN (ORCPT ); Tue, 18 Feb 2020 15:00:13 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 11E8824677; Tue, 18 Feb 2020 20:00:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056012; bh=us2hgAvUzqAPptOOCH7doagG3AK8HtWXYp9L9PEzMC8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cxQZM8x+j4+PWPB72yarVCbMEsmrmYHCEBolDRB+d1RjQGPlxu2qshYDbX0kdb0Xy uXQ1InjEUL+q7PmEHu50nwlO2rrRlphHiyhGsC0MRgomx+nsumJe3Wy9+8Tbhc+pD6 Ewlq9N+aJl3ya2t+3BwMy9dX5EyBuqvZxtO4Ty3c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mike Jones , Guenter Roeck Subject: [PATCH 5.4 53/66] hwmon: (pmbus/ltc2978) Fix PMBus polling of MFR_COMMON definitions. Date: Tue, 18 Feb 2020 20:55:20 +0100 Message-Id: <20200218190432.966572221@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Jones commit cf2b012c90e74e85d8aea7d67e48868069cfee0c upstream. Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to bits 6/5. This fixs a LTC297X family bug where polling always returns not busy even when the part is busy. This fixes a LTC388X and LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY was not polled, which can lead to NACKing of commands. LTC388X and LTM467X modules now poll BUSY and PEND, increasing reliability by eliminating NACKing of commands. Signed-off-by: Mike Jones Link: https://lore.kernel.org/r/1580234400-2829-2-git-send-email-michael-a1.jones@analog.com Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman --- drivers/hwmon/pmbus/ltc2978.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/hwmon/pmbus/ltc2978.c +++ b/drivers/hwmon/pmbus/ltc2978.c @@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, #define LTC_POLL_TIMEOUT 100 /* in milli-seconds */ -#define LTC_NOT_BUSY BIT(5) -#define LTC_NOT_PENDING BIT(4) +#define LTC_NOT_BUSY BIT(6) +#define LTC_NOT_PENDING BIT(5) /* * LTC2978 clears peak data whenever the CLEAR_FAULTS command is executed, which From patchwork Tue Feb 18 19:55:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231146 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB599C34026 for ; Tue, 18 Feb 2020 20:00:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF4F624655 for ; Tue, 18 Feb 2020 20:00:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056016; bh=yaJiDeQSI2EMCSVNMIN7LeAM+k+7UbmGAwh6/ahZFPk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=bt+shivAvbMBz4TqByVJNVuCuOgwdFSMWQizKdVsJwUSUr0keY497qoY9mldCT/m0 JEuvzz+kK6bm+m3JSgxR8pNOVJjV68zPmhe7n4Cx/kVRDRJfygAkThSvpAgYsTbFKs zjyETGVvyeM3L53ddj7O5xbp8zlhmj2W6tJYxUF0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728537AbgBRUAQ (ORCPT ); Tue, 18 Feb 2020 15:00:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:39424 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727462AbgBRUAP (ORCPT ); Tue, 18 Feb 2020 15:00:15 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 85FB824655; Tue, 18 Feb 2020 20:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056015; bh=yaJiDeQSI2EMCSVNMIN7LeAM+k+7UbmGAwh6/ahZFPk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MS99XP2ApjmfJMQLGU+ALPmHZ1/AJCK/wtjeIl08sL/A4uvwFuPuQQaC/QFGDZorD 0OaEfhtQS59hVB04o3xCXEOJriGE+/hUJlucifDsMS8OTxlvKbyMdU9aPlxGGy/1Vm xMFDAnHGjIImj9gOgrCtTf7nqWCeVOCsHKlfijps= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sara Sharon , Luca Coelho , Johannes Berg Subject: [PATCH 5.4 54/66] mac80211: fix quiet mode activation in action frames Date: Tue, 18 Feb 2020 20:55:21 +0100 Message-Id: <20200218190433.068096153@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sara Sharon commit 2bf973ff9b9aeceb8acda629ae65341820d4b35b upstream. Previously I intended to ignore quiet mode in probe response, however I ended up ignoring it instead for action frames. As a matter of fact, this path isn't invoked for probe responses to start with. Just revert this patch. Signed-off-by: Sara Sharon Fixes: 7976b1e9e3bf ("mac80211: ignore quiet mode in probe") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/20200131111300.891737-15-luca@coelho.fi Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- net/mac80211/mlme.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -8,7 +8,7 @@ * Copyright 2007, Michael Wu * Copyright 2013-2014 Intel Mobile Communications GmbH * Copyright (C) 2015 - 2017 Intel Deutschland GmbH - * Copyright (C) 2018 - 2019 Intel Corporation + * Copyright (C) 2018 - 2020 Intel Corporation */ #include @@ -1311,7 +1311,7 @@ ieee80211_sta_process_chanswitch(struct if (!res) { ch_switch.timestamp = timestamp; ch_switch.device_timestamp = device_timestamp; - ch_switch.block_tx = beacon ? csa_ie.mode : 0; + ch_switch.block_tx = csa_ie.mode; ch_switch.chandef = csa_ie.chandef; ch_switch.count = csa_ie.count; ch_switch.delay = csa_ie.max_switch_time; @@ -1404,7 +1404,7 @@ ieee80211_sta_process_chanswitch(struct sdata->vif.csa_active = true; sdata->csa_chandef = csa_ie.chandef; - sdata->csa_block_tx = ch_switch.block_tx; + sdata->csa_block_tx = csa_ie.mode; ifmgd->csa_ignored_same_chan = false; if (sdata->csa_block_tx) @@ -1438,7 +1438,7 @@ ieee80211_sta_process_chanswitch(struct * reset when the disconnection worker runs. */ sdata->vif.csa_active = true; - sdata->csa_block_tx = ch_switch.block_tx; + sdata->csa_block_tx = csa_ie.mode; ieee80211_queue_work(&local->hw, &ifmgd->csa_connection_drop_work); mutex_unlock(&local->chanctx_mtx); From patchwork Tue Feb 18 19:55:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231104 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2064CC34049 for ; Tue, 18 Feb 2020 20:06:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E37C324125 for ; Tue, 18 Feb 2020 20:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056395; bh=vnKENgL2erzlXMxnhaMBf4SD/3+ntQcfdelWp6Lmqck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=P5NHalh/xMeu+Vy3mb/sJYJpUiuLRgBnuTbrXyP3/uBMkuvFC7lpJb4VdVnruAMLD UVRQf3zh+cyQsMZDr1efud4e0jpaOP9zEx8nwqkxr4qYviDJmqELqJUPmh+R0CYUsq j7FaRvsc/klmvWPL3dd+KVgL36i8e4LTUaPbZhj8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728569AbgBRUAV (ORCPT ); Tue, 18 Feb 2020 15:00:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:39502 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728563AbgBRUAU (ORCPT ); Tue, 18 Feb 2020 15:00:20 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7D2122465A; Tue, 18 Feb 2020 20:00:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056020; bh=vnKENgL2erzlXMxnhaMBf4SD/3+ntQcfdelWp6Lmqck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MtI5q0mvUOIAEKaQA2Bwn4e2+CXTlfjHUeuifQezfYWCxWR0r9dwkGt9DHuKkZtyD JD/vXGvyR4/o2iGfwNUnePrMy1gHifgY843B8NVBmyWI2plk11ORWihlGB/lMUJjcf 0noESdoTjEEEo/q0sdgSz+VpvQed/ESLyFXdGo3Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Zyngier , Sudeep Holla Subject: [PATCH 5.4 56/66] arm64: dts: fast models: Fix FVP PCI interrupt-map property Date: Tue, 18 Feb 2020 20:55:23 +0100 Message-Id: <20200218190433.259761685@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Marc Zyngier commit 3543d7ddd55fe12c37e8a9db846216c51846015b upstream. The interrupt map for the FVP's PCI node is missing the parent-unit-address cells for each of the INTx entries, leading to the kernel code failing to parse the entries correctly. Add the missing zero cells, which are pretty useless as far as the GIC is concerned, but that the spec requires. This allows INTx to be usable on the model, and VFIO to work correctly. Fixes: fa083b99eb28 ("arm64: dts: fast models: Add DTS fo Base RevC FVP") Signed-off-by: Marc Zyngier Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman --- arch/arm64/boot/dts/arm/fvp-base-revc.dts | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts +++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts @@ -161,10 +161,10 @@ bus-range = <0x0 0x1>; reg = <0x0 0x40000000 0x0 0x10000000>; ranges = <0x2000000 0x0 0x50000000 0x0 0x50000000 0x0 0x10000000>; - interrupt-map = <0 0 0 1 &gic GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 2 &gic GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 3 &gic GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 4 &gic GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>; + interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &gic 0 0 GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &gic 0 0 GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &gic 0 0 GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; msi-map = <0x0 &its 0x0 0x10000>; iommu-map = <0x0 &smmu 0x0 0x10000>; From patchwork Tue Feb 18 19:55:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231105 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05A04C34049 for ; Tue, 18 Feb 2020 20:06:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB14922B48 for ; Tue, 18 Feb 2020 20:06:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056391; bh=mgL7HSGN6Ip5HwbugGrUQYfFeYcitgxBsLwi6J77rxo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Mbb0xBJWklumsbZkXRNjPKNPXKKce7Shc+aogJP87uwxdrfbKbE4PIU30IAlc78Rj MotlRGOOhY7YewBkVyPwjm6PjmDiLl9dtmeUO1t3FX1sYnuB3qVU8lIWmPIoXAFd+g SI2yBfVDG4o85g1fRbO5nrIppE3RYhJpRKp8IZ/I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728593AbgBRUA2 (ORCPT ); Tue, 18 Feb 2020 15:00:28 -0500 Received: from mail.kernel.org ([198.145.29.99]:39720 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728590AbgBRUA2 (ORCPT ); Tue, 18 Feb 2020 15:00:28 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 155F82464E; Tue, 18 Feb 2020 20:00:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056027; bh=mgL7HSGN6Ip5HwbugGrUQYfFeYcitgxBsLwi6J77rxo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oi+6oVhCyf1n74NhQBJyAfuV08sgL68hji/1NjAbGUStfg5dEMv/QVSVN3RXkKtQd 4I5tVBDI45Y+x9l7ai8OZTJlAYYGwahIUu70h2wsezC0yVWLizpX7FUEWmurAiEoZM stJ+ESXitc3wXVw4ZGN77pbEjzPkP6bYjzRo7qAY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Olga Kornievskaia , Trond Myklebust , Anna Schumaker Subject: [PATCH 5.4 59/66] NFSv4.1 make cachethis=no for writes Date: Tue, 18 Feb 2020 20:55:26 +0100 Message-Id: <20200218190433.535496148@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Olga Kornievskaia commit cd1b659d8ce7697ee9799b64f887528315b9097b upstream. Turning caching off for writes on the server should improve performance. Fixes: fba83f34119a ("NFS: Pass "privileged" value to nfs4_init_sequence()") Signed-off-by: Olga Kornievskaia Reviewed-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman --- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -5293,7 +5293,7 @@ static void nfs4_proc_write_setup(struct hdr->timestamp = jiffies; msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_WRITE]; - nfs4_init_sequence(&hdr->args.seq_args, &hdr->res.seq_res, 1, 0); + nfs4_init_sequence(&hdr->args.seq_args, &hdr->res.seq_res, 0, 0); nfs4_state_protect_write(server->nfs_client, clnt, msg, hdr); } From patchwork Tue Feb 18 19:55:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231102 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C70F9C34047 for ; Tue, 18 Feb 2020 20:06:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9756421D56 for ; Tue, 18 Feb 2020 20:06:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056407; bh=DtG1klsFYIJX4cADiDULKjR/ydcpU3huW4ineSvRNjg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=HykRrJq1J8Sf+j3JrXYg30P6MCUN6AZBMx1pgWNjYDiwlSWPCao9ce/PbmRZViV87 GE48d8UBcImbrncxDNCw8IXU8VZEQrVTyPlllokhOPPQdYkavVjFhnF3s66QsBko6z N67OGx+93Z6su0okx5GzBWFwdrCijSZ6YSmVNwyc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726571AbgBRT7z (ORCPT ); Tue, 18 Feb 2020 14:59:55 -0500 Received: from mail.kernel.org ([198.145.29.99]:38800 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726557AbgBRT7w (ORCPT ); Tue, 18 Feb 2020 14:59:52 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6ED3920659; Tue, 18 Feb 2020 19:59:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582055991; bh=DtG1klsFYIJX4cADiDULKjR/ydcpU3huW4ineSvRNjg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pgBhDxdAoNJ7x7B2YJEvD/cXQp7D+PoRV23dl/4mjAq5JJDeM6t2t8CxxUhkZqjx6 dDJVzUL8x4cbUVzDvV9wRJt/ZyoITGRA9sSZ9DybY7gZYRRHlR+o3T1rVKO/G3AYGO uyPBH6ryLw6NNAvKKEQnlVy1umvqsqbgq+KK8oZw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jernej Skrabec , Paul Kocialkowski , Maxime Ripard Subject: [PATCH 5.4 60/66] Revert "drm/sun4i: drv: Allow framebuffer modifiers in mode config" Date: Tue, 18 Feb 2020 20:55:27 +0100 Message-Id: <20200218190433.633379307@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Jernej Skrabec commit cf913e9683273f2640501094fa63a67e29f437b3 upstream. This reverts commit 9db9c0cf5895e4ddde2814360cae7bea9282edd2. Setting mode_config.allow_fb_modifiers manually is completely unnecessary. It is set automatically by drm_universal_plane_init() based on the fact if modifier list is provided or not. Even more, it breaks DE2 and DE3 as they don't support any modifiers beside linear. Modifiers aware applications can be confused by provided empty modifier list - at least linear modifier should be included, but it's not for DE2 and DE3. Fixes: 9db9c0cf5895 ("drm/sun4i: drv: Allow framebuffer modifiers in mode config") Signed-off-by: Jernej Skrabec Reviewed-by: Paul Kocialkowski Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200126065937.9564-1-jernej.skrabec@siol.net Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c @@ -85,7 +85,6 @@ static int sun4i_drv_bind(struct device } drm_mode_config_init(drm); - drm->mode_config.allow_fb_modifiers = true; ret = component_bind_all(drm->dev, drm); if (ret) { From patchwork Tue Feb 18 19:55:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 231148 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A82EC34049 for ; Tue, 18 Feb 2020 20:00:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5138A24676 for ; Tue, 18 Feb 2020 20:00:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056004; bh=0jem6XZ66gE+dB+u/Ocyu8cRj6OtJjD6/+Lb9cXcejI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=cVisg8lVRQ6CB09GqX2l3ASrdtvuIwlzYA5F70lipi+HFhZzCnqva5Hf4xX6XeWj+ FAwBp+pZVSQ1BaAIQUVmMeMWROlhF7kGpvy6JacZSA7N0OfpPuCDg6TbtAfY33xVvS 5eAT/45pCHzrYCp8MP2+q85vm/3cOwO3e5ijXW24= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727999AbgBRUAD (ORCPT ); Tue, 18 Feb 2020 15:00:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:39066 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728228AbgBRUAC (ORCPT ); Tue, 18 Feb 2020 15:00:02 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A872F20659; Tue, 18 Feb 2020 20:00:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582056002; bh=0jem6XZ66gE+dB+u/Ocyu8cRj6OtJjD6/+Lb9cXcejI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kg7SFLSXQe6HBoeXWXahGLoCjtivhA7yFUAELrg+dE8wLl7u0KEfg143dMPCAFLT+ vEzuOjkWx9EB+6iSB13/fcaG8jCt4e0mG/CmNohHu/nPPjJavSUw08yYg528e1T8D3 9QQoC6ejhxB+ODRUt30FnD+BehiEeZ1oXeKX0jFA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sean Christopherson , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.4 64/66] KVM: x86/mmu: Fix struct guest_walker arrays for 5-level paging Date: Tue, 18 Feb 2020 20:55:31 +0100 Message-Id: <20200218190434.149508774@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200218190428.035153861@linuxfoundation.org> References: <20200218190428.035153861@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sean Christopherson [ Upstream commit f6ab0107a4942dbf9a5cf0cca3f37e184870a360 ] Define PT_MAX_FULL_LEVELS as PT64_ROOT_MAX_LEVEL, i.e. 5, to fix shadow paging for 5-level guest page tables. PT_MAX_FULL_LEVELS is used to size the arrays that track guest pages table information, i.e. using a "max levels" of 4 causes KVM to access garbage beyond the end of an array when querying state for level 5 entries. E.g. FNAME(gpte_changed) will read garbage and most likely return %true for a level 5 entry, soft-hanging the guest because FNAME(fetch) will restart the guest instead of creating SPTEs because it thinks the guest PTE has changed. Note, KVM doesn't yet support 5-level nested EPT, so PT_MAX_FULL_LEVELS gets to stay "4" for the PTTYPE_EPT case. Fixes: 855feb673640 ("KVM: MMU: Add 5 level EPT & Shadow page table support.") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- arch/x86/kvm/paging_tmpl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index c1d7b866a03fa..4e3f137ffa8c8 100644 --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -33,7 +33,7 @@ #define PT_GUEST_ACCESSED_SHIFT PT_ACCESSED_SHIFT #define PT_HAVE_ACCESSED_DIRTY(mmu) true #ifdef CONFIG_X86_64 - #define PT_MAX_FULL_LEVELS 4 + #define PT_MAX_FULL_LEVELS PT64_ROOT_MAX_LEVEL #define CMPXCHG cmpxchg #else #define CMPXCHG cmpxchg64