From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA34EC19F2D for ; Tue, 9 Aug 2022 18:20:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343527AbiHIST7 (ORCPT ); Tue, 9 Aug 2022 14:19:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346565AbiHISRJ (ORCPT ); Tue, 9 Aug 2022 14:17:09 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 404822E691; Tue, 9 Aug 2022 11:06:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 18CD5B818C9; Tue, 9 Aug 2022 18:06:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67F3DC433D7; Tue, 9 Aug 2022 18:06:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068375; bh=Hw4pzzLd0H6uAutoVrmjO0vf0SfnwAPU/bjzRGD23m8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EUINnB7pTBUYBOGDmi7LyrU273Qs4WXjemDo5lYfQ6fm5go8qSToulVECC0dRGtsm oqmasT/LJdjcqV5eBkAMtPneM6u/j7CLfDNS9zXGu12F+kAy+ITZZui8t6QjDpAM9H 0qomcptbwSDWJer5L81q4go9rLVkzAcnku0nJwd4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ben Hutchings , Borislav Petkov Subject: [PATCH 5.18 01/35] x86/speculation: Make all RETbleed mitigations 64-bit only Date: Tue, 9 Aug 2022 20:00:30 +0200 Message-Id: <20220809175515.095853601@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ben Hutchings commit b648ab487f31bc4c38941bc770ea97fe394304bb upstream. The mitigations for RETBleed are currently ineffective on x86_32 since entry_32.S does not use the required macros. However, for an x86_32 target, the kconfig symbols for them are still enabled by default and /sys/devices/system/cpu/vulnerabilities/retbleed will wrongly report that mitigations are in place. Make all of these symbols depend on X86_64, and only enable RETHUNK by default on X86_64. Fixes: f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs") Signed-off-by: Ben Hutchings Signed-off-by: Borislav Petkov Cc: Link: https://lore.kernel.org/r/YtwSR3NNsWp1ohfV@decadent.org.uk [bwh: Backported to 5.10/5.15/5.18: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/Kconfig | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2469,7 +2469,7 @@ config RETPOLINE config RETHUNK bool "Enable return-thunks" depends on RETPOLINE && CC_HAS_RETURN_THUNK - default y + default y if X86_64 help Compile the kernel with the return-thunks compiler option to guard against kernel-to-user data leaks by avoiding return speculation. @@ -2478,21 +2478,21 @@ config RETHUNK =20 config CPU_UNRET_ENTRY bool "Enable UNRET on kernel entry" - depends on CPU_SUP_AMD && RETHUNK + depends on CPU_SUP_AMD && RETHUNK && X86_64 default y help Compile the kernel with support for the retbleed=3Dunret mitigation. =20 config CPU_IBPB_ENTRY bool "Enable IBPB on kernel entry" - depends on CPU_SUP_AMD + depends on CPU_SUP_AMD && X86_64 default y help Compile the kernel with support for the retbleed=3Dibpb mitigation. =20 config CPU_IBRS_ENTRY bool "Enable IBRS on kernel entry" - depends on CPU_SUP_INTEL + depends on CPU_SUP_INTEL && X86_64 default y help Compile the kernel with support for the spectre_v2=3Dibrs mitigation. From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44530C25B0E for ; Tue, 9 Aug 2022 18:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346284AbiHISVC (ORCPT ); Tue, 9 Aug 2022 14:21:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346823AbiHISRt (ORCPT ); Tue, 9 Aug 2022 14:17:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E45A42ED42; Tue, 9 Aug 2022 11:06:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 645C5B818B7; Tue, 9 Aug 2022 18:06:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9C25C43141; Tue, 9 Aug 2022 18:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068390; bh=mOhX7/1JiVZXl/rUxysqLLJzKJJU34tJ44uNbeSOHMw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QTaspwzr1X6z07//rISv7i4ZvL83XQCozOcU2RuHLCEfv5qErOQX4bG9YotMZ5lNC CmdZnC/R41SBZKJR7mRXeYIRr5yKP+Y8HMySiD3fikJn2WOKbnAbbc67xy5wzfFqBw Y31vLyuJ6Uy9aqZU+AHE2wXyatA/UIvHLh+BgpcI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Damien Le Moal , Jan Kara , Christoph Hellwig , Jens Axboe Subject: [PATCH 5.18 02/35] block: fix default IO priority handling again Date: Tue, 9 Aug 2022 20:00:31 +0200 Message-Id: <20220809175515.135974385@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jan Kara commit e589f46445960c274cc813a1cc8e2fc73b2a1849 upstream. Commit e70344c05995 ("block: fix default IO priority handling") introduced an inconsistency in get_current_ioprio() that tasks without IO context return IOPRIO_DEFAULT priority while tasks with freshly allocated IO context will return 0 (IOPRIO_CLASS_NONE/0) IO priority. Tasks without IO context used to be rare before 5a9d041ba2f6 ("block: move io_context creation into where it's needed") but after this commit they became common because now only BFQ IO scheduler setups task's IO context. Similar inconsistency is there for get_task_ioprio() so this inconsistency is now exposed to userspace and userspace will see different IO priority for tasks operating on devices with BFQ compared to devices without BFQ. Furthemore the changes done by commit e70344c05995 change the behavior when no IO priority is set for BFQ IO scheduler which is also documented in ioprio_set(2) manpage: "If no I/O scheduler has been set for a thread, then by default the I/O priority will follow the CPU nice value (setpriority(2)). In Linux kernels before version 2.6.24, once an I/O priority had been set using ioprio_set(), there was no way to reset the I/O scheduling behavior to the default. Since Linux 2.6.24, specifying ioprio as 0 can be used to reset to the default I/O scheduling behavior." So make sure we default to IOPRIO_CLASS_NONE as used to be the case before commit e70344c05995. Also cleanup alloc_io_context() to explicitely set this IO priority for the allocated IO context to avoid future surprises. Note that we tweak ioprio_best() to maintain ioprio_get(2) behavior and make this commit easily backportable. CC: stable@vger.kernel.org Fixes: e70344c05995 ("block: fix default IO priority handling") Reviewed-by: Damien Le Moal Tested-by: Damien Le Moal Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220623074840.5960-1-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- block/blk-ioc.c | 2 ++ block/ioprio.c | 4 ++-- include/linux/ioprio.h | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) --- a/block/blk-ioc.c +++ b/block/blk-ioc.c @@ -247,6 +247,8 @@ static struct io_context *alloc_io_conte INIT_HLIST_HEAD(&ioc->icq_list); INIT_WORK(&ioc->release_work, ioc_release_fn); #endif + ioc->ioprio =3D IOPRIO_DEFAULT; + return ioc; } =20 --- a/block/ioprio.c +++ b/block/ioprio.c @@ -157,9 +157,9 @@ out: int ioprio_best(unsigned short aprio, unsigned short bprio) { if (!ioprio_valid(aprio)) - aprio =3D IOPRIO_DEFAULT; + aprio =3D IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_BE_NORM); if (!ioprio_valid(bprio)) - bprio =3D IOPRIO_DEFAULT; + bprio =3D IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_BE_NORM); =20 return min(aprio, bprio); } --- a/include/linux/ioprio.h +++ b/include/linux/ioprio.h @@ -11,7 +11,7 @@ /* * Default IO priority. */ -#define IOPRIO_DEFAULT IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_BE_NORM) +#define IOPRIO_DEFAULT IOPRIO_PRIO_VALUE(IOPRIO_CLASS_NONE, 0) =20 /* * Check that a priority value has a valid class. From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C3AAC25B07 for ; Tue, 9 Aug 2022 18:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346201AbiHISU5 (ORCPT ); Tue, 9 Aug 2022 14:20:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346866AbiHISRy (ORCPT ); Tue, 9 Aug 2022 14:17:54 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13C1F2F005; Tue, 9 Aug 2022 11:07:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 173F5B818BF; Tue, 9 Aug 2022 18:06:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64EE7C4347C; Tue, 9 Aug 2022 18:06:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068392; bh=UinAzkFxj+BLJyuf4XCMytJV/KED8ZQPD9DVBguyrlg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e+TlfBFrO3M5/WxNaTj5i3X6lr05/Xn0F+ZvpOQNX7OH3q/mz7zUwFYixuG+lPJbP c1ktfFNgHDuME9C4YLvz18eda1UTU4tnILQQ6eevNE20Txkh8xtkQeu8fzvwTgl3M6 Zi3eq+FR0ehRDMd1uUtU6ZBZ8/OsfcWBZuT/JWxY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?St=C3=A9phane=20Graber?= , Vlastimil Babka Subject: [PATCH 5.18 03/35] tools/vm/slabinfo: Handle files in debugfs Date: Tue, 9 Aug 2022 20:00:32 +0200 Message-Id: <20220809175515.184493506@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: St=C3=A9phane Graber commit 0c7e0d699ef1430d7f4cf12b4b1d097af58b5515 upstream. Commit 64dd68497be76 relocated and renamed the alloc_calls and free_calls files from /sys/kernel/slab/NAME/*_calls over to /sys/kernel/debug/slab/NAME/*_calls but didn't update the slabinfo tool with the new location. This change will now have slabinfo look at the new location (and filenames) with a fallback to the prior files. Fixes: 64dd68497be76 ("mm: slub: move sysfs slab alloc/free interfaces to d= ebugfs") Cc: stable@vger.kernel.org Signed-off-by: St=C3=A9phane Graber Tested-by: St=C3=A9phane Graber Signed-off-by: Vlastimil Babka Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/vm/slabinfo.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) --- a/tools/vm/slabinfo.c +++ b/tools/vm/slabinfo.c @@ -233,6 +233,24 @@ static unsigned long read_slab_obj(struc return l; } =20 +static unsigned long read_debug_slab_obj(struct slabinfo *s, const char *n= ame) +{ + char x[128]; + FILE *f; + size_t l; + + snprintf(x, 128, "/sys/kernel/debug/slab/%s/%s", s->name, name); + f =3D fopen(x, "r"); + if (!f) { + buffer[0] =3D 0; + l =3D 0; + } else { + l =3D fread(buffer, 1, sizeof(buffer), f); + buffer[l] =3D 0; + fclose(f); + } + return l; +} =20 /* * Put a size string together @@ -409,14 +427,18 @@ static void show_tracking(struct slabinf { printf("\n%s: Kernel object allocation\n", s->name); printf("-----------------------------------------------------------------= ------\n"); - if (read_slab_obj(s, "alloc_calls")) + if (read_debug_slab_obj(s, "alloc_traces")) + printf("%s", buffer); + else if (read_slab_obj(s, "alloc_calls")) printf("%s", buffer); else printf("No Data\n"); =20 printf("\n%s: Kernel object freeing\n", s->name); printf("-----------------------------------------------------------------= -------\n"); - if (read_slab_obj(s, "free_calls")) + if (read_debug_slab_obj(s, "free_traces")) + printf("%s", buffer); + else if (read_slab_obj(s, "free_calls")) printf("%s", buffer); else printf("No Data\n"); From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BE9CC19F2D for ; Tue, 9 Aug 2022 18:22:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245493AbiHISUm (ORCPT ); Tue, 9 Aug 2022 14:20:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346881AbiHISR4 (ORCPT ); Tue, 9 Aug 2022 14:17:56 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA62E2F016; Tue, 9 Aug 2022 11:07:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E4140B81890; Tue, 9 Aug 2022 18:06:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 399FDC433B5; Tue, 9 Aug 2022 18:06:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068395; bh=u4lI2lMYiinJQmQwYUWckHKjbNmaK8/9yZABUkeTu6g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cOAt6xZQJKQa3reEws0BTxxFSg8JgvWa+yaeUtdvVe3+Y7x4cjEaBmMICEy5SKfBt IcDtMNGlNZG7BH8K6MInRnhjb3qoYC016Q3GVML3oCzQBGq8B6UE1ynfUXxWO43DL7 ttcNhogWhAV8FGErlf1BRqAz/96Q6WvEUFRG2FYA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Werner Sembach , Hans de Goede , "Rafael J. Wysocki" Subject: [PATCH 5.18 04/35] ACPI: video: Force backlight native for some TongFang devices Date: Tue, 9 Aug 2022 20:00:33 +0200 Message-Id: <20220809175515.223731007@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Werner Sembach commit c752089f7cf5b5800c6ace4cdd1a8351ee78a598 upstream. The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10, Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2: They have a working native and video interface. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process. Signed-off-by: Werner Sembach Cc: All applicable Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/video_detect.c | 51 +++++++++++++++++++++++++++++++++++++++= ++++- 1 file changed, 50 insertions(+), 1 deletion(-) --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -490,7 +490,56 @@ static const struct dmi_system_id video_ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), }, }, - + /* + * The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10, + * Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo + * NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description + * above. + */ + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5PU1G", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF4NU1F", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF4NU1F", + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5NU1G", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5NU1G", + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5LUXG", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"), + }, + }, /* * Desktops which falsely report a backlight and which our heuristics * for this do not catch. From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54BAEC25B0D for ; Tue, 9 Aug 2022 18:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346415AbiHISVI (ORCPT ); Tue, 9 Aug 2022 14:21:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347002AbiHISSN (ORCPT ); Tue, 9 Aug 2022 14:18:13 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54EF32F02E; Tue, 9 Aug 2022 11:07:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A0C9DB818C2; Tue, 9 Aug 2022 18:06:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA8F9C433C1; Tue, 9 Aug 2022 18:06:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068398; bh=aGyKQPkfCYyDbbGaZ0fkMiRh36HetKAwNQbREqd4pEQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XAeiId7xSLOZWRBadoyutw8twlV35K4+cBEddEm3wxDUyJQu1O3eDS8pJZtpuBG5Q J/FR7jAk2dM543SeBV/iY548nzWP5Yhhs3WgB1IaMZ8wGebUzjjec10Q5jEkhRiNmO 2EksnTNxVBYsIzHOBoHA5YEVhM5K5nbbcPfeKDaE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Werner Sembach , Hans de Goede , "Rafael J. Wysocki" Subject: [PATCH 5.18 05/35] ACPI: video: Shortening quirk list by identifying Clevo by board_name only Date: Tue, 9 Aug 2022 20:00:34 +0200 Message-Id: <20220809175515.270042778@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Werner Sembach commit f0341e67b3782603737f7788e71bd3530012a4f4 upstream. Taking a recent change in the i8042 quirklist to this one: Clevo board_names are somewhat unique, and if not: The generic Board_-/Sys_Vendor string "Notebook" doesn't help much anyway. So identifying the devices just by the board_name helps keeping the list significantly shorter and might even hit more devices requiring the fix. Signed-off-by: Werner Sembach Fixes: c844d22fe0c0 ("ACPI: video: Force backlight native for Clevo NL5xRU = and NL5xNU") Cc: All applicable Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/video_detect.c | 34 ---------------------------------- 1 file changed, 34 deletions(-) --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -430,23 +430,6 @@ static const struct dmi_system_id video_ .callback =3D video_detect_force_native, .ident =3D "Clevo NL5xRU", .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xRU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xRU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), }, }, @@ -470,23 +453,6 @@ static const struct dmi_system_id video_ .callback =3D video_detect_force_native, .ident =3D "Clevo NL5xNU", .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xNU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xNU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), }, }, From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 054E5C25B0C for ; Tue, 9 Aug 2022 18:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344714AbiHISUu (ORCPT ); Tue, 9 Aug 2022 14:20:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347049AbiHISSU (ORCPT ); Tue, 9 Aug 2022 14:18:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7860E2F3A2; Tue, 9 Aug 2022 11:07:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7B20FB818EC; Tue, 9 Aug 2022 18:06:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C282BC433D6; Tue, 9 Aug 2022 18:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068401; bh=aS6kC7/UR/+s4cEQ6IbqOtahiGkvu5P7CX0AzJ/IWIM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KQ9lv3fUflTGCqwLRYIHGDPsvsh2/dU3/hNfDvFWFfxVQC/uXYgj8mB8Lue/sjth1 a0rtm3zaqd2IEXnXyLpFoqa3wNISwZpSWbAX7tqZ4VcZbDXe6D+K6RtmukCad/jf2+ GoYm+2nALGdKKZ6E7sQsP5SOdHQdAuNmsLTyXlb4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tony Luck , "Rafael J. Wysocki" Subject: [PATCH 5.18 06/35] ACPI: APEI: Better fix to avoid spamming the console with old error logs Date: Tue, 9 Aug 2022 20:00:35 +0200 Message-Id: <20220809175515.299942787@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Tony Luck commit c3481b6b75b4797657838f44028fd28226ab48e0 upstream. The fix in commit 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT table data") does not work as intended on systems where the BIOS has a fixed size block of memory for the BERT table, relying on s/w to quit when it finds a record with estatus->block_status =3D=3D 0. On these systems all errors are suppressed because the check: if (region_len < ACPI_BERT_PRINT_MAX_LEN) always fails. New scheme skips individual CPER records that are too large, and also limits the total number of records that will be printed to 5. Fixes: 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT table data") Cc: All applicable Signed-off-by: Tony Luck Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/apei/bert.c | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) --- a/drivers/acpi/apei/bert.c +++ b/drivers/acpi/apei/bert.c @@ -29,16 +29,26 @@ =20 #undef pr_fmt #define pr_fmt(fmt) "BERT: " fmt + +#define ACPI_BERT_PRINT_MAX_RECORDS 5 #define ACPI_BERT_PRINT_MAX_LEN 1024 =20 static int bert_disable; =20 +/* + * Print "all" the error records in the BERT table, but avoid huge spam to + * the console if the BIOS included oversize records, or too many records. + * Skipping some records here does not lose anything because the full + * data is available to user tools in: + * /sys/firmware/acpi/tables/data/BERT + */ static void __init bert_print_all(struct acpi_bert_region *region, unsigned int region_len) { struct acpi_hest_generic_status *estatus =3D (struct acpi_hest_generic_status *)region; int remain =3D region_len; + int printed =3D 0, skipped =3D 0; u32 estatus_len; =20 while (remain >=3D sizeof(struct acpi_bert_region)) { @@ -46,24 +56,26 @@ static void __init bert_print_all(struct if (remain < estatus_len) { pr_err(FW_BUG "Truncated status block (length: %u).\n", estatus_len); - return; + break; } =20 /* No more error records. */ if (!estatus->block_status) - return; + break; =20 if (cper_estatus_check(estatus)) { pr_err(FW_BUG "Invalid error record.\n"); - return; + break; } =20 - pr_info_once("Error records from previous boot:\n"); - if (region_len < ACPI_BERT_PRINT_MAX_LEN) + if (estatus_len < ACPI_BERT_PRINT_MAX_LEN && + printed < ACPI_BERT_PRINT_MAX_RECORDS) { + pr_info_once("Error records from previous boot:\n"); cper_estatus_print(KERN_INFO HW_ERR, estatus); - else - pr_info_once("Max print length exceeded, table data is available at:\n" - "/sys/firmware/acpi/tables/data/BERT"); + printed++; + } else { + skipped++; + } =20 /* * Because the boot error source is "one-time polled" type, @@ -75,6 +87,9 @@ static void __init bert_print_all(struct estatus =3D (void *)estatus + estatus_len; remain -=3D estatus_len; } + + if (skipped) + pr_info(HW_ERR "Skipped %d error records\n", skipped); } =20 static int __init setup_bert_disable(char *str) From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63C60C282E7 for ; Tue, 9 Aug 2022 18:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346512AbiHISVM (ORCPT ); Tue, 9 Aug 2022 14:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347072AbiHISSW (ORCPT ); Tue, 9 Aug 2022 14:18:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA5292F654; Tue, 9 Aug 2022 11:07:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7DCB3B817C2; Tue, 9 Aug 2022 18:06:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9460EC433D7; Tue, 9 Aug 2022 18:06:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068404; bh=jDWLxdfLb0UfgoWC21cxL2t9XM8NGIBroBhN1wxTcp4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FcFU1c0311Ht8ppHI5NMzyeLAPu3O3mBs1ailvsahLmO3rn5eZF8UI11KAkL2vssc aVYeDdO5fgoePgdlkjVW54bnLyT5dCQXz5E/kileIJT0PhnGixc3ybnfxQqVenadzu 1458DwNEI/KMyrDEWwEtLZF1WxSABfTwDPOQo1EQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, GUO Zihua , Eric Biggers , Will Deacon , Herbert Xu Subject: [PATCH 5.18 07/35] crypto: arm64/poly1305 - fix a read out-of-bound Date: Tue, 9 Aug 2022 20:00:36 +0200 Message-Id: <20220809175515.340186939@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: GUO Zihua commit 7ae19d422c7da84b5f13bc08b98bd737a08d3a53 upstream. A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x= 250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.a= arch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace: dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include #include #include #include char test_data[] =3D "\x00\x01\x02\x03\x04\x05\x06\x07" "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" "\x10\x11\x12\x13\x14\x15\x16\x17" "\x18\x19\x1a\x1b\x1c\x1d\x1e"; int init(void) { struct crypto_shash *tfm =3D NULL; char *data =3D NULL, *out =3D NULL; tfm =3D crypto_alloc_shash("poly1305", 0, 0); data =3D kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out =3D kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1); crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE("GPL"); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first "block" that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes. The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead of poly1305_init_arch(). This is also the implementation for the same algorithm on arm platform. Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGA= MS NEON implementation") Cc: stable@vger.kernel.org Signed-off-by: GUO Zihua Reviewed-by: Eric Biggers Acked-by: Will Deacon Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/arm64/crypto/poly1305-glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm64/crypto/poly1305-glue.c +++ b/arch/arm64/crypto/poly1305-glue.c @@ -52,7 +52,7 @@ static void neon_poly1305_blocks(struct { if (unlikely(!dctx->sset)) { if (!dctx->rset) { - poly1305_init_arch(dctx, src); + poly1305_init_arm64(&dctx->h, src); src +=3D POLY1305_BLOCK_SIZE; len -=3D POLY1305_BLOCK_SIZE; dctx->rset =3D 1; From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5B43C19F2D for ; Tue, 9 Aug 2022 18:22:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245708AbiHISWp (ORCPT ); Tue, 9 Aug 2022 14:22:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245464AbiHISSn (ORCPT ); Tue, 9 Aug 2022 14:18:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0111F2F679; Tue, 9 Aug 2022 11:07:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2FA6EB81895; Tue, 9 Aug 2022 18:06:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D953C433C1; Tue, 9 Aug 2022 18:06:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068406; bh=kyH58hFaNVvGkfde/a9XwzjhZRFLQg7liGu7TyinB0A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nrxR28g/m2JBhXKX9OAxpYZQfL+qkaM5F3pCX9Pb5mEMfpTB3NLc5XxANatdc9byX QyatxtqxV/ZD80NA0600PhSUxbkMLuhWGznTJxIwWrA07U0yuEplAXjeJW8oFvUd9q H/vhW6PZShCc4hWwFAsDuEUDvnDoYwnkguE86u0A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jann Horn , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 08/35] KVM: x86: do not report a vCPU as preempted outside instruction boundaries Date: Tue, 9 Aug 2022 20:00:37 +0200 Message-Id: <20220809175515.374218393@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Paolo Bonzini [ Upstream commit 6cd88243c7e03845a450795e134b488fc2afb736 ] If a vCPU is outside guest mode and is scheduled out, it might be in the process of making a memory access. A problem occurs if another vCPU uses the PV TLB flush feature during the period when the vCPU is scheduled out, and a virtual address has already been translated but has not yet been accessed, because this is equivalent to using a stale TLB entry. To avoid this, only report a vCPU as preempted if sure that the guest is at an instruction boundary. A rescheduling request will be delivered to the host physical CPU as an external interrupt, so for simplicity consider any vmexit *not* instruction boundary except for external interrupts. It would in principle be okay to report the vCPU as preempted also if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the vmentry/vmexit overhead unnecessarily, and optimistic spinning is also unlikely to succeed. However, leave it for later because right now kvm_vcpu_check_block() is doing memory accesses. Even though the TLB flush issue only applies to virtual memory address, it's very much preferrable to be conservative. Reported-by: Jann Horn Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/svm/svm.c | 2 ++ arch/x86/kvm/vmx/vmx.c | 1 + arch/x86/kvm/x86.c | 22 ++++++++++++++++++++++ 4 files changed, 28 insertions(+) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 4ff36610af6a..9fdaa847d4b6 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -651,6 +651,7 @@ struct kvm_vcpu_arch { u64 ia32_misc_enable_msr; u64 smbase; u64 smi_count; + bool at_instruction_boundary; bool tpr_access_reporting; bool xsaves_enabled; bool xfd_no_write_intercept; @@ -1289,6 +1290,8 @@ struct kvm_vcpu_stat { u64 nested_run; u64 directed_yield_attempted; u64 directed_yield_successful; + u64 preemption_reported; + u64 preemption_other; u64 guest_mode; }; =20 diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 6bfb0b0e66bd..c667214c630b 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4166,6 +4166,8 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu, =20 static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu) { + if (to_svm(vcpu)->vmcb->control.exit_code =3D=3D SVM_EXIT_INTR) + vcpu->arch.at_instruction_boundary =3D true; } =20 static void svm_sched_in(struct kvm_vcpu *vcpu, int cpu) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 4b6a0268c78e..597c3c08da50 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -6630,6 +6630,7 @@ static void handle_external_interrupt_irqoff(struct k= vm_vcpu *vcpu) return; =20 handle_interrupt_nmi_irqoff(vcpu, gate_offset(desc)); + vcpu->arch.at_instruction_boundary =3D true; } =20 static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 53b6fdf30c99..df74ec51c7f3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -291,6 +291,8 @@ const struct _kvm_stats_desc kvm_vcpu_stats_desc[] =3D { STATS_DESC_COUNTER(VCPU, nested_run), STATS_DESC_COUNTER(VCPU, directed_yield_attempted), STATS_DESC_COUNTER(VCPU, directed_yield_successful), + STATS_DESC_COUNTER(VCPU, preemption_reported), + STATS_DESC_COUNTER(VCPU, preemption_other), STATS_DESC_ICOUNTER(VCPU, guest_mode) }; =20 @@ -4607,6 +4609,19 @@ static void kvm_steal_time_set_preempted(struct kvm_= vcpu *vcpu) struct kvm_memslots *slots; static const u8 preempted =3D KVM_VCPU_PREEMPTED; =20 + /* + * The vCPU can be marked preempted if and only if the VM-Exit was on + * an instruction boundary and will not trigger guest emulation of any + * kind (see vcpu_run). Vendor specific code controls (conservatively) + * when this is true, for example allowing the vCPU to be marked + * preempted if and only if the VM-Exit was due to a host interrupt. + */ + if (!vcpu->arch.at_instruction_boundary) { + vcpu->stat.preemption_other++; + return; + } + + vcpu->stat.preemption_reported++; if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED)) return; =20 @@ -10363,6 +10378,13 @@ static int vcpu_run(struct kvm_vcpu *vcpu) vcpu->arch.l1tf_flush_l1d =3D true; =20 for (;;) { + /* + * If another guest vCPU requests a PV TLB flush in the middle + * of instruction emulation, the rest of the emulation could + * use a stale page translation. Assume that any code after + * this point can start executing an instruction. + */ + vcpu->arch.at_instruction_boundary =3D false; if (kvm_vcpu_running(vcpu)) { r =3D vcpu_enter_guest(vcpu); } else { --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9C03C19F2D for ; Tue, 9 Aug 2022 18:20:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343551AbiHISU0 (ORCPT ); Tue, 9 Aug 2022 14:20:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346728AbiHISRa (ORCPT ); Tue, 9 Aug 2022 14:17:30 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7955727FE2; Tue, 9 Aug 2022 11:06:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2ED7661001; Tue, 9 Aug 2022 18:06:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C584C43470; Tue, 9 Aug 2022 18:06:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068409; bh=lhDlPIwIg8u55QCmC20qTz4SHPQXU5/TWaQnXw4U9yk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=08eoEfF3BjtrNX6wskkugQjCB75MinXeXe0DgdWOu+zh97LNKAxd7ptcx+tCjSDhE Z/1u3KY9TKG1FJ5YG16hROgf7T1AkwH0s2/ziOJ1XW2qSmp6eMqTSPdX2lNFBIDrp1 DTgEHE/Q7wRF1PjaqzhyOdqFKIaX8FJI372ItqKQ= 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.18 09/35] KVM: x86: do not set st->preempted when going back to user space Date: Tue, 9 Aug 2022 20:00:38 +0200 Message-Id: <20220809175515.412581840@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Paolo Bonzini [ Upstream commit 54aa83c90198e68eee8b0850c749bc70efb548da ] Similar to the Xen path, only change the vCPU's reported state if the vCPU was actually preempted. The reason for KVM's behavior is that for example optimistic spinning might not be a good idea if the guest is doing repeated exits to userspace; however, it is confusing and unlikely to make a differe= nce, because well-tuned guests will hardly ever exit KVM_RUN in the first place. Suggested-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kvm/x86.c | 26 ++++++++++++++------------ arch/x86/kvm/xen.h | 6 ++++-- 2 files changed, 18 insertions(+), 14 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index df74ec51c7f3..91d887fd10ab 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4651,19 +4651,21 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu) { int idx; =20 - if (vcpu->preempted && !vcpu->arch.guest_state_protected) - vcpu->arch.preempted_in_kernel =3D !static_call(kvm_x86_get_cpl)(vcpu); + if (vcpu->preempted) { + if (!vcpu->arch.guest_state_protected) + vcpu->arch.preempted_in_kernel =3D !static_call(kvm_x86_get_cpl)(vcpu); =20 - /* - * Take the srcu lock as memslots will be accessed to check the gfn - * cache generation against the memslots generation. - */ - idx =3D srcu_read_lock(&vcpu->kvm->srcu); - if (kvm_xen_msr_enabled(vcpu->kvm)) - kvm_xen_runstate_set_preempted(vcpu); - else - kvm_steal_time_set_preempted(vcpu); - srcu_read_unlock(&vcpu->kvm->srcu, idx); + /* + * Take the srcu lock as memslots will be accessed to check the gfn + * cache generation against the memslots generation. + */ + idx =3D srcu_read_lock(&vcpu->kvm->srcu); + if (kvm_xen_msr_enabled(vcpu->kvm)) + kvm_xen_runstate_set_preempted(vcpu); + else + kvm_steal_time_set_preempted(vcpu); + srcu_read_unlock(&vcpu->kvm->srcu, idx); + } =20 static_call(kvm_x86_vcpu_put)(vcpu); vcpu->arch.last_host_tsc =3D rdtsc(); diff --git a/arch/x86/kvm/xen.h b/arch/x86/kvm/xen.h index adbcc9ed59db..fda1413f8af9 100644 --- a/arch/x86/kvm/xen.h +++ b/arch/x86/kvm/xen.h @@ -103,8 +103,10 @@ static inline void kvm_xen_runstate_set_preempted(stru= ct kvm_vcpu *vcpu) * behalf of the vCPU. Only if the VMM does actually block * does it need to enter RUNSTATE_blocked. */ - if (vcpu->preempted) - kvm_xen_update_runstate_guest(vcpu, RUNSTATE_runnable); + if (WARN_ON_ONCE(!vcpu->preempted)) + return; + + kvm_xen_update_runstate_guest(vcpu, RUNSTATE_runnable); } =20 /* 32-bit compatibility definitions, also used natively in 32-bit build */ --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE5F3C19F2D for ; Tue, 9 Aug 2022 18:20:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344474AbiHISUO (ORCPT ); Tue, 9 Aug 2022 14:20:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346600AbiHISRO (ORCPT ); Tue, 9 Aug 2022 14:17:14 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C99A2E6A4; Tue, 9 Aug 2022 11:06:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DB108B818A6; Tue, 9 Aug 2022 18:06:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EC51C433D7; Tue, 9 Aug 2022 18:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068378; bh=IBCeAButYsRtNeRmHz0Nr8ebRIHdO/EQ3qn0BXhofwY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RCKngP0r24UFgv1tarcS1wNrd2RBaB5wfCOdse7kgvx64+XswMMDrUulcFS+8IEEK LzvF2Z5UpHRCk5GJ/yMX35JpYnX2y47thNzyS/javZ9NtRwlM9x22p6JK+msJ4Tw88 hS8AlTYA+c1tkmp2bYdnBYm1IZ3iSGv2Mk9+ZwK8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxim Levitsky , Vitaly Kuznetsov , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 10/35] KVM: selftests: Make hyperv_clock selftest more stable Date: Tue, 9 Aug 2022 20:00:39 +0200 Message-Id: <20220809175515.442327221@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vitaly Kuznetsov [ Upstream commit eae260be3a0111a28fe95923e117a55dddec0384 ] hyperv_clock doesn't always give a stable test result, especially with AMD CPUs. The test compares Hyper-V MSR clocksource (acquired either with rdmsr() from within the guest or KVM_GET_MSRS from the host) against rdtsc(). To increase the accuracy, increase the measured delay (done with nop loop) by two orders of magnitude and take the mean rdtsc() value before and after rdmsr()/KVM_GET_MSRS. Reported-by: Maxim Levitsky Signed-off-by: Vitaly Kuznetsov Reviewed-by: Maxim Levitsky Tested-by: Maxim Levitsky Message-Id: <20220601144322.1968742-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/kvm/x86_64/hyperv_clock.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/kvm/x86_64/hyperv_clock.c b/tools/test= ing/selftests/kvm/x86_64/hyperv_clock.c index e0b2bb1339b1..3330fb183c68 100644 --- a/tools/testing/selftests/kvm/x86_64/hyperv_clock.c +++ b/tools/testing/selftests/kvm/x86_64/hyperv_clock.c @@ -44,7 +44,7 @@ static inline void nop_loop(void) { int i; =20 - for (i =3D 0; i < 1000000; i++) + for (i =3D 0; i < 100000000; i++) asm volatile("nop"); } =20 @@ -56,12 +56,14 @@ static inline void check_tsc_msr_rdtsc(void) tsc_freq =3D rdmsr(HV_X64_MSR_TSC_FREQUENCY); GUEST_ASSERT(tsc_freq > 0); =20 - /* First, check MSR-based clocksource */ + /* For increased accuracy, take mean rdtsc() before and afrer rdmsr() */ r1 =3D rdtsc(); t1 =3D rdmsr(HV_X64_MSR_TIME_REF_COUNT); + r1 =3D (r1 + rdtsc()) / 2; nop_loop(); r2 =3D rdtsc(); t2 =3D rdmsr(HV_X64_MSR_TIME_REF_COUNT); + r2 =3D (r2 + rdtsc()) / 2; =20 GUEST_ASSERT(r2 > r1 && t2 > t1); =20 @@ -181,12 +183,14 @@ static void host_check_tsc_msr_rdtsc(struct kvm_vm *v= m) tsc_freq =3D vcpu_get_msr(vm, VCPU_ID, HV_X64_MSR_TSC_FREQUENCY); TEST_ASSERT(tsc_freq > 0, "TSC frequency must be nonzero"); =20 - /* First, check MSR-based clocksource */ + /* For increased accuracy, take mean rdtsc() before and afrer ioctl */ r1 =3D rdtsc(); t1 =3D vcpu_get_msr(vm, VCPU_ID, HV_X64_MSR_TIME_REF_COUNT); + r1 =3D (r1 + rdtsc()) / 2; nop_loop(); r2 =3D rdtsc(); t2 =3D vcpu_get_msr(vm, VCPU_ID, HV_X64_MSR_TIME_REF_COUNT); + r2 =3D (r2 + rdtsc()) / 2; =20 TEST_ASSERT(t2 > t1, "Time reference MSR is not monotonic (%ld <=3D %ld)"= , t1, t2); =20 --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19E76C19F2D for ; Tue, 9 Aug 2022 18:20:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245557AbiHISUV (ORCPT ); Tue, 9 Aug 2022 14:20:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346686AbiHISRX (ORCPT ); Tue, 9 Aug 2022 14:17:23 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62E712E9DE; Tue, 9 Aug 2022 11:06:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CBD6FB818B4; Tue, 9 Aug 2022 18:06:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 198E8C433D7; Tue, 9 Aug 2022 18:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068381; bh=NSlycFjduxzkyRLbG8gBMYKto4K11+uaNjz5PTLaJf8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eJVqhguF6DQ3rWpGSAHEQkxBd2vQJGHvTyRQ++DyvDymIvo83TZnLvFx0+7dcZw3Z +mG5LSiX/cQj7ToliMHui2YmxkPh8JXSzit2kKss5jTyAQ//QpzLxrlSmKr2XIuWoG FfA90CeHA1iMLnIpSgY3D99xla3HaAEBSYPkZFpY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ben Gardon , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 11/35] KVM: x86/MMU: Zap non-leaf SPTEs when disabling dirty logging Date: Tue, 9 Aug 2022 20:00:40 +0200 Message-Id: <20220809175515.481015905@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ben Gardon [ Upstream commit 5ba7c4c6d1c7af47a916f728bb5940669684a087 ] Currently disabling dirty logging with the TDP MMU is extremely slow. On a 96 vCPU / 96G VM backed with gigabyte pages, it takes ~200 seconds to disable dirty logging with the TDP MMU, as opposed to ~4 seconds with the shadow MMU. When disabling dirty logging, zap non-leaf parent entries to allow replacement with huge pages instead of recursing and zapping all of the child, leaf entries. This reduces the number of TLB flushes required. and reduces the disable dirty log time with the TDP MMU to ~3 seconds. Opportunistically add a WARN() to catch GFNs that are mapped at a higher level than their max level. Signed-off-by: Ben Gardon Message-Id: <20220525230904.1584480-1-bgardon@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kvm/mmu/tdp_iter.c | 9 +++++++++ arch/x86/kvm/mmu/tdp_iter.h | 1 + arch/x86/kvm/mmu/tdp_mmu.c | 38 +++++++++++++++++++++++++++++++------ 3 files changed, 42 insertions(+), 6 deletions(-) diff --git a/arch/x86/kvm/mmu/tdp_iter.c b/arch/x86/kvm/mmu/tdp_iter.c index 6d3b3e5a5533..ee4802d7b36c 100644 --- a/arch/x86/kvm/mmu/tdp_iter.c +++ b/arch/x86/kvm/mmu/tdp_iter.c @@ -145,6 +145,15 @@ static bool try_step_up(struct tdp_iter *iter) return true; } =20 +/* + * Step the iterator back up a level in the paging structure. Should only = be + * used when the iterator is below the root level. + */ +void tdp_iter_step_up(struct tdp_iter *iter) +{ + WARN_ON(!try_step_up(iter)); +} + /* * Step to the next SPTE in a pre-order traversal of the paging structure. * To get to the next SPTE, the iterator either steps down towards the goal diff --git a/arch/x86/kvm/mmu/tdp_iter.h b/arch/x86/kvm/mmu/tdp_iter.h index f0af385c56e0..adfca0cf94d3 100644 --- a/arch/x86/kvm/mmu/tdp_iter.h +++ b/arch/x86/kvm/mmu/tdp_iter.h @@ -114,5 +114,6 @@ void tdp_iter_start(struct tdp_iter *iter, struct kvm_m= mu_page *root, int min_level, gfn_t next_last_level_gfn); void tdp_iter_next(struct tdp_iter *iter); void tdp_iter_restart(struct tdp_iter *iter); +void tdp_iter_step_up(struct tdp_iter *iter); =20 #endif /* __KVM_X86_MMU_TDP_ITER_H */ diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index 922b06bf4b94..b61a11d462cc 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -1748,12 +1748,12 @@ static void zap_collapsible_spte_range(struct kvm *= kvm, gfn_t start =3D slot->base_gfn; gfn_t end =3D start + slot->npages; struct tdp_iter iter; + int max_mapping_level; kvm_pfn_t pfn; =20 rcu_read_lock(); =20 tdp_root_for_each_pte(iter, root, start, end) { -retry: if (tdp_mmu_iter_cond_resched(kvm, &iter, false, true)) continue; =20 @@ -1761,15 +1761,41 @@ static void zap_collapsible_spte_range(struct kvm *= kvm, !is_last_spte(iter.old_spte, iter.level)) continue; =20 + /* + * This is a leaf SPTE. Check if the PFN it maps can + * be mapped at a higher level. + */ pfn =3D spte_to_pfn(iter.old_spte); - if (kvm_is_reserved_pfn(pfn) || - iter.level >=3D kvm_mmu_max_mapping_level(kvm, slot, iter.gfn, - pfn, PG_LEVEL_NUM)) + + if (kvm_is_reserved_pfn(pfn)) continue; =20 + max_mapping_level =3D kvm_mmu_max_mapping_level(kvm, slot, + iter.gfn, pfn, PG_LEVEL_NUM); + + WARN_ON(max_mapping_level < iter.level); + + /* + * If this page is already mapped at the highest + * viable level, there's nothing more to do. + */ + if (max_mapping_level =3D=3D iter.level) + continue; + + /* + * The page can be remapped at a higher level, so step + * up to zap the parent SPTE. + */ + while (max_mapping_level > iter.level) + tdp_iter_step_up(&iter); + /* Note, a successful atomic zap also does a remote TLB flush. */ - if (tdp_mmu_zap_spte_atomic(kvm, &iter)) - goto retry; + tdp_mmu_zap_spte_atomic(kvm, &iter); + + /* + * If the atomic zap fails, the iter will recurse back into + * the same subtree to retry. + */ } =20 rcu_read_unlock(); --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 926D8C19F2D for ; Tue, 9 Aug 2022 18:20:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245422AbiHISUb (ORCPT ); Tue, 9 Aug 2022 14:20:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346741AbiHISRf (ORCPT ); Tue, 9 Aug 2022 14:17:35 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D57282ED4F; Tue, 9 Aug 2022 11:06:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A62FCB8188F; Tue, 9 Aug 2022 18:06:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAC6BC433C1; Tue, 9 Aug 2022 18:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068384; bh=mqbC7bVhIM0dnxYNVzszPMiYzv0AKKldGP1tDyqt/kk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G04DlaKk5aKiV38CAoLzgjFBvDH4mTSob9yKXD1cc9HydSy5J9AOjakGjSj/keXSI lWnrdQC9cGGsgQO5wuQPjg1yEErfHRkw7owo0RfNRjFJroqrrESHLlNGqK6Y+iwIvb NtyeE89nIK9NM7dM3IY6wr6sB44ramnX2nGKrZrY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Eric W. Biederman" , Petr Mladek , Seth Forshee , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 12/35] entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set Date: Tue, 9 Aug 2022 20:00:41 +0200 Message-Id: <20220809175515.512110504@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Seth Forshee [ Upstream commit 3e684903a8574ffc9475fdf13c4780a7adb506ad ] A livepatch transition may stall indefinitely when a kvm vCPU is heavily loaded. To the host, the vCPU task is a user thread which is spending a very long time in the ioctl(KVM_RUN) syscall. During livepatch transition, set_notify_signal() will be called on such tasks to interrupt the syscall so that the task can be transitioned. This interrupts guest execution, but when xfer_to_guest_mode_work() sees that TIF_NOTIFY_SIGNAL is set but not TIF_SIGPENDING it concludes that an exit to user mode is unnecessary, and guest execution is resumed without transitioning the task for the livepatch. This handling of TIF_NOTIFY_SIGNAL is incorrect, as set_notify_signal() is expected to break tasks out of interruptible kernel loops and cause them to return to userspace. Change xfer_to_guest_mode_work() to handle TIF_NOTIFY_SIGNAL the same as TIF_SIGPENDING, signaling to the vCPU run loop that an exit to userpsace is needed. Any pending task_work will be run when get_signal() is called from exit_to_user_mode_loop(), so there is no longer any need to run task work from xfer_to_guest_mode_work(). Suggested-by: "Eric W. Biederman" Cc: Petr Mladek Signed-off-by: Seth Forshee Message-Id: <20220504180840.2907296-1-sforshee@digitalocean.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/entry/kvm.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/kernel/entry/kvm.c b/kernel/entry/kvm.c index 9d09f489b60e..2e0f75bcb7fd 100644 --- a/kernel/entry/kvm.c +++ b/kernel/entry/kvm.c @@ -9,12 +9,6 @@ static int xfer_to_guest_mode_work(struct kvm_vcpu *vcpu, = unsigned long ti_work) int ret; =20 if (ti_work & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) { - clear_notify_signal(); - if (task_work_pending(current)) - task_work_run(); - } - - if (ti_work & _TIF_SIGPENDING) { kvm_handle_signal_exit(vcpu); return -EINTR; } --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6E72C25B0C for ; Tue, 9 Aug 2022 18:20:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343851AbiHISUi (ORCPT ); Tue, 9 Aug 2022 14:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346788AbiHISRp (ORCPT ); Tue, 9 Aug 2022 14:17:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8C762ED65; Tue, 9 Aug 2022 11:06:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6E1DCB818E2; Tue, 9 Aug 2022 18:06:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B991EC433B5; Tue, 9 Aug 2022 18:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068387; bh=sZkq70RwvIjDXbL2WLFX6bnGB7uLboQX0UZurcdhliU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TdTJqjQ/x4y1KkujQNpMugEJKuBBXoTkprOzSRmfkeJmr0Bid/xoLeMj8Gia/zKeK VM4xLd/PjKLscdwGGGc4xWZphK3munHC0qGb0feyIh4ezOlfDiMrEBnu0PVZWqCzXT 44IBr+fWmoSDtLlbbpXPtq+lj/CgywUBDx6RYvT8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxim Levitsky , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 13/35] KVM: x86: disable preemption while updating apicv inhibition Date: Tue, 9 Aug 2022 20:00:42 +0200 Message-Id: <20220809175515.542696207@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Maxim Levitsky [ Upstream commit 66c768d30e64e1280520f34dbef83419f55f3459 ] Currently nothing prevents preemption in kvm_vcpu_update_apicv. On SVM, If the preemption happens after we update the vcpu->arch.apicv_active, the preemption itself will 'update' the inhibition since the AVIC will be first disabled on vCPU unload and then enabled, when the current task is loaded again. Then we will try to update it again, which will lead to a warning in __avic_vcpu_load, that the AVIC is already enabled. Fix this by disabling preemption in this code. Signed-off-by: Maxim Levitsky Message-Id: <20220606180829.102503-6-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 91d887fd10ab..65b0ec28bd52 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9784,6 +9784,7 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) return; =20 down_read(&vcpu->kvm->arch.apicv_update_lock); + preempt_disable(); =20 activate =3D kvm_apicv_activated(vcpu->kvm); if (vcpu->arch.apicv_active =3D=3D activate) @@ -9803,6 +9804,7 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) kvm_make_request(KVM_REQ_EVENT, vcpu); =20 out: + preempt_enable(); up_read(&vcpu->kvm->arch.apicv_update_lock); } EXPORT_SYMBOL_GPL(kvm_vcpu_update_apicv); --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CA75C19F2D for ; Tue, 9 Aug 2022 18:25:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344593AbiHISZX (ORCPT ); Tue, 9 Aug 2022 14:25:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245720AbiHISWq (ORCPT ); Tue, 9 Aug 2022 14:22:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33DD732058; Tue, 9 Aug 2022 11:08:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2EDC3B818C9; Tue, 9 Aug 2022 18:07:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77044C433D7; Tue, 9 Aug 2022 18:07:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068451; bh=u9PreAMLfAZXPuhQcBjbpBtRZ/5+dZ+KdUmxs9Nagbk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wTTGWX0VU+cfqabt/vVcy48wvWLR2oV8DJorN+yrW2tBFtDplopKiocwUAdh3d/vu 3ACRM5UOszyKVIkqKv9FlITnoNTWUF36FvlwR2XlEfHSh6eWKTxGsDzdGqydG2bq7Q C5IQrYH+fSFUDFsl3/RoZyZl+sW0Lohb3L/Luq34= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxim Levitsky , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 14/35] KVM: x86: disable preemption around the call to kvm_arch_vcpu_{un|}blocking Date: Tue, 9 Aug 2022 20:00:43 +0200 Message-Id: <20220809175515.577225397@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Maxim Levitsky [ Upstream commit 18869f26df1a11ed11031dfb7392bc7d774062e8 ] On SVM, if preemption happens right after the call to finish_rcuwait but before call to kvm_arch_vcpu_unblocking on SVM/AVIC, it itself will re-enable AVIC, and then we will try to re-enable it again in kvm_arch_vcpu_unblocking which will lead to a warning in __avic_vcpu_load. The same problem can happen if the vCPU is preempted right after the call to kvm_arch_vcpu_blocking but before the call to prepare_to_rcuwait and in this case, we will end up with AVIC enabled during sleep - Ooops. Signed-off-by: Maxim Levitsky Message-Id: <20220606180829.102503-7-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- virt/kvm/kvm_main.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 24cb37d19c63..7f1d19689701 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3327,9 +3327,11 @@ bool kvm_vcpu_block(struct kvm_vcpu *vcpu) =20 vcpu->stat.generic.blocking =3D 1; =20 + preempt_disable(); kvm_arch_vcpu_blocking(vcpu); - prepare_to_rcuwait(wait); + preempt_enable(); + for (;;) { set_current_state(TASK_INTERRUPTIBLE); =20 @@ -3339,9 +3341,11 @@ bool kvm_vcpu_block(struct kvm_vcpu *vcpu) waited =3D true; schedule(); } - finish_rcuwait(wait); =20 + preempt_disable(); + finish_rcuwait(wait); kvm_arch_vcpu_unblocking(vcpu); + preempt_enable(); =20 vcpu->stat.generic.blocking =3D 0; =20 --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5235C19F2D for ; Tue, 9 Aug 2022 18:23:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343584AbiHISW6 (ORCPT ); Tue, 9 Aug 2022 14:22:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345992AbiHISTo (ORCPT ); Tue, 9 Aug 2022 14:19:44 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD4CA2FFEF; Tue, 9 Aug 2022 11:07:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 937EFB8190A; Tue, 9 Aug 2022 18:06:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBF64C433B5; Tue, 9 Aug 2022 18:06:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068415; bh=3+kfBJXx7bJFsPBrjotmt2oV78Cw71odr1QKUuLojLM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DPkwUjI0E/mgK5BzzgmVkQbdXIsMn4mn05dOStrynkvlAllHIoc6VoJWNl35PvOuQ lUzNZUcYLnaOvWvebmMY0YREmVHgodgL8e4j24iDz0ayG3vnWxuRkKZsZ2LYi1u6nJ 3ndAMwhrMz5Tj8EEQIJoWD+DfkQ3OlBKY4qnSm9M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sean Christopherson , David Matlack , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 15/35] KVM: selftests: Restrict test region to 48-bit physical addresses when using nested Date: Tue, 9 Aug 2022 20:00:44 +0200 Message-Id: <20220809175515.617280681@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: David Matlack [ Upstream commit e0f3f46e42064a51573914766897b4ab95d943e3 ] The selftests nested code only supports 4-level paging at the moment. This means it cannot map nested guest physical addresses with more than 48 bits. Allow perf_test_util nested mode to work on hosts with more than 48 physical addresses by restricting the guest test region to 48-bits. While here, opportunistically fix an off-by-one error when dealing with vm_get_max_gfn(). perf_test_util.c was treating this as the maximum number of GFNs, rather than the maximum allowed GFN. This didn't result in any correctness issues, but it did end up shifting the test region down slightly when using huge pages. Suggested-by: Sean Christopherson Signed-off-by: David Matlack Message-Id: <20220520233249.3776001-12-dmatlack@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- .../testing/selftests/kvm/lib/perf_test_util.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/kvm/lib/perf_test_util.c b/tools/testi= ng/selftests/kvm/lib/perf_test_util.c index 722df3a28791..ddd68ba0c99f 100644 --- a/tools/testing/selftests/kvm/lib/perf_test_util.c +++ b/tools/testing/selftests/kvm/lib/perf_test_util.c @@ -110,6 +110,7 @@ struct kvm_vm *perf_test_create_vm(enum vm_guest_mode m= ode, int vcpus, struct kvm_vm *vm; uint64_t guest_num_pages; uint64_t backing_src_pagesz =3D get_backing_src_pagesz(backing_src); + uint64_t region_end_gfn; int i; =20 pr_info("Testing guest mode: %s\n", vm_guest_mode_string(mode)); @@ -144,18 +145,29 @@ struct kvm_vm *perf_test_create_vm(enum vm_guest_mode= mode, int vcpus, =20 pta->vm =3D vm; =20 + /* Put the test region at the top guest physical memory. */ + region_end_gfn =3D vm_get_max_gfn(vm) + 1; + +#ifdef __x86_64__ + /* + * When running vCPUs in L2, restrict the test region to 48 bits to + * avoid needing 5-level page tables to identity map L2. + */ + if (pta->nested) + region_end_gfn =3D min(region_end_gfn, (1UL << 48) / pta->guest_page_siz= e); +#endif /* * If there should be more memory in the guest test region than there * can be pages in the guest, it will definitely cause problems. */ - TEST_ASSERT(guest_num_pages < vm_get_max_gfn(vm), + TEST_ASSERT(guest_num_pages < region_end_gfn, "Requested more guest memory than address space allows.\n" " guest pages: %" PRIx64 " max gfn: %" PRIx64 " vcpus: %d wss: %" PRIx64 "]\n", - guest_num_pages, vm_get_max_gfn(vm), vcpus, + guest_num_pages, region_end_gfn - 1, vcpus, vcpu_memory_bytes); =20 - pta->gpa =3D (vm_get_max_gfn(vm) - guest_num_pages) * pta->guest_page_siz= e; + pta->gpa =3D (region_end_gfn - guest_num_pages) * pta->guest_page_size; pta->gpa =3D align_down(pta->gpa, backing_src_pagesz); #ifdef __s390x__ /* Align to 1M (segment size) */ --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C787C19F2D for ; Tue, 9 Aug 2022 18:23:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343903AbiHISXx (ORCPT ); Tue, 9 Aug 2022 14:23:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346913AbiHISVn (ORCPT ); Tue, 9 Aug 2022 14:21:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FFFD30F78; Tue, 9 Aug 2022 11:08:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 914B9B81977; Tue, 9 Aug 2022 18:07:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D469AC4347C; Tue, 9 Aug 2022 18:07:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068429; bh=cAL7cSlopyAfoe9ePy3AVZXWDpqa/7WVl3RSZd8S3bI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OL6pi+cxDpQiTWaTe9bg+6LAGKo2+1x6BA6L1nu6QJc//8SKMFZ0xRL9XN7v9joOj weuqS1xEgc2m6wA8EnAlYhTIUCS3GYzvM5AK4y+XD94n+cWcArw/JF646YcWdUZSvd BYmPWOIAwt52IhJMaf9sp/n83vNQDm77ll0864eU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Klochkov , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 16/35] tools/kvm_stat: fix display of error when multiple processes are found Date: Tue, 9 Aug 2022 20:00:45 +0200 Message-Id: <20220809175515.646168498@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dmitry Klochkov [ Upstream commit 933b5f9f98da29af646b51b36a0753692908ef64 ] Instead of printing an error message, kvm_stat script fails when we restrict statistics to a guest by its name and there are multiple guests with such name: # kvm_stat -g my_vm Traceback (most recent call last): File "/usr/bin/kvm_stat", line 1819, in main() File "/usr/bin/kvm_stat", line 1779, in main options =3D get_options() File "/usr/bin/kvm_stat", line 1718, in get_options options =3D argparser.parse_args() File "/usr/lib64/python3.10/argparse.py", line 1825, in parse_args args, argv =3D self.parse_known_args(args, namespace) File "/usr/lib64/python3.10/argparse.py", line 1858, in parse_known_args namespace, args =3D self._parse_known_args(args, namespace) File "/usr/lib64/python3.10/argparse.py", line 2067, in _parse_known_ar= gs start_index =3D consume_optional(start_index) File "/usr/lib64/python3.10/argparse.py", line 2007, in consume_optional take_action(action, args, option_string) File "/usr/lib64/python3.10/argparse.py", line 1935, in take_action action(self, namespace, argument_values, option_string) File "/usr/bin/kvm_stat", line 1649, in __call__ ' to specify the desired pid'.format(" ".join(pids))) TypeError: sequence item 0: expected str instance, int found To avoid this, it's needed to convert pids int values to strings before pass them to join(). Signed-off-by: Dmitry Klochkov Message-Id: <20220614121141.160689-1-kdmitry556@gmail.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/kvm/kvm_stat/kvm_stat | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/kvm/kvm_stat/kvm_stat b/tools/kvm/kvm_stat/kvm_stat index 5a5bd74f55bd..9c366b3a676d 100755 --- a/tools/kvm/kvm_stat/kvm_stat +++ b/tools/kvm/kvm_stat/kvm_stat @@ -1646,7 +1646,8 @@ Press any other key to refresh statistics immediately. .format(values)) if len(pids) > 1: sys.exit('Error: Multiple processes found (pids: {}). Use = "-p"' - ' to specify the desired pid'.format(" ".join(pid= s))) + ' to specify the desired pid' + .format(" ".join(map(str, pids)))) namespace.pid =3D pids[0] =20 argparser =3D argparse.ArgumentParser(description=3Ddescription_text, --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A56EC19F2D for ; Tue, 9 Aug 2022 18:24:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343934AbiHISYB (ORCPT ); Tue, 9 Aug 2022 14:24:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347005AbiHISVs (ORCPT ); Tue, 9 Aug 2022 14:21:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16BD231342; Tue, 9 Aug 2022 11:08:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7961DB81978; Tue, 9 Aug 2022 18:07:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1882C433B5; Tue, 9 Aug 2022 18:07:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068432; bh=Q9TQo1YpqN5c0AN7PcviO9s8yzNZpGDadJSGpTvGND8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zfTYSnciBE64iArhPgp2RoAnbNFztxpuXWzyYRj1kGcGyrZ0kRjsRJRpquF14nx4g fLB6EAXGxk0IK5MywQ3TGwfXfAfM/Gr0t015TcVXUPzYavoUnMBAvgyVU5Mc2MP53q 5VqIk6ddU0jE1pVlhYNxpySHrMaCoLXtERQ/oBjE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ricardo Koller , Reiji Watanabe , Raghavendra Rao Ananta , Andrew Jones , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 17/35] selftests: KVM: Handle compiler optimizations in ucall Date: Tue, 9 Aug 2022 20:00:46 +0200 Message-Id: <20220809175515.675440462@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Raghavendra Rao Ananta [ Upstream commit 9e2f6498efbbc880d7caa7935839e682b64fe5a6 ] The selftests, when built with newer versions of clang, is found to have over optimized guests' ucall() function, and eliminating the stores for uc.cmd (perhaps due to no immediate readers). This resulted in the userspace side always reading a value of '0', and causing multiple test failures. As a result, prevent the compiler from optimizing the stores in ucall() with WRITE_ONCE(). Suggested-by: Ricardo Koller Suggested-by: Reiji Watanabe Signed-off-by: Raghavendra Rao Ananta Message-Id: <20220615185706.1099208-1-rananta@google.com> Reviewed-by: Andrew Jones Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/kvm/lib/aarch64/ucall.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/kvm/lib/aarch64/ucall.c b/tools/testin= g/selftests/kvm/lib/aarch64/ucall.c index e0b0164e9af8..be1d9728c4ce 100644 --- a/tools/testing/selftests/kvm/lib/aarch64/ucall.c +++ b/tools/testing/selftests/kvm/lib/aarch64/ucall.c @@ -73,20 +73,19 @@ void ucall_uninit(struct kvm_vm *vm) =20 void ucall(uint64_t cmd, int nargs, ...) { - struct ucall uc =3D { - .cmd =3D cmd, - }; + struct ucall uc =3D {}; va_list va; int i; =20 + WRITE_ONCE(uc.cmd, cmd); nargs =3D nargs <=3D UCALL_MAX_ARGS ? nargs : UCALL_MAX_ARGS; =20 va_start(va, nargs); for (i =3D 0; i < nargs; ++i) - uc.args[i] =3D va_arg(va, uint64_t); + WRITE_ONCE(uc.args[i], va_arg(va, uint64_t)); va_end(va); =20 - *ucall_exit_mmio_addr =3D (vm_vaddr_t)&uc; + WRITE_ONCE(*ucall_exit_mmio_addr, (vm_vaddr_t)&uc); } =20 uint64_t get_ucall(struct kvm_vm *vm, uint32_t vcpu_id, struct ucall *uc) --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA448C19F2D for ; Tue, 9 Aug 2022 18:24:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343966AbiHISYI (ORCPT ); Tue, 9 Aug 2022 14:24:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347065AbiHISVv (ORCPT ); Tue, 9 Aug 2022 14:21:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC5B93135B; Tue, 9 Aug 2022 11:08:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2BE71B81984; Tue, 9 Aug 2022 18:07:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AC08C43470; Tue, 9 Aug 2022 18:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068434; bh=6t5nAW85mchGprZ1vZMUXJ5LsQtTviicHPUQGDgT6qY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zaurccPVk1p0r67rfkQu1iQCPiX1Z+x+eCF6cbiU6tA6YL5pZwi37813H9zwwk2G8 e9SWF+e5wsBBRgrd1san6AntrwLH3i3B7o9wZpOrrOxN0Gh1ey2cuLdRpnsHnnz7OI im8O0UmaqfaG4K2grqgIEqzqufqlfZ2bQEri0DTo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mingwei Zhang , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.18 18/35] KVM: x86/svm: add __GFP_ACCOUNT to __sev_dbg_{en,de}crypt_user() Date: Tue, 9 Aug 2022 20:00:47 +0200 Message-Id: <20220809175515.705981446@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Mingwei Zhang [ Upstream commit ebdec859faa8cfbfef9f6c1f83d79dd6c8f4ab8c ] Adding the accounting flag when allocating pages within the SEV function, since these memory pages should belong to individual VM. No functional change intended. Signed-off-by: Mingwei Zhang Message-Id: <20220623171858.2083637-1-mizhang@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/kvm/svm/sev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 76e9e6eb71d6..7aa1ce34a520 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -844,7 +844,7 @@ static int __sev_dbg_encrypt_user(struct kvm *kvm, unsi= gned long paddr, =20 /* If source buffer is not aligned then use an intermediate buffer */ if (!IS_ALIGNED((unsigned long)vaddr, 16)) { - src_tpage =3D alloc_page(GFP_KERNEL); + src_tpage =3D alloc_page(GFP_KERNEL_ACCOUNT); if (!src_tpage) return -ENOMEM; =20 @@ -865,7 +865,7 @@ static int __sev_dbg_encrypt_user(struct kvm *kvm, unsi= gned long paddr, if (!IS_ALIGNED((unsigned long)dst_vaddr, 16) || !IS_ALIGNED(size, 16)) { int dst_offset; =20 - dst_tpage =3D alloc_page(GFP_KERNEL); + dst_tpage =3D alloc_page(GFP_KERNEL_ACCOUNT); if (!dst_tpage) { ret =3D -ENOMEM; goto e_free; --=20 2.35.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87A79C19F2D for ; Tue, 9 Aug 2022 18:24:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343991AbiHISYS (ORCPT ); Tue, 9 Aug 2022 14:24:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347248AbiHISWG (ORCPT ); Tue, 9 Aug 2022 14:22:06 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49BE13190F; Tue, 9 Aug 2022 11:08:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 16BFCB8198C; Tue, 9 Aug 2022 18:07:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34567C43470; Tue, 9 Aug 2022 18:07:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068437; bh=Du+LfgidnyUZQYmLnNKvCIdplUELRrxtwIDyhwydf1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zur7zKxtD12ZouyIjmHgS6iqi7LqByyMG7O9tQ1HSLE8j+t7KnrLPM4MgodQjLWdK +fJPbP7MFjCzl2U0U0sEalqEib7W/hwFeq58F/aIKHcMTxCm7NXpC7vNya1+71x8HN 2WrdlYway/M+/TFnMdfs7HpCANYyCJI3kwHP5GiE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Peter Collingbourne , Will Deacon , Ard Biesheuvel , Catalin Marinas Subject: [PATCH 5.18 19/35] arm64: set UXN on swapper page tables Date: Tue, 9 Aug 2022 20:00:48 +0200 Message-Id: <20220809175515.739951080@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Peter Collingbourne [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64: head: cover entire kernel image in initial ID map") as part of a large refactoring of the arm64 boot flow. This simple fix is therefore preferred for -stable backporting ] On a system that implements FEAT_EPAN, read/write access to the idmap is denied because UXN is not set on the swapper PTEs. As a result, idmap_kpti_install_ng_mappings panics the kernel when accessing __idmap_kpti_flag. Fix it by setting UXN on these PTEs. Fixes: 18107f8a2df6 ("arm64: Support execute-only permissions with Enhanced= PAN") Cc: # 5.15 Link: https://linux-review.googlesource.com/id/Ic452fa4b4f74753e54f71e61027= e7222a0fae1b1 Signed-off-by: Peter Collingbourne Acked-by: Will Deacon Cc: Ard Biesheuvel Cc: Catalin Marinas Link: https://lore.kernel.org/r/20220719234909.1398992-1-pcc@google.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/arm64/include/asm/kernel-pgtable.h | 4 ++-- arch/arm64/kernel/head.S | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) --- a/arch/arm64/include/asm/kernel-pgtable.h +++ b/arch/arm64/include/asm/kernel-pgtable.h @@ -103,8 +103,8 @@ /* * Initial memory map attributes. */ -#define SWAPPER_PTE_FLAGS (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED) -#define SWAPPER_PMD_FLAGS (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S) +#define SWAPPER_PTE_FLAGS (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED | PTE_UXN) +#define SWAPPER_PMD_FLAGS (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S | PMD_= SECT_UXN) =20 #if ARM64_KERNEL_USES_PMD_MAPS #define SWAPPER_MM_MMUFLAGS (PMD_ATTRINDX(MT_NORMAL) | SWAPPER_PMD_FLAGS) --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -285,7 +285,7 @@ SYM_FUNC_START_LOCAL(__create_page_table subs x1, x1, #64 b.ne 1b =20 - mov x7, SWAPPER_MM_MMUFLAGS + mov_q x7, SWAPPER_MM_MMUFLAGS =20 /* * Create the identity mapping. From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 711DBC19F2D for ; Tue, 9 Aug 2022 18:24:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343975AbiHISYN (ORCPT ); Tue, 9 Aug 2022 14:24:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347204AbiHISV7 (ORCPT ); Tue, 9 Aug 2022 14:21:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 012043191F; Tue, 9 Aug 2022 11:08:25 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E5B04B81998; Tue, 9 Aug 2022 18:07:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38A15C433B5; Tue, 9 Aug 2022 18:07:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068440; bh=uOqmvHyVPGr4OzJcrboci6revzGPg2fVNA1CygeyDr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FGe208FmTZPJkzZhWox2qy1K46oP4rcZv5k+ELZZDLhLm4F4bjYY7fieA2FQ4cdew nmUp1r66NLdKq0R5PhJg/m0ph5mJWzbbgdQ1+KlbCztJp3jBADXjKHyEltrXCEBNyl UtcWJ3cBY0+OGtkIPxMuhVMks1l3dyTvNdwWZ8XY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Naohiro Aota , David Sterba Subject: [PATCH 5.18 20/35] btrfs: zoned: prevent allocation from previous data relocation BG Date: Tue, 9 Aug 2022 20:00:49 +0200 Message-Id: <20220809175515.790452677@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naohiro Aota commit 343d8a30851c48a4ef0f5ef61d5e9fbd847a6883 upstream. After commit 5f0addf7b890 ("btrfs: zoned: use dedicated lock for data relocation"), we observe IO errors on e.g, btrfs/232 like below. [09.0][T4038707] WARNING: CPU: 3 PID: 4038707 at fs/btrfs/extent-tree.c:2= 381 btrfs_cross_ref_exist+0xfc/0x120 [btrfs] [09.9][T4038707] Call Trace: [09.5][T4038707] [09.3][T4038707] run_delalloc_nocow+0x7f1/0x11a0 [btrfs] [09.6][T4038707] ? test_range_bit+0x174/0x320 [btrfs] [09.2][T4038707] ? fallback_to_cow+0x980/0x980 [btrfs] [09.3][T4038707] ? find_lock_delalloc_range+0x33e/0x3e0 [btrfs] [09.5][T4038707] btrfs_run_delalloc_range+0x445/0x1320 [btrfs] [09.2][T4038707] ? test_range_bit+0x320/0x320 [btrfs] [09.4][T4038707] ? lock_downgrade+0x6a0/0x6a0 [09.2][T4038707] ? orc_find.part.0+0x1ed/0x300 [09.5][T4038707] ? __module_address.part.0+0x25/0x300 [09.0][T4038707] writepage_delalloc+0x159/0x310 [btrfs] [09.4][ C3] sd 10:0:1:0: [sde] tag#2620 FAILED Result: hostbyte=3DDID_= OK driverbyte=3DDRIVER_OK cmd_age=3D0s [09.5][ C3] sd 10:0:1:0: [sde] tag#2620 Sense Key : Illegal Request [c= urrent] [09.9][ C3] sd 10:0:1:0: [sde] tag#2620 Add. Sense: Unaligned write co= mmand [09.5][ C3] sd 10:0:1:0: [sde] tag#2620 CDB: Write(16) 8a 00 00 00 00 = 00 02 f3 63 87 00 00 00 2c 00 00 [09.4][ C3] critical target error, dev sde, sector 396041272 op 0x1:(W= RITE) flags 0x800 phys_seg 3 prio class 0 [09.9][ C3] BTRFS error (device dm-1): bdev /dev/mapper/dml_102_2 errs= : wr 1, rd 0, flush 0, corrupt 0, gen 0 The IO errors occur when we allocate a regular extent in previous data relocation block group. On zoned btrfs, we use a dedicated block group to relocate a data extent. Thus, we allocate relocating data extents (pre-alloc) only from the dedicated block group and vice versa. Once the free space in the dedicated block group gets tight, a relocating extent may not fit into the block group. In that case, we need to switch the dedicated block group to the next one. Then, the previous one is now freed up for allocating a regular extent. The BG is already not enough to allocate the relocating extent, but there is still room to allocate a smaller extent. Now the problem happens. By allocating a regular extent while nocow IOs for the relocation is still on-going, we will issue WRITE IOs (for relocation) and ZONE APPEND IOs (for the regular writes) at the same time. That mixed IOs confuses the write pointer and arises the unaligned write errors. This commit introduces a new bit 'zoned_data_reloc_ongoing' to the btrfs_block_group. We set this bit before releasing the dedicated block group, and no extent are allocated from a block group having this bit set. This bit is similar to setting block_group->ro, but is different from it by allowing nocow writes to start. Once all the nocow IO for relocation is done (hooked from btrfs_finish_ordered_io), we reset the bit to release the block group for further allocation. Fixes: c2707a255623 ("btrfs: zoned: add a dedicated data relocation block g= roup") CC: stable@vger.kernel.org # 5.16+ Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/block-group.h | 1 + fs/btrfs/extent-tree.c | 20 ++++++++++++++++++-- fs/btrfs/inode.c | 2 ++ fs/btrfs/zoned.c | 27 +++++++++++++++++++++++++++ fs/btrfs/zoned.h | 5 +++++ 5 files changed, 53 insertions(+), 2 deletions(-) --- a/fs/btrfs/block-group.h +++ b/fs/btrfs/block-group.h @@ -104,6 +104,7 @@ struct btrfs_block_group { unsigned int relocating_repair:1; unsigned int chunk_item_inserted:1; unsigned int zone_is_active:1; + unsigned int zoned_data_reloc_ongoing:1; =20 int disk_cache_state; =20 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3836,7 +3836,7 @@ static int do_allocation_zoned(struct bt block_group->start =3D=3D fs_info->data_reloc_bg || fs_info->data_reloc_bg =3D=3D 0); =20 - if (block_group->ro) { + if (block_group->ro || block_group->zoned_data_reloc_ongoing) { ret =3D 1; goto out; } @@ -3898,8 +3898,24 @@ static int do_allocation_zoned(struct bt out: if (ret && ffe_ctl->for_treelog) fs_info->treelog_bg =3D 0; - if (ret && ffe_ctl->for_data_reloc) + if (ret && ffe_ctl->for_data_reloc && + fs_info->data_reloc_bg =3D=3D block_group->start) { + /* + * Do not allow further allocations from this block group. + * Compared to increasing the ->ro, setting the + * ->zoned_data_reloc_ongoing flag still allows nocow + * writers to come in. See btrfs_inc_nocow_writers(). + * + * We need to disable an allocation to avoid an allocation of + * regular (non-relocation data) extent. With mix of relocation + * extents and regular extents, we can dispatch WRITE commands + * (for relocation extents) and ZONE APPEND commands (for + * regular extents) at the same time to the same zone, which + * easily break the write pointer. + */ + block_group->zoned_data_reloc_ongoing =3D 1; fs_info->data_reloc_bg =3D 0; + } spin_unlock(&fs_info->relocation_bg_lock); spin_unlock(&fs_info->treelog_bg_lock); spin_unlock(&block_group->lock); --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3102,6 +3102,8 @@ static int btrfs_finish_ordered_io(struc ordered_extent->file_offset, ordered_extent->file_offset + logical_len); + btrfs_zoned_release_data_reloc_bg(fs_info, ordered_extent->disk_bytenr, + ordered_extent->disk_num_bytes); } else { BUG_ON(root =3D=3D fs_info->tree_root); ret =3D insert_ordered_extent_file_extent(trans, ordered_extent); --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -2116,3 +2116,30 @@ void btrfs_free_zone_cache(struct btrfs_ } mutex_unlock(&fs_devices->device_list_mutex); } + +void btrfs_zoned_release_data_reloc_bg(struct btrfs_fs_info *fs_info, u64 = logical, + u64 length) +{ + struct btrfs_block_group *block_group; + + if (!btrfs_is_zoned(fs_info)) + return; + + block_group =3D btrfs_lookup_block_group(fs_info, logical); + /* It should be called on a previous data relocation block group. */ + ASSERT(block_group && (block_group->flags & BTRFS_BLOCK_GROUP_DATA)); + + spin_lock(&block_group->lock); + if (!block_group->zoned_data_reloc_ongoing) + goto out; + + /* All relocation extents are written. */ + if (block_group->start + block_group->alloc_offset =3D=3D logical + lengt= h) { + /* Now, release this block group for further allocations. */ + block_group->zoned_data_reloc_ongoing =3D 0; + } + +out: + spin_unlock(&block_group->lock); + btrfs_put_block_group(block_group); +} --- a/fs/btrfs/zoned.h +++ b/fs/btrfs/zoned.h @@ -80,6 +80,8 @@ void btrfs_schedule_zone_finish_bg(struc struct extent_buffer *eb); void btrfs_clear_data_reloc_bg(struct btrfs_block_group *bg); void btrfs_free_zone_cache(struct btrfs_fs_info *fs_info); +void btrfs_zoned_release_data_reloc_bg(struct btrfs_fs_info *fs_info, u64 = logical, + u64 length); #else /* CONFIG_BLK_DEV_ZONED */ static inline int btrfs_get_dev_zone(struct btrfs_device *device, u64 pos, struct blk_zone *zone) @@ -241,6 +243,9 @@ static inline void btrfs_schedule_zone_f static inline void btrfs_clear_data_reloc_bg(struct btrfs_block_group *bg)= { } =20 static inline void btrfs_free_zone_cache(struct btrfs_fs_info *fs_info) { } + +static inline void btrfs_zoned_release_data_reloc_bg(struct btrfs_fs_info = *fs_info, + u64 logical, u64 length) { } #endif =20 static inline bool btrfs_dev_is_sequential(struct btrfs_device *device, u6= 4 pos) From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18315C19F2D for ; Tue, 9 Aug 2022 18:24:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344318AbiHISYZ (ORCPT ); Tue, 9 Aug 2022 14:24:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347327AbiHISWU (ORCPT ); Tue, 9 Aug 2022 14:22:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9198631DC4; Tue, 9 Aug 2022 11:08:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8D852B8199A; Tue, 9 Aug 2022 18:07:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAE7AC43470; Tue, 9 Aug 2022 18:07:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068443; bh=ywVLN2ma4MVkAmTR58UKcULnKrwma1toTjcHNXw3Wbg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OId86UbL5sY1lR91qK20OFi+3IZ+VZ8TzILrQ9/OWGlIJAg9M+BBV9hREpvMw9/Zl NFCTJceaImhC7xl7i4/qYblNQEcCKTmvbhTDEjkoZD+2bPZCjWdcVIz8ZJ6Nu1mTHr IREZYooR9o3Ipi1ovjWBFalhTgg1TSZfuo0mpKhY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Johannes Thumshirn , Naohiro Aota , David Sterba Subject: [PATCH 5.18 21/35] btrfs: zoned: fix critical section of relocation inode writeback Date: Tue, 9 Aug 2022 20:00:50 +0200 Message-Id: <20220809175515.832622102@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naohiro Aota commit 19ab78ca86981e0e1e73036fb73a508731a7c078 upstream. We use btrfs_zoned_data_reloc_{lock,unlock} to allow only one process to write out to the relocation inode. That critical section must include all the IO submission for the inode. However, flush_write_bio() in extent_writepages() is out of the critical section, causing an IO submission outside of the lock. This leads to an out of the order IO submission and fail the relocation process. Fix it by extending the critical section. Fixes: 35156d852762 ("btrfs: zoned: only allow one process to add pages to = a relocation inode") CC: stable@vger.kernel.org # 5.16+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/extent_io.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -5214,13 +5214,14 @@ int extent_writepages(struct address_spa */ btrfs_zoned_data_reloc_lock(BTRFS_I(inode)); ret =3D extent_write_cache_pages(mapping, wbc, &epd); - btrfs_zoned_data_reloc_unlock(BTRFS_I(inode)); ASSERT(ret <=3D 0); if (ret < 0) { + btrfs_zoned_data_reloc_unlock(BTRFS_I(inode)); end_write_bio(&epd, ret); return ret; } ret =3D flush_write_bio(&epd); + btrfs_zoned_data_reloc_unlock(BTRFS_I(inode)); return ret; } From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43532C19F2D for ; Tue, 9 Aug 2022 18:24:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242549AbiHISYo (ORCPT ); Tue, 9 Aug 2022 14:24:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347402AbiHISW1 (ORCPT ); Tue, 9 Aug 2022 14:22:27 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDCDC31DE6; Tue, 9 Aug 2022 11:08:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5FC52B818C2; Tue, 9 Aug 2022 18:07:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA402C4347C; Tue, 9 Aug 2022 18:07:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068446; bh=bTdcFfwKJ/nbB6gJvzfhysdQBts1d5oaJWWzgVsCDuc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ad0hxGuRVBjomg6S32i3X4fc2BK673vrekKy8Ux8EXJP6zTCwzvine9L6HdY4rs7V 1/wJsMyyAAyYHCCHHN9+h5njZOyqHSCo/UO4tQEJR1Xx9tcpF/WCHhrNXN3QWWyhr/ RVOrTFZry03UEVx7reE2fYc5YQfp9DFuYw8EoZ4Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Johannes Thumshirn , Naohiro Aota , David Sterba Subject: [PATCH 5.18 22/35] btrfs: zoned: drop optimization of zone finish Date: Tue, 9 Aug 2022 20:00:51 +0200 Message-Id: <20220809175515.877774133@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naohiro Aota commit b3a3b0255797e1d395253366ba24a4cc6c8bdf9c upstream. We have an optimization in do_zone_finish() to send REQ_OP_ZONE_FINISH only when necessary, i.e. we don't send REQ_OP_ZONE_FINISH when we assume we wrote fully into the zone. The assumption is determined by "alloc_offset =3D=3D capacity". This condit= ion won't work if the last ordered extent is canceled due to some errors. In that case, we consider the zone is deactivated without sending the finish command while it's still active. This inconstancy results in activating another block group while we cannot really activate the underlying zone, which causes the active zone exceeds errors like below. BTRFS error (device nvme3n2): allocation failed flags 1, wanted 520192 = tree-log 0, relocation: 0 nvme3n2: I/O Cmd(0x7d) @ LBA 160432128, 127 blocks, I/O Error (sct 0x1 = / sc 0xbd) MORE DNR active zones exceeded error, dev nvme3n2, sector 0 op 0xd:(ZONE_APPEND)= flags 0x4800 phys_seg 1 prio class 0 nvme3n2: I/O Cmd(0x7d) @ LBA 160432128, 127 blocks, I/O Error (sct 0x1 = / sc 0xbd) MORE DNR active zones exceeded error, dev nvme3n2, sector 0 op 0xd:(ZONE_APPEND)= flags 0x4800 phys_seg 1 prio class 0 Fix the issue by removing the optimization for now. Fixes: 8376d9e1ed8f ("btrfs: zoned: finish superblock zone once no space le= ft for new SB") Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/btrfs/zoned.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -2005,6 +2005,7 @@ void btrfs_zone_finish_endio(struct btrf struct btrfs_device *device; u64 min_alloc_bytes; u64 physical; + int i; =20 if (!btrfs_is_zoned(fs_info)) return; @@ -2039,13 +2040,25 @@ void btrfs_zone_finish_endio(struct btrf spin_unlock(&block_group->lock); =20 map =3D block_group->physical_map; - device =3D map->stripes[0].dev; - physical =3D map->stripes[0].physical; + for (i =3D 0; i < map->num_stripes; i++) { + int ret; =20 - if (!device->zone_info->max_active_zones) - goto out; + device =3D map->stripes[i].dev; + physical =3D map->stripes[i].physical; + + if (device->zone_info->max_active_zones =3D=3D 0) + continue; + + ret =3D blkdev_zone_mgmt(device->bdev, REQ_OP_ZONE_FINISH, + physical >> SECTOR_SHIFT, + device->zone_info->zone_size >> SECTOR_SHIFT, + GFP_NOFS); =20 - btrfs_dev_clear_active_zone(device, physical); + if (ret) + return; + + btrfs_dev_clear_active_zone(device, physical); + } =20 spin_lock(&fs_info->zone_active_bgs_lock); ASSERT(!list_empty(&block_group->active_bg_list)); From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99DA0C19F2D for ; Tue, 9 Aug 2022 18:27:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344605AbiHISZi (ORCPT ); Tue, 9 Aug 2022 14:25:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343519AbiHISWq (ORCPT ); Tue, 9 Aug 2022 14:22:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 225D52872F; Tue, 9 Aug 2022 11:08:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 77DB2B818AF; Tue, 9 Aug 2022 18:07:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD804C43470; Tue, 9 Aug 2022 18:07:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068449; bh=+vJskcDitlf+1EjDn+hcxj0rA5Uriic/6Rh7abIhVGg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HcjxM2kdhGzmGU0HrLOpyZVHn0n87U+7dyBxtWzApnbevO7FapOb7A78NdRRVeCoS j0JwRcVh+Q5/vryHQ8oEFPTH1OgERfTBnBPWeXLQxf6LeF7cmKmI4MS6huWCARmdPK YJ8Di90m3+4nzmNh4DlquJY0l+UXesXymxKZhptk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sai Teja Aluvala , Marcel Holtmann Subject: [PATCH 5.18 23/35] Bluetooth: hci_qca: Return wakeup for qca_wakeup Date: Tue, 9 Aug 2022 20:00:52 +0200 Message-Id: <20220809175515.907662332@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Sai Teja Aluvala commit bde63e9effd3a6ba384707c62abe46c32d22f665 upstream. This fixes the return value of qca_wakeup(), since .wakeup work inversely with original .prevent_wake. Fixes: 4539ca67fe8ed (Bluetooth: Rename driver .prevent_wake to .wakeup) Signed-off-by: Sai Teja Aluvala Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/hci_qca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index eab34e24d944..8df11016fd51 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1588,7 +1588,7 @@ static bool qca_wakeup(struct hci_dev *hdev) wakeup =3D device_may_wakeup(hu->serdev->ctrl->dev.parent); bt_dev_dbg(hu->hdev, "wakeup status : %d", wakeup); =20 - return !wakeup; + return wakeup; } =20 static int qca_regulator_init(struct hci_uart *hu) --=20 2.37.1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D2BBC25B0C for ; Tue, 9 Aug 2022 18:23:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343807AbiHISXD (ORCPT ); Tue, 9 Aug 2022 14:23:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346094AbiHISUx (ORCPT ); Tue, 9 Aug 2022 14:20:53 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 909B62FFCC; Tue, 9 Aug 2022 11:07:47 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7319DB8190F; Tue, 9 Aug 2022 18:06:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF5E3C43470; Tue, 9 Aug 2022 18:06:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068418; bh=cGoSbcBMNOOEJ6uxE2E5jK3xAT+bVsyN8dNDllw4yW0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P0Do+lXjTmhxxcdPlk/7L2+IqzNBQUqM0gHQPS8OPMl/DV/P67z+eXUKCI78jFBcs cIUfHSONaLTjwtKIOZ40qp8+wYgXCoEtxhul+6PEYwPSVYDIP4nBheVYiYl7W+satM SWN2JMxgVzZsBrOds4RpBk75pqLIEr6oXbNWkMk4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ahmad Fatoum , Linus Walleij , Marcel Holtmann Subject: [PATCH 5.18 24/35] Bluetooth: hci_bcm: Add BCM4349B1 variant Date: Tue, 9 Aug 2022 20:00:53 +0200 Message-Id: <20220809175515.952454036@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ahmad Fatoum commit 4f17c2b6694d0c4098f33b07ee3a696976940aa5 upstream. The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Two subversions are added for the chip, because ROM firmware reports 002.002.013 (at least for the chips I have here), while depending on patchram firmware revision, either 002.002.013 or 002.002.014 is reported. Signed-off-by: Ahmad Fatoum Reviewed-by: Linus Walleij Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btbcm.c | 2 ++ drivers/bluetooth/hci_bcm.c | 1 + 2 files changed, 3 insertions(+) --- a/drivers/bluetooth/btbcm.c +++ b/drivers/bluetooth/btbcm.c @@ -453,6 +453,8 @@ static const struct bcm_subver_table bcm { 0x6606, "BCM4345C5" }, /* 003.006.006 */ { 0x230f, "BCM4356A2" }, /* 001.003.015 */ { 0x220e, "BCM20702A1" }, /* 001.002.014 */ + { 0x420d, "BCM4349B1" }, /* 002.002.013 */ + { 0x420e, "BCM4349B1" }, /* 002.002.014 */ { 0x4217, "BCM4329B1" }, /* 002.002.023 */ { 0x6106, "BCM4359C0" }, /* 003.001.006 */ { 0x4106, "BCM4335A0" }, /* 002.001.006 */ --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -1544,6 +1544,7 @@ static const struct of_device_id bcm_blu { .compatible =3D "brcm,bcm43430a0-bt" }, { .compatible =3D "brcm,bcm43430a1-bt" }, { .compatible =3D "brcm,bcm43438-bt", .data =3D &bcm43438_device_data }, + { .compatible =3D "brcm,bcm4349-bt", .data =3D &bcm43438_device_data }, { .compatible =3D "brcm,bcm43540-bt", .data =3D &bcm4354_device_data }, { .compatible =3D "brcm,bcm4335a0" }, { }, From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31F27C19F2D for ; Tue, 9 Aug 2022 18:23:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343862AbiHISXJ (ORCPT ); Tue, 9 Aug 2022 14:23:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346206AbiHISU5 (ORCPT ); Tue, 9 Aug 2022 14:20:57 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9486130F49; Tue, 9 Aug 2022 11:07:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3AE42B81913; Tue, 9 Aug 2022 18:07:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83509C433D7; Tue, 9 Aug 2022 18:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068420; bh=HTT+0szE6QFagNjHa5lguAMblNs0baFDZDBvsdoAhl8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GeTcCw0O45ndAUa0yyl6UXUGSbEMqQb4o54HVG0+FpAh/8nFCwVCHtCrT/NLQIOfq k+CmTqAU2E6McEPaKWEW0qUBQ7ftjYbwG0A/nhp5A1URYjvl3cju1gDivjmlCy3LhY rvohSPvMnecMkkVjl3Y9y+C2V28J6NkQ8xXZUVQQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hakan Jansson , Linus Walleij , Luiz Augusto von Dentz Subject: [PATCH 5.18 25/35] Bluetooth: hci_bcm: Add DT compatible for CYW55572 Date: Tue, 9 Aug 2022 20:00:54 +0200 Message-Id: <20220809175515.983312516@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hakan Jansson commit f8cad62002a7699fd05a23b558b980b5a77defe0 upstream. CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon. Signed-off-by: Hakan Jansson Reviewed-by: Linus Walleij Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/hci_bcm.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -1547,6 +1547,7 @@ static const struct of_device_id bcm_blu { .compatible =3D "brcm,bcm4349-bt", .data =3D &bcm43438_device_data }, { .compatible =3D "brcm,bcm43540-bt", .data =3D &bcm4354_device_data }, { .compatible =3D "brcm,bcm4335a0" }, + { .compatible =3D "infineon,cyw55572-bt" }, { }, }; MODULE_DEVICE_TABLE(of, bcm_bluetooth_of_match); From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 047EEC19F2D for ; Tue, 9 Aug 2022 18:24:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343943AbiHISYd (ORCPT ); Tue, 9 Aug 2022 14:24:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346443AbiHISVJ (ORCPT ); Tue, 9 Aug 2022 14:21:09 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9752930F7A; Tue, 9 Aug 2022 11:07:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0D9BAB817AE; Tue, 9 Aug 2022 18:07:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58D6EC43470; Tue, 9 Aug 2022 18:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068423; bh=Taysnb1prxfCv9T/91n/QGNd8Cyr03FyNjTTbZNsz2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YHe0e1F9OpsXoqmnVO8DIQGTPwiqlBK9UTfcmLnYWCaKbDMS1L7nwwvywoff54Rzf 5w/ztdtYcB78TMBqMKszQxH61pgMCtZSfyYBaUbaHAhD4btgpnDNY5IwUd/q+oycEP dogwt8jxU5LilKSnNbfTf+mV1eQVRnT9WVE0z+Qw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Krzysztof Kozlowski , Linus Walleij , Ahmad Fatoum , Marcel Holtmann Subject: [PATCH 5.18 26/35] dt-bindings: bluetooth: broadcom: Add BCM4349B1 DT binding Date: Tue, 9 Aug 2022 20:00:55 +0200 Message-Id: <20220809175516.023780646@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ahmad Fatoum commit 88b65887aa1b76cd8649a97824fb9904c1d79254 upstream. The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Extend the binding with its DT compatible. Acked-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Signed-off-by: Ahmad Fatoum Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml | 1 + 1 file changed, 1 insertion(+) --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -23,6 +23,7 @@ properties: - brcm,bcm4345c5 - brcm,bcm43540-bt - brcm,bcm4335a0 + - brcm,bcm4349-bt =20 shutdown-gpios: maxItems: 1 From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E29AC19F2D for ; Tue, 9 Aug 2022 18:23:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343830AbiHISXr (ORCPT ); Tue, 9 Aug 2022 14:23:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346614AbiHISVS (ORCPT ); Tue, 9 Aug 2022 14:21:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F8C230F4D; Tue, 9 Aug 2022 11:08:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BFB1DB81928; Tue, 9 Aug 2022 18:07:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18F18C43470; Tue, 9 Aug 2022 18:07:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068426; bh=CWNgJ/mRgt3f1gIIywjLR7FYwNO5xLv+kG2ApKVF4O4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qtQJz8272wSdk0l7eojlrpTmCW/ZcSO18/LSzJcXtIT8IuHq2haaF6924zg1MQcJa Dfkj9D5wA/H9MSnbY3MN6nA0j8AcwqvLcSksIZcwZG25lRdK9OXcrYieg86TywdOeR H2SLK+kwKTvwmKs+J5ryreuC1qPrHqt7XZ+tY/zg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Aaron Ma , Marcel Holtmann Subject: [PATCH 5.18 27/35] Bluetooth: btusb: Add support of IMC Networks PID 0x3568 Date: Tue, 9 Aug 2022 20:00:56 +0200 Message-Id: <20220809175516.054785926@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Aaron Ma commit c69ecb0ea4c96b8b191cbaa0b420222a37867655 upstream. It is 13d3:3568 for MediaTek MT7922 USB Bluetooth chip. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D01 Dev#=3D 2 Spd=3D480 MxC= h=3D 0 D: Ver=3D 2.10 Cls=3Def(misc ) Sub=3D02 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D13d3 ProdID=3D3568 Rev=3D01.00 S: Manufacturer=3DMediaTek Inc. S: Product=3DWireless_Device S: SerialNumber=3D... C: #Ifs=3D 3 Cfg#=3D 1 Atr=3De0 MxPwr=3D100mA I: If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D125us E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 512 Ivl=3D0ms I: If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 2 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D0a(O) Atr=3D03(Int.) MxPS=3D 64 Ivl=3D125us E: Ad=3D8a(I) Atr=3D03(Int.) MxPS=3D 64 Ivl=3D125us Signed-off-by: Aaron Ma Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btusb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -469,6 +469,9 @@ static const struct usb_device_id blackl { USB_DEVICE(0x0489, 0xe0d9), .driver_info =3D BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH | BTUSB_VALID_LE_STATES }, + { USB_DEVICE(0x13d3, 0x3568), .driver_info =3D BTUSB_MEDIATEK | + BTUSB_WIDEBAND_SPEECH | + BTUSB_VALID_LE_STATES }, =20 /* Additional Realtek 8723AE Bluetooth devices */ { USB_DEVICE(0x0930, 0x021d), .driver_info =3D BTUSB_REALTEK }, From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56D52C19F2D for ; Tue, 9 Aug 2022 18:30:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344127AbiHISaB (ORCPT ); Tue, 9 Aug 2022 14:30:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346878AbiHIS0n (ORCPT ); Tue, 9 Aug 2022 14:26:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 402AF26AC4; Tue, 9 Aug 2022 11:09:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0AEEAB819FE; Tue, 9 Aug 2022 18:07:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 575F9C43142; Tue, 9 Aug 2022 18:07:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068473; bh=2qF/kK6RRTDUlVEb+7Biig8eUepMNHqNOn3cahipYnI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wUakgvzWteBoXeIQP2NuIbFRh2Fz1yBENaPXUjiIWBOU3w3b0bBBM5lA2okNoACKI jYUy5N2yPhCTtS9XgqBNoQwKcz3RmcHp9B80bJm5zoMQ5Qe/adpoh2/slGby4mtzrc aBKLtK0VXBeuOLn7pC2eRqL6izSYtH+BlRowSCPI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hilda Wu , Luiz Augusto von Dentz Subject: [PATCH 5.18 28/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04CA:0x4007 Date: Tue, 9 Aug 2022 20:00:57 +0200 Message-Id: <20220809175516.096951692@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hilda Wu commit c379c96cc221767af9688a5d4758a78eea30883a upstream. Add the support ID(0x04CA, 0x4007) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D01 Dev#=3D 2 Spd=3D12 Mx= Ch=3D 0 D: Ver=3D 1.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D04ca ProdID=3D4007 Rev=3D 0.00 S: Manufacturer=3DRealtek S: Product=3DBluetooth Radio S: SerialNumber=3D00e04c000001 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D500mA I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms Signed-off-by: Hilda Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btusb.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -422,6 +422,10 @@ static const struct usb_device_id blackl { USB_DEVICE(0x04ca, 0x4006), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, =20 + /* Realtek 8852CE Bluetooth devices */ + { USB_DEVICE(0x04ca, 0x4007), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, + /* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01), .driver_info =3D BTUSB_REALTEK }, From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 178AEC19F2D for ; Tue, 9 Aug 2022 18:25:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245669AbiHISZc (ORCPT ); Tue, 9 Aug 2022 14:25:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343680AbiHISX5 (ORCPT ); Tue, 9 Aug 2022 14:23:57 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD28A3207E; Tue, 9 Aug 2022 11:08:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D33EAB818A4; Tue, 9 Aug 2022 18:07:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E0D1C433D6; Tue, 9 Aug 2022 18:07:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068454; bh=XOZonHpnPLoxWjir9XnHleFqm42CLckIlkVZmh2+kSs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MbGIYwIOR8ll5Td3vPuXBEs8oryzC3ULV58Xp82JDKIO9mIPZDe16XaKG39NJNHNG cBGWNbm/X/7XSn8S8ivj8UcPLxckEK8SmcIhqG0r0LqBhspRtwxCAp8Z3yqmXlT/Mk JGZxYkYDqvvX+DAxmwTo6qhRehMtYfmLy+Fn5Fcw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hilda Wu , Luiz Augusto von Dentz Subject: [PATCH 5.18 29/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04C5:0x1675 Date: Tue, 9 Aug 2022 20:00:58 +0200 Message-Id: <20220809175516.135240859@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hilda Wu commit 893fa8bc9952a36fb682ee12f0a994b5817a36d2 upstream. Add the support ID(0x04c5, 0x1675) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D01 Dev#=3D 2 Spd=3D12 Mx= Ch=3D 0 D: Ver=3D 1.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D04c5 ProdID=3D1675 Rev=3D 0.00 S: Manufacturer=3DRealtek S: Product=3DBluetooth Radio S: SerialNumber=3D00e04c000001 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D500mA I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms Signed-off-by: Hilda Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -425,6 +425,8 @@ static const struct usb_device_id blackl /* Realtek 8852CE Bluetooth devices */ { USB_DEVICE(0x04ca, 0x4007), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x04c5, 0x1675), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, =20 /* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01), From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D422BC19F2D for ; Tue, 9 Aug 2022 18:27:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345016AbiHISZl (ORCPT ); Tue, 9 Aug 2022 14:25:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343984AbiHISYR (ORCPT ); Tue, 9 Aug 2022 14:24:17 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 346B2326E4; Tue, 9 Aug 2022 11:08:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7FA7FB818A6; Tue, 9 Aug 2022 18:07:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA708C433B5; Tue, 9 Aug 2022 18:07:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068457; bh=7Ho4AkDkIrwPpDOrcmHB2PFQcaeUG0/d0k5VAxr7MrY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D4d88PkHS+c5NexDJalSLIcRKD/3BgXcsZYnN1X0CsrodptFSNn0wNzzDZ3uioyNv AhJ1aRL3/zuhx0EkCtnGSaiE24nNEaIhIzoZggqOR85BhhV3VcSkyUZ1k0tO5/NJTQ YlZqjxqJRA7NusfmuX1H2fyGiTeg9Oo+5gSmHdog= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hilda Wu , Luiz Augusto von Dentz Subject: [PATCH 5.18 30/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0CB8:0xC558 Date: Tue, 9 Aug 2022 20:00:59 +0200 Message-Id: <20220809175516.181509561@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hilda Wu commit 5b75ee37ebb73f58468d4cca172434324af203f1 upstream. Add the support ID(0x0CB8, 0xC558) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D01 Dev#=3D 2 Spd=3D12 Mx= Ch=3D 0 D: Ver=3D 1.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D0cb8 ProdID=3Dc558 Rev=3D 0.00 S: Manufacturer=3DRealtek S: Product=3DBluetooth Radio S: SerialNumber=3D00e04c000001 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D500mA I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms Signed-off-by: Hilda Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -427,6 +427,8 @@ static const struct usb_device_id blackl BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x04c5, 0x1675), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x0cb8, 0xc558), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, =20 /* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01), From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7E0AC19F2D for ; Tue, 9 Aug 2022 18:27:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245531AbiHIS1m (ORCPT ); Tue, 9 Aug 2022 14:27:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344910AbiHISZj (ORCPT ); Tue, 9 Aug 2022 14:25:39 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9733426556; Tue, 9 Aug 2022 11:09:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 51620B819C5; Tue, 9 Aug 2022 18:07:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 954C7C4347C; Tue, 9 Aug 2022 18:07:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068460; bh=/xSNsz0Q1xGn6Qbi383yTTpVSzDSSlwYNkntV2cf7O8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WPG52E22WW8jI0sFzUhzjpEArOtKKiEBZPSG/6s5hsqTla7e0QIsyhM4wBGP3NhhO h16BhOXLpJa4/v7dKRJmVx0FTmCNwo1cQV2vMkks+8XMFcerk9nRjsxydSNiHTyYQw 2ffZ9rl86M36w+7zVTLmTF48EgiGSenlmBLR+hRE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hilda Wu , Luiz Augusto von Dentz Subject: [PATCH 5.18 31/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3587 Date: Tue, 9 Aug 2022 20:01:00 +0200 Message-Id: <20220809175516.227417756@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hilda Wu commit 8f0054dd29373cd877db87751c143610561d549d upstream. Add the support ID(0x13D3, 0x3587) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D01 Dev#=3D 2 Spd=3D12 Mx= Ch=3D 0 D: Ver=3D 1.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D13d3 ProdID=3D3587 Rev=3D 0.00 S: Manufacturer=3DRealtek S: Product=3DBluetooth Radio S: SerialNumber=3D00e04c000001 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D500mA I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms Signed-off-by: Hilda Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -429,6 +429,8 @@ static const struct usb_device_id blackl BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0cb8, 0xc558), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3587), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, =20 /* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01), From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E88CC19F2D for ; Tue, 9 Aug 2022 18:28:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343818AbiHIS1t (ORCPT ); Tue, 9 Aug 2022 14:27:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345487AbiHISZr (ORCPT ); Tue, 9 Aug 2022 14:25:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 873072873C; Tue, 9 Aug 2022 11:09:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 23DBCB81895; Tue, 9 Aug 2022 18:07:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A400C433D7; Tue, 9 Aug 2022 18:07:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068462; bh=JRHQuuj8Ui0F1dR8M9LdTpFl6yAg8cKXNWkoKDelFbA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tGNJMsUNKEb21GAu2MkVMVf8qG4zbNYonHhkb4nj5yE8kslAObpFKkzkTqcjgYMdg 61g/L+UaBUGqOeJapAE9r/v08yqbodJDTcxNT7qqaUHVqUI/EU9OI+WfmVDJ+7Jn2o 2ClR6/FYAO82tII2YLUqWGcjQUlWLnEgefYQyc7o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hilda Wu , Luiz Augusto von Dentz Subject: [PATCH 5.18 32/35] Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3586 Date: Tue, 9 Aug 2022 20:01:01 +0200 Message-Id: <20220809175516.279445309@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hilda Wu commit 6ad353dfc8ee3230a5e123c21da50f1b64cc4b39 upstream. Add the support ID(0x13D3, 0x3586) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=3D03 Lev=3D01 Prnt=3D01 Port=3D02 Cnt=3D01 Dev#=3D 2 Spd=3D12 Mx= Ch=3D 0 D: Ver=3D 1.00 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D13d3 ProdID=3D3586 Rev=3D 0.00 S: Manufacturer=3DRealtek S: Product=3DBluetooth Radio S: SerialNumber=3D00e04c000001 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3De0 MxPwr=3D500mA I:* If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I:* If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(wlcon) Sub=3D01 Prot=3D01 Driver= =3Dbtusb E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms Signed-off-by: Hilda Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -431,6 +431,8 @@ static const struct usb_device_id blackl BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3587), .driver_info =3D BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3586), .driver_info =3D BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, =20 /* Realtek Bluetooth devices */ { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01), From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB932C25B07 for ; Tue, 9 Aug 2022 18:28:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344038AbiHIS2k (ORCPT ); Tue, 9 Aug 2022 14:28:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346345AbiHIS0O (ORCPT ); Tue, 9 Aug 2022 14:26:14 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27C4A26AC9; Tue, 9 Aug 2022 11:09:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D1039B819D6; Tue, 9 Aug 2022 18:07:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A4EDC433D6; Tue, 9 Aug 2022 18:07:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068465; bh=e+Sqdz09GdVHe1dlbhbcgQasCVxSYIYnh6jIqbIAANo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=STYuDiLOv4B42TuwZGsyE94cBqJZEs0ma2qnzrRION+9X/7vJuzyCUfem7ZNAzPrs Fa1+yZMkksUaoW4elSWGRgEaEITt5F1mjUF6W8IrlDgMoOacbtOaWTJzhQvKZ67a7t Siq8ZiWWbFqww8W5q7P5Ao2FBJqBZ50FZ+3ud4/0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable , Ning Qiang , Kees Cook , Benjamin Herrenschmidt , Michael Ellerman Subject: [PATCH 5.18 33/35] macintosh/adb: fix oob read in do_adb_query() function Date: Tue, 9 Aug 2022 20:01:02 +0200 Message-Id: <20220809175516.328338947@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ning Qiang commit fd97e4ad6d3b0c9fce3bca8ea8e6969d9ce7423b upstream. In do_adb_query() function of drivers/macintosh/adb.c, req->data is copied form userland. The parameter "req->data[2]" is missing check, the array size of adb_handler[] is 16, so adb_handler[req->data[2]].original_address = and adb_handler[req->data[2]].handler_id will lead to oob read. Cc: stable Signed-off-by: Ning Qiang Reviewed-by: Kees Cook Reviewed-by: Greg Kroah-Hartman Acked-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220713153734.2248-1-sohu0106@126.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/macintosh/adb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/macintosh/adb.c +++ b/drivers/macintosh/adb.c @@ -647,7 +647,7 @@ do_adb_query(struct adb_request *req) =20 switch(req->data[1]) { case ADB_QUERY_GETDEVINFO: - if (req->nbytes < 3) + if (req->nbytes < 3 || req->data[2] >=3D 16) break; mutex_lock(&adb_handler_mutex); req->reply[0] =3D adb_handler[req->data[2]].original_address; From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4076C25B0C for ; Tue, 9 Aug 2022 18:28:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344062AbiHIS2t (ORCPT ); Tue, 9 Aug 2022 14:28:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346377AbiHIS0Q (ORCPT ); Tue, 9 Aug 2022 14:26:16 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EFF032DB3; Tue, 9 Aug 2022 11:09:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8E9F3B818B4; Tue, 9 Aug 2022 18:07:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8F1EC433B5; Tue, 9 Aug 2022 18:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068468; bh=l32JHu9PTGPY39fV6meRswxoDAcgeliDnGkLLW5tklE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zoJgGExrGvywCNJxWUOZ8MbfL5yh31T9paHnNL0rxp4CkGpHAqrw/8QExn3Y7KlxJ kdcQTHftY91XXSVXZWEvnecykZwOqjgdZNZxyEBlAv/zUW7dyS75J1N8YGlk3ZEHTx 1oJ+OPOGpRwbAVI4ZDKzqEI1JTHmFshvnmYAZ6P0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Sneddon , Pawan Gupta , Borislav Petkov Subject: [PATCH 5.18 34/35] x86/speculation: Add RSB VM Exit protections Date: Tue, 9 Aug 2022 20:01:03 +0200 Message-Id: <20220809175516.385571106@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Daniel Sneddon commit 2b1299322016731d56807aa49254a5ea3080b6b3 upstream. tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as documented for RET instructions after VM exits. Mitigate it with a new one-entry RSB stuffing mechanism and a new LFENCE. =3D=3D Background =3D=3D Indirect Branch Restricted Speculation (IBRS) was designed to help mitigate Branch Target Injection and Speculative Store Bypass, i.e. Spectre, attacks. IBRS prevents software run in less privileged modes from affecting branch prediction in more privileged modes. IBRS requires the MSR to be written on every privilege level change. To overcome some of the performance issues of IBRS, Enhanced IBRS was introduced. eIBRS is an "always on" IBRS, in other words, just turn it on once instead of writing the MSR on every privilege level change. When eIBRS is enabled, more privileged modes should be protected from less privileged modes, including protecting VMMs from guests. =3D=3D Problem =3D=3D Here's a simplification of how guests are run on Linux' KVM: void run_kvm_guest(void) { // Prepare to run guest VMRESUME(); // Clean up after guest runs } The execution flow for that would look something like this to the processor: 1. Host-side: call run_kvm_guest() 2. Host-side: VMRESUME 3. Guest runs, does "CALL guest_function" 4. VM exit, host runs again 5. Host might make some "cleanup" function calls 6. Host-side: RET from run_kvm_guest() Now, when back on the host, there are a couple of possible scenarios of post-guest activity the host needs to do before executing host code: * on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not touched and Linux has to do a 32-entry stuffing. * on eIBRS hardware, VM exit with IBRS enabled, or restoring the host IBRS=3D1 shortly after VM exit, has a documented side effect of flushing the RSB except in this PBRSB situation where the software needs to stuff the last RSB entry "by hand". IOW, with eIBRS supported, host RET instructions should no longer be influenced by guest behavior after the host retires a single CALL instruction. However, if the RET instructions are "unbalanced" with CALLs after a VM exit as is the RET in #6, it might speculatively use the address for the instruction after the CALL in #3 as an RSB prediction. This is a problem since the (untrusted) guest controls this address. Balanced CALL/RET instruction pairs such as in step #5 are not affected. =3D=3D Solution =3D=3D The PBRSB issue affects a wide variety of Intel processors which support eIBRS. But not all of them need mitigation. Today, X86_FEATURE_RSB_VMEXIT triggers an RSB filling sequence that mitigates PBRSB. Systems setting RSB_VMEXIT need no further mitigation - i.e., eIBRS systems which enable legacy IBRS explicitly. However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RSB_VMEXIT and most of them need a new mitigation. Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE which triggers a lighter-weight PBRSB mitigation versus RSB_VMEXIT. The lighter-weight mitigation performs a CALL instruction which is immediately followed by a speculative execution barrier (INT3). This steers speculative execution to the barrier -- just like a retpoline -- which ensures that speculation can never reach an unbalanced RET. Then, ensure this CALL is retired before continuing execution with an LFENCE. In other words, the window of exposure is opened at VM exit where RET behavior is troublesome. While the window is open, force RSB predictions sampling for RET targets to a dead end at the INT3. Close the window with the LFENCE. There is a subset of eIBRS systems which are not vulnerable to PBRSB. Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB. Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO. [ bp: Massage, incorporate review comments from Andy Cooper. ] Signed-off-by: Daniel Sneddon Co-developed-by: Pawan Gupta Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- Documentation/admin-guide/hw-vuln/spectre.rst | 8 ++ arch/x86/include/asm/cpufeatures.h | 2=20 arch/x86/include/asm/msr-index.h | 4 + arch/x86/include/asm/nospec-branch.h | 17 ++++- arch/x86/kernel/cpu/bugs.c | 86 +++++++++++++++++++--= ----- arch/x86/kernel/cpu/common.c | 12 +++ arch/x86/kvm/vmx/vmenter.S | 8 +- tools/arch/x86/include/asm/cpufeatures.h | 1=20 tools/arch/x86/include/asm/msr-index.h | 4 + 9 files changed, 113 insertions(+), 29 deletions(-) --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -422,6 +422,14 @@ The possible values in this file are: 'RSB filling' Protection of RSB on context switch enabled =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 + - EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D + 'PBRSB-eIBRS: SW sequence' CPU is affected and protection of RSB on VM= EXIT enabled + 'PBRSB-eIBRS: Vulnerable' CPU is vulnerable + 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D + Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -302,6 +302,7 @@ #define X86_FEATURE_RETHUNK (11*32+14) /* "" Use REturn THUNK */ #define X86_FEATURE_UNRET (11*32+15) /* "" AMD BTB untrain return */ #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime = firmware calls */ +#define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM exit w= hen EIBRS is enabled */ =20 /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ @@ -453,5 +454,6 @@ #define X86_BUG_SRBDS X86_BUG(24) /* CPU may leak RNG bits if not mitiga= ted */ #define X86_BUG_MMIO_STALE_DATA X86_BUG(25) /* CPU is affected by Process= or MMIO Stale Data vulnerabilities */ #define X86_BUG_RETBLEED X86_BUG(26) /* CPU is affected by RETBleed */ +#define X86_BUG_EIBRS_PBRSB X86_BUG(27) /* EIBRS is vulnerable to Post Ba= rrier RSB Predictions */ =20 #endif /* _ASM_X86_CPUFEATURES_H */ --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -148,6 +148,10 @@ * are restricted to targets in * kernel. */ +#define ARCH_CAP_PBRSB_NO BIT(24) /* + * Not susceptible to Post-Barrier + * Return Stack Buffer Predictions. + */ =20 #define MSR_IA32_FLUSH_CMD 0x0000010b #define L1D_FLUSH BIT(0) /* --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -118,13 +118,28 @@ #endif .endm =20 +.macro ISSUE_UNBALANCED_RET_GUARD + ANNOTATE_INTRA_FUNCTION_CALL + call .Lunbalanced_ret_guard_\@ + int3 +.Lunbalanced_ret_guard_\@: + add $(BITS_PER_LONG/8), %_ASM_SP + lfence +.endm + /* * A simpler FILL_RETURN_BUFFER macro. Don't make people use the CPP * monstrosity above, manually. */ -.macro FILL_RETURN_BUFFER reg:req nr:req ftr:req +.macro FILL_RETURN_BUFFER reg:req nr:req ftr:req ftr2 +.ifb \ftr2 ALTERNATIVE "jmp .Lskip_rsb_\@", "", \ftr +.else + ALTERNATIVE_2 "jmp .Lskip_rsb_\@", "", \ftr, "jmp .Lunbalanced_\@", \ftr2 +.endif __FILL_RETURN_BUFFER(\reg,\nr,%_ASM_SP) +.Lunbalanced_\@: + ISSUE_UNBALANCED_RET_GUARD .Lskip_rsb_\@: .endm =20 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1328,6 +1328,53 @@ static void __init spec_ctrl_disable_ker } } =20 +static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spect= re_v2_mitigation mode) +{ + /* + * Similar to context switches, there are two types of RSB attacks + * after VM exit: + * + * 1) RSB underflow + * + * 2) Poisoned RSB entry + * + * When retpoline is enabled, both are mitigated by filling/clearing + * the RSB. + * + * When IBRS is enabled, while #1 would be mitigated by the IBRS branch + * prediction isolation protections, RSB still needs to be cleared + * because of #2. Note that SMEP provides no protection here, unlike + * user-space-poisoned RSB entries. + * + * eIBRS should protect against RSB poisoning, but if the EIBRS_PBRSB + * bug is present then a LITE version of RSB protection is required, + * just a single call needs to retire before a RET is executed. + */ + switch (mode) { + case SPECTRE_V2_NONE: + return; + + case SPECTRE_V2_EIBRS_LFENCE: + case SPECTRE_V2_EIBRS: + if (boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB)) { + setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE); + pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n"); + } + return; + + case SPECTRE_V2_EIBRS_RETPOLINE: + case SPECTRE_V2_RETPOLINE: + case SPECTRE_V2_LFENCE: + case SPECTRE_V2_IBRS: + setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); + pr_info("Spectre v2 / SpectreRSB : Filling RSB on VMEXIT\n"); + return; + } + + pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation at VM exi= t"); + dump_stack(); +} + static void __init spectre_v2_select_mitigation(void) { enum spectre_v2_mitigation_cmd cmd =3D spectre_v2_parse_cmdline(); @@ -1478,28 +1525,7 @@ static void __init spectre_v2_select_mit setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW); pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switc= h\n"); =20 - /* - * Similar to context switches, there are two types of RSB attacks - * after vmexit: - * - * 1) RSB underflow - * - * 2) Poisoned RSB entry - * - * When retpoline is enabled, both are mitigated by filling/clearing - * the RSB. - * - * When IBRS is enabled, while #1 would be mitigated by the IBRS branch - * prediction isolation protections, RSB still needs to be cleared - * because of #2. Note that SMEP provides no protection here, unlike - * user-space-poisoned RSB entries. - * - * eIBRS, on the other hand, has RSB-poisoning protections, so it - * doesn't need RSB clearing after vmexit. - */ - if (boot_cpu_has(X86_FEATURE_RETPOLINE) || - boot_cpu_has(X86_FEATURE_KERNEL_IBRS)) - setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT); + spectre_v2_determine_rsb_fill_type_at_vmexit(mode); =20 /* * Retpoline protects the kernel, but doesn't protect firmware. IBRS @@ -2285,6 +2311,19 @@ static char *ibpb_state(void) return ""; } =20 +static char *pbrsb_eibrs_state(void) +{ + if (boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB)) { + if (boot_cpu_has(X86_FEATURE_RSB_VMEXIT_LITE) || + boot_cpu_has(X86_FEATURE_RSB_VMEXIT)) + return ", PBRSB-eIBRS: SW sequence"; + else + return ", PBRSB-eIBRS: Vulnerable"; + } else { + return ", PBRSB-eIBRS: Not affected"; + } +} + static ssize_t spectre_v2_show_state(char *buf) { if (spectre_v2_enabled =3D=3D SPECTRE_V2_LFENCE) @@ -2297,12 +2336,13 @@ static ssize_t spectre_v2_show_state(cha spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS_LFENCE) return sprintf(buf, "Vulnerable: eIBRS+LFENCE with unprivileged eBPF and= SMT\n"); =20 - return sprintf(buf, "%s%s%s%s%s%s\n", + return sprintf(buf, "%s%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], ibpb_state(), boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "", stibp_state(), boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB filling" : "", + pbrsb_eibrs_state(), spectre_v2_module_string()); } =20 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1161,6 +1161,7 @@ static void identify_cpu_without_cpuid(s #define NO_SWAPGS BIT(6) #define NO_ITLB_MULTIHIT BIT(7) #define NO_SPECTRE_V2 BIT(8) +#define NO_EIBRS_PBRSB BIT(9) =20 #define VULNWL(vendor, family, model, whitelist) \ X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, whitelist) @@ -1203,7 +1204,7 @@ static const __initconst struct x86_cpu_ =20 VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTI= HIT), VULNWL_INTEL(ATOM_GOLDMONT_D, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MUL= TIHIT), - VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_M= ULTIHIT), + VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_M= ULTIHIT | NO_EIBRS_PBRSB), =20 /* * Technically, swapgs isn't serializing on AMD (despite it previously @@ -1213,7 +1214,9 @@ static const __initconst struct x86_cpu_ * good enough for our purposes. */ =20 - VULNWL_INTEL(ATOM_TREMONT_D, NO_ITLB_MULTIHIT), + VULNWL_INTEL(ATOM_TREMONT, NO_EIBRS_PBRSB), + VULNWL_INTEL(ATOM_TREMONT_L, NO_EIBRS_PBRSB), + VULNWL_INTEL(ATOM_TREMONT_D, NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB), =20 /* AMD Family 0xf - 0x12 */ VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT), @@ -1391,6 +1394,11 @@ static void __init cpu_set_bug_bits(stru setup_force_cpu_bug(X86_BUG_RETBLEED); } =20 + if (cpu_has(c, X86_FEATURE_IBRS_ENHANCED) && + !cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) && + !(ia32_cap & ARCH_CAP_PBRSB_NO)) + setup_force_cpu_bug(X86_BUG_EIBRS_PBRSB); + if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN)) return; =20 --- a/arch/x86/kvm/vmx/vmenter.S +++ b/arch/x86/kvm/vmx/vmenter.S @@ -227,11 +227,13 @@ SYM_INNER_LABEL(vmx_vmexit, SYM_L_GLOBAL * entries and (in some cases) RSB underflow. * * eIBRS has its own protection against poisoned RSB, so it doesn't - * need the RSB filling sequence. But it does need to be enabled - * before the first unbalanced RET. + * need the RSB filling sequence. But it does need to be enabled, and a + * single call to retire, before the first unbalanced RET. */ =20 - FILL_RETURN_BUFFER %_ASM_CX, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_VMEXIT + FILL_RETURN_BUFFER %_ASM_CX, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_VMEXIT,\ + X86_FEATURE_RSB_VMEXIT_LITE + =20 pop %_ASM_ARG2 /* @flags */ pop %_ASM_ARG1 /* @vmx */ --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -301,6 +301,7 @@ #define X86_FEATURE_RETPOLINE_LFENCE (11*32+13) /* "" Use LFENCE for Spect= re variant 2 */ #define X86_FEATURE_RETHUNK (11*32+14) /* "" Use REturn THUNK */ #define X86_FEATURE_UNRET (11*32+15) /* "" AMD BTB untrain return */ +#define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM-Exit w= hen EIBRS is enabled */ =20 /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ --- a/tools/arch/x86/include/asm/msr-index.h +++ b/tools/arch/x86/include/asm/msr-index.h @@ -148,6 +148,10 @@ * are restricted to targets in * kernel. */ +#define ARCH_CAP_PBRSB_NO BIT(24) /* + * Not susceptible to Post-Barrier + * Return Stack Buffer Predictions. + */ =20 #define MSR_IA32_FLUSH_CMD 0x0000010b #define L1D_FLUSH BIT(0) /* From nobody Mon Apr 13 10:34:41 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73CE7C19F2D for ; Tue, 9 Aug 2022 18:29:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344089AbiHIS3P (ORCPT ); Tue, 9 Aug 2022 14:29:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346688AbiHIS0f (ORCPT ); Tue, 9 Aug 2022 14:26:35 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCBD232EF2; Tue, 9 Aug 2022 11:09:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 512B9B819ED; Tue, 9 Aug 2022 18:07:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A637C433C1; Tue, 9 Aug 2022 18:07:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068471; bh=Aj/qrZaVX0QhpzS2MUF/ANJF5hHr2wjbfHO7Xx3sWUY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LM4Ot6b5dt+QDNNe73zgQcuvlD143Iv5/ETOVjeb91Dig3RTKgSFgxLJUf85s0j7z d4OnvEgopQexRO9otBfN4SLL9WhEWSlsGNnmT34MtadShCuXK625/q7Wr0hT+5IgC1 Yn4jvqg+WfOZGukGROCCHYnZYorVQTWcfT2RN9yM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrew Cooper , Pawan Gupta , Borislav Petkov , Daniel Sneddon Subject: [PATCH 5.18 35/35] x86/speculation: Add LFENCE to RSB fill sequence Date: Tue, 9 Aug 2022 20:01:04 +0200 Message-Id: <20220809175516.425509841@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175515.046484486@linuxfoundation.org> References: <20220809175515.046484486@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit ba6e31af2be96c4d0536f2152ed6f7b6c11bca47 upstream. RSB fill sequence does not have any protection for miss-prediction of conditional branch at the end of the sequence. CPU can speculatively execute code immediately after the sequence, while RSB filling hasn't completed yet. #define __FILL_RETURN_BUFFER(reg, nr, sp) \ mov $(nr/2), reg; \ 771: \ ANNOTATE_INTRA_FUNCTION_CALL; \ call 772f; \ 773: /* speculation trap */ \ UNWIND_HINT_EMPTY; \ pause; \ lfence; \ jmp 773b; \ 772: \ ANNOTATE_INTRA_FUNCTION_CALL; \ call 774f; \ 775: /* speculation trap */ \ UNWIND_HINT_EMPTY; \ pause; \ lfence; \ jmp 775b; \ 774: \ add $(BITS_PER_LONG/8) * 2, sp; \ dec reg; \ jnz 771b; <----- CPU can miss-predict here. Before RSB is filled, RETs that come in program order after this macro can be executed speculatively, making them vulnerable to RSB-based attacks. Mitigate it by adding an LFENCE after the conditional branch to prevent speculation while RSB is being filled. Suggested-by: Andrew Cooper Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Daniel Sneddon Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/include/asm/nospec-branch.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -60,7 +60,9 @@ 774: \ add $(BITS_PER_LONG/8) * 2, sp; \ dec reg; \ - jnz 771b; + jnz 771b; \ + /* barrier for jnz misprediction */ \ + lfence; =20 #ifdef __ASSEMBLY__