The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e7ad18d1169c62e6c78c01ff693fd362d9d65278
Gitweb: https://git.kernel.org/tip/e7ad18d1169c62e6c78c01ff693fd362d9d65278
Author: Borislav Petkov <bp(a)suse.de>
AuthorDate: Wed, 05 Oct 2022 12:00:08 +02:00
Committer: Borislav Petkov <bp(a)suse.de>
CommitterDate: Tue, 18 Oct 2022 11:03:27 +02:00
x86/microcode/AMD: Apply the patch early on every logical thread
Currently, the patch application logic checks whether the revision
needs to be applied on each logical CPU (SMT thread). Therefore, on SMT
designs where the microcode engine is shared between the two threads,
the application happens only on one of them as that is enough to update
the shared microcode engine.
However, there are microcode patches which do per-thread modification,
see Link tag below.
Therefore, drop the revision check and try applying on each thread. This
is what the BIOS does too so this method is very much tested.
Btw, change only the early paths. On the late loading paths, there's no
point in doing per-thread modification because if is it some case like
in the bugzilla below - removing a CPUID flag - the kernel cannot go and
un-use features it has detected are there early. For that, one should
use early loading anyway.
[ bp: Fixes does not contain the oldest commit which did check for
equality but that is good enough. ]
Fixes: 8801b3fcb574 ("x86/microcode/AMD: Rework container parsing")
Reported-by: Ștefan Talpalaru <stefantalpalaru(a)yahoo.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Tested-by: Ștefan Talpalaru <stefantalpalaru(a)yahoo.com>
Cc: <stable(a)vger.kernel.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216211
---
arch/x86/kernel/cpu/microcode/amd.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index e7410e9..3a35dec 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -440,7 +440,13 @@ apply_microcode_early_amd(u32 cpuid_1_eax, void *ucode, size_t size, bool save_p
return ret;
native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
- if (rev >= mc->hdr.patch_id)
+
+ /*
+ * Allow application of the same revision to pick up SMT-specific
+ * changes even if the revision of the other SMT thread is already
+ * up-to-date.
+ */
+ if (rev > mc->hdr.patch_id)
return ret;
if (!__apply_microcode_amd(mc)) {
@@ -528,8 +534,12 @@ void load_ucode_amd_ap(unsigned int cpuid_1_eax)
native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
- /* Check whether we have saved a new patch already: */
- if (*new_rev && rev < mc->hdr.patch_id) {
+ /*
+ * Check whether a new patch has been saved already. Also, allow application of
+ * the same revision in order to pick up SMT-thread-specific configuration even
+ * if the sibling SMT thread already has an up-to-date revision.
+ */
+ if (*new_rev && rev <= mc->hdr.patch_id) {
if (!__apply_microcode_amd(mc)) {
*new_rev = mc->hdr.patch_id;
return;
Hi Greg and Sasha,
Please consider applying the following commits to 5.19 and 6.0:
4f001a21080f ("Kconfig.debug: simplify the dependency of DEBUG_INFO_DWARF4/5")
bb1435f3f575 ("Kconfig.debug: add toolchain checks for DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT")
0a6de78cff60 ("lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5")
The main change is the final one but the second patch is a prerequisite
and a useful fix in its own right. The first change allows the second to
apply cleanly and it is a good clean up as well.
I have verified that they apply cleanly to those trees with 'patch -p1'.
Attached is a manual backport for 5.15; the changes should not be
necessary for older trees, as they do not have support for DWARF 5.
If there are any problems or questions, please let me know.
Cheers,
Nathan
hi,
new version of pahole (1.24) is causing compilation fail for 5.15
stable kernel, discussed in here [1][2]. Sending fix for that plus
one dependency patch.
Note for patch 1:
there was one extra line change in scripts/pahole-flags.sh file in
its linux tree merge commit:
fc02cb2b37fe Merge tag 'net-next-for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
not sure how/if to track that, I squashed the change in.
thanks,
jirka
[1] https://lore.kernel.org/bpf/20220825163538.vajnsv3xcpbhl47v@altlinux.org/
[2] https://lore.kernel.org/bpf/YwQRKkmWqsf%2FDu6A@kernel.org/
---
Jiri Olsa (1):
kbuild: Unify options for BTF generation for vmlinux and modules
Martin Rodriguez Reboredo (1):
kbuild: Add skip_encoding_btf_enum64 option to pahole
Makefile | 3 +++
scripts/Makefile.modfinal | 2 +-
scripts/link-vmlinux.sh | 11 +----------
scripts/pahole-flags.sh | 24 ++++++++++++++++++++++++
4 files changed, 29 insertions(+), 11 deletions(-)
create mode 100755 scripts/pahole-flags.sh
Hi Sasha,
Please stop backporting my commits to stable without asking, especially without
Cc'ing to any mailing list that is archived on lore.kernel.org.
"fscrypt: stop using keyrings subsystem for fscrypt_master_key" is a big change,
and there's already a fix for it pending
(https://lore.kernel.org/r/20221011213838.209879-1-ebiggers@kernel.org). I've
been planning on doing the backports myself once the change has had a bit more
time to soak, which is why I intentionally didn't add Cc stable.
It appears you also backported several other commits just to get it apply
cleanly to 5.10, so please drop those too for now.
- Eric
The patch below does not apply to the 6.0-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
f9929f69de94 ("drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid()")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f9929f69de94212f98b3ad72a3e81c3bd3d333e0 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan(a)kernel.org>
Date: Mon, 25 Jul 2022 16:36:29 -0700
Subject: [PATCH] drm/simpledrm: Fix return type of
simpledrm_simple_display_pipe_mode_valid()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When booting a kernel compiled with clang's CFI protection
(CONFIG_CFI_CLANG), there is a CFI failure in
drm_simple_kms_crtc_mode_valid() when trying to call
simpledrm_simple_display_pipe_mode_valid() through ->mode_valid():
[ 0.322802] CFI failure (target: simpledrm_simple_display_pipe_mode_valid+0x0/0x8):
...
[ 0.324928] Call trace:
[ 0.324969] __ubsan_handle_cfi_check_fail+0x58/0x60
[ 0.325053] __cfi_check_fail+0x3c/0x44
[ 0.325120] __cfi_slowpath_diag+0x178/0x200
[ 0.325192] drm_simple_kms_crtc_mode_valid+0x58/0x80
[ 0.325279] __drm_helper_update_and_validate+0x31c/0x464
...
The ->mode_valid() member in 'struct drm_simple_display_pipe_funcs'
expects a return type of 'enum drm_mode_status', not 'int'. Correct it
to fix the CFI failure.
Cc: stable(a)vger.kernel.org
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1647
Reported-by: Tomasz Paweł Gajc <tpgxyz(a)gmail.com>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
Reviewed-by: Sami Tolvanen <samitolvanen(a)google.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220725233629.223223-1-natha…
(cherry picked from commit 0c09bc33aa8e9dc867300acaadc318c2f0d85a1e)
Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 768242a78e2b..5422363690e7 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -627,7 +627,7 @@ static const struct drm_connector_funcs simpledrm_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static int
+static enum drm_mode_status
simpledrm_simple_display_pipe_mode_valid(struct drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode)
{
With the re-use of the previous completion status in 0d1c407b1a749
("usb: dwc3: gadget: Return proper request status") it could be possible
that the next frame would also get dropped if the current frame has a
missed isoc error. Ensure that an interrupt is requested for the start
of a new frame.
Fixes: fc78941d8169 ("usb: gadget: uvc: decrease the interrupt load to a quarter")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Dan Vacura <w36195(a)motorola.com>
---
V1 -> V3:
- no change, new patch in series
drivers/usb/gadget/function/uvc_video.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
index bb037fcc90e6..323977716f5a 100644
--- a/drivers/usb/gadget/function/uvc_video.c
+++ b/drivers/usb/gadget/function/uvc_video.c
@@ -431,7 +431,8 @@ static void uvcg_video_pump(struct work_struct *work)
/* Endpoint now owns the request */
req = NULL;
- video->req_int_count++;
+ if (buf->state != UVC_BUF_STATE_DONE)
+ video->req_int_count++;
}
if (!req)
--
2.34.1