- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] rust: use `#[used(compiler)]` to fix build and `modpost` with" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 7498159226772d66f150dd406be462d75964a366 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072102-theorize-single-3700@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7498159226772d66f150dd406be462d75964a366 Mon Sep 17 00:00:00 2001 From: Miguel Ojeda <ojeda(a)kernel.org> Date: Sat, 12 Jul 2025 18:01:03 +0200 Subject: [PATCH] rust: use `#[used(compiler)]` to fix build and `modpost` with Rust >= 1.89.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the `rusttest` target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to `rust_helper_kunit_get_current_test' Moreover, tooling like `modpost` gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat `#[used]` as `#[used(linker)]` instead of `#[used(compiler)]` for our targets. This means that the retain section flag (`R`, `SHF_GNU_RETAIN`) will be used and that they will be marked as `unique` too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in `rusttest` and that multiple `.modinfo` sections are generated, which confuse tooling like `modpost` because they only expect one. Thus start using `#[used(compiler)]` to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (`used_with_arg`) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use `#[no_mangle]` or `#[export_name = ...]` since those still behave like `#[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood <david(a)davidtw.co> Cc: Wesley Wiser <wwiser(a)gmail.com> Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Acked-by: Björn Roy Baron <bjorn3_gh(a)protonmail.com> Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> diff --git a/rust/Makefile b/rust/Makefile index 27dec7904c3a..115b63b7d1e3 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -194,6 +194,7 @@ quiet_cmd_rustdoc_test = RUSTDOC T $< RUST_MODFILE=test.rs \ OBJTREE=$(abspath $(objtree)) \ $(RUSTDOC) --test $(rust_common_flags) \ + -Zcrate-attr='feature(used_with_arg)' \ @$(objtree)/include/generated/rustc_cfg \ $(rustc_target_flags) $(rustdoc_test_target_flags) \ $(rustdoc_test_quiet) \ diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs index 2494c96e105f..4fe621f35716 100644 --- a/rust/kernel/firmware.rs +++ b/rust/kernel/firmware.rs @@ -202,7 +202,7 @@ macro_rules! module_firmware { }; #[link_section = ".modinfo"] - #[used] + #[used(compiler)] static __MODULE_FIRMWARE: [u8; $($builder)*::create(__MODULE_FIRMWARE_PREFIX) .build_length()] = $($builder)*::create(__MODULE_FIRMWARE_PREFIX).build(); }; diff --git a/rust/kernel/kunit.rs b/rust/kernel/kunit.rs index 4b8cdcb21e77..b9e65905e121 100644 --- a/rust/kernel/kunit.rs +++ b/rust/kernel/kunit.rs @@ -302,7 +302,7 @@ macro_rules! kunit_unsafe_test_suite { is_init: false, }; - #[used] + #[used(compiler)] #[allow(unused_unsafe)] #[cfg_attr(not(target_os = "macos"), link_section = ".kunit_test_suites")] static mut KUNIT_TEST_SUITE_ENTRY: *const ::kernel::bindings::kunit_suite = diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index 6b4774b2b1c3..e13d6ed88fa6 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -34,6 +34,9 @@ // Expected to become stable. #![feature(arbitrary_self_types)] // +// To be determined. +#![feature(used_with_arg)] +// // `feature(derive_coerce_pointee)` is expected to become stable. Before Rust // 1.84.0, it did not exist, so enable the predecessor features. #![cfg_attr(CONFIG_RUSTC_HAS_COERCE_POINTEE, feature(derive_coerce_pointee))] diff --git a/rust/macros/module.rs b/rust/macros/module.rs index 2ddd2eeb2852..75efc6eeeafc 100644 --- a/rust/macros/module.rs +++ b/rust/macros/module.rs @@ -57,7 +57,7 @@ fn emit_base(&mut self, field: &str, content: &str, builtin: bool) { {cfg} #[doc(hidden)] #[cfg_attr(not(target_os = \"macos\"), link_section = \".modinfo\")] - #[used] + #[used(compiler)] pub static __{module}_{counter}: [u8; {length}] = *{string}; ", cfg = if builtin { @@ -249,7 +249,7 @@ mod __module_init {{ // key or a new section. For the moment, keep it simple. #[cfg(MODULE)] #[doc(hidden)] - #[used] + #[used(compiler)] static __IS_RUST_MODULE: () = (); static mut __MOD: ::core::mem::MaybeUninit<{type_}> = @@ -273,7 +273,7 @@ mod __module_init {{ #[cfg(MODULE)] #[doc(hidden)] - #[used] + #[used(compiler)] #[link_section = \".init.data\"] static __UNIQUE_ID___addressable_init_module: unsafe extern \"C\" fn() -> i32 = init_module; @@ -293,7 +293,7 @@ mod __module_init {{ #[cfg(MODULE)] #[doc(hidden)] - #[used] + #[used(compiler)] #[link_section = \".exit.data\"] static __UNIQUE_ID___addressable_cleanup_module: extern \"C\" fn() = cleanup_module; @@ -303,7 +303,7 @@ mod __module_init {{ #[cfg(not(CONFIG_HAVE_ARCH_PREL32_RELOCATIONS))] #[doc(hidden)] #[link_section = \"{initcall_section}\"] - #[used] + #[used(compiler)] pub static __{ident}_initcall: extern \"C\" fn() -> ::kernel::ffi::c_int = __{ident}_init; diff --git a/scripts/Makefile.build b/scripts/Makefile.build index a6461ea411f7..ba71b27aa363 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -312,10 +312,11 @@ $(obj)/%.lst: $(obj)/%.c FORCE # - Stable since Rust 1.82.0: `feature(asm_const)`, `feature(raw_ref_op)`. # - Stable since Rust 1.87.0: `feature(asm_goto)`. # - Expected to become stable: `feature(arbitrary_self_types)`. +# - To be determined: `feature(used_with_arg)`. # # Please see https://github.com/Rust-for-Linux/linux/issues/2 for details on # the unstable features in use. -rust_allowed_features := asm_const,asm_goto,arbitrary_self_types,lint_reasons,raw_ref_op +rust_allowed_features := asm_const,asm_goto,arbitrary_self_types,lint_reasons,raw_ref_op,used_with_arg # `--out-dir` is required to avoid temporaries being created by `rustc` in the # current working directory, which may be not accessible in the out-of-tree

1 month, 1 week

3
2
0 0

[PATCH 6.6.y] erofs: address D-cache aliasing

by Gao Xiang

commit 27917e8194f91dffd8b4825350c63cb68e98ce58 upstream. Flush the D-cache before unlocking folios for compressed inodes, as they are dirtied during decompression. Avoid calling flush_dcache_folio() on every CPU write, since it's more like playing whack-a-mole without real benefit. It has no impact on x86 and arm64/risc-v: on x86, flush_dcache_folio() is a no-op, and on arm64/risc-v, PG_dcache_clean (PG_arch_1) is clear for new page cache folios. However, certain ARM boards are affected, as reported. Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support") Closes: https://lore.kernel.org/r/c1e51e16-6cc6-49d0-a63e-4e9ff6c4dd53@pengutronix.… Closes: https://lore.kernel.org/r/38d43fae-1182-4155-9c5b-ffc7382d9917@siemens.com Tested-by: Jan Kiszka <jan.kiszka(a)siemens.com> Tested-by: Stefan Kerkmann <s.kerkmann(a)pengutronix.de> Link: https://lore.kernel.org/r/20250709034614.2780117-2-hsiangkao@linux.alibaba.… Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> --- Hi Jan & Stefan, Please help confirm this 6.6 fix backport if possible. Thanks, Gao Xiang fs/erofs/decompressor.c | 6 ++---- fs/erofs/zdata.c | 32 +++++++++++++++++++------------- 2 files changed, 21 insertions(+), 17 deletions(-) diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c index aa59788a61e6..86e088fd386e 100644 --- a/fs/erofs/decompressor.c +++ b/fs/erofs/decompressor.c @@ -342,14 +342,12 @@ static int z_erofs_transform_plain(struct z_erofs_decompress_req *rq, if (outpages > inpages) { DBG_BUGON(!rq->out[outpages - 1]); - if (rq->out[outpages - 1] != rq->in[inpages - 1]) { + if (rq->out[outpages - 1] != rq->in[inpages - 1]) memcpy_to_page(rq->out[outpages - 1], 0, src + (interlaced_offset ? 0 : righthalf), lefthalf); - } else if (!interlaced_offset) { + else if (!interlaced_offset) memmove(src, src + righthalf, lefthalf); - flush_dcache_page(rq->in[inpages - 1]); - } } kunmap_local(src); return 0; diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index 496e4c7c52a4..d852b43ac43e 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -122,9 +122,11 @@ static inline unsigned int z_erofs_pclusterpages(struct z_erofs_pcluster *pcl) /* * bit 30: I/O error occurred on this page + * bit 29: CPU has dirty data in D-cache (needs aliasing handling); * bit 0 - 29: remaining parts to complete this page */ -#define Z_EROFS_PAGE_EIO (1 << 30) +#define Z_EROFS_ONLINEPAGE_EIO 30 +#define Z_EROFS_ONLINEPAGE_DIRTY 29 static inline void z_erofs_onlinepage_init(struct page *page) { @@ -143,7 +145,7 @@ static inline void z_erofs_onlinepage_split(struct page *page) atomic_inc((atomic_t *)&page->private); } -static void z_erofs_onlinepage_endio(struct page *page, int err) +static void z_erofs_onlinepage_end(struct page *page, int err, bool dirty) { int orig, v; @@ -151,16 +153,20 @@ static void z_erofs_onlinepage_endio(struct page *page, int err) do { orig = atomic_read((atomic_t *)&page->private); - v = (orig - 1) | (err ? Z_EROFS_PAGE_EIO : 0); + DBG_BUGON(orig <= 0); + v = dirty << Z_EROFS_ONLINEPAGE_DIRTY; + v |= (orig - 1) | (!!err << Z_EROFS_ONLINEPAGE_EIO); } while (atomic_cmpxchg((atomic_t *)&page->private, orig, v) != orig); - if (!(v & ~Z_EROFS_PAGE_EIO)) { - set_page_private(page, 0); - ClearPagePrivate(page); - if (!(v & Z_EROFS_PAGE_EIO)) - SetPageUptodate(page); - unlock_page(page); - } + if (v & (BIT(Z_EROFS_ONLINEPAGE_DIRTY) - 1)) + return; + set_page_private(page, 0); + ClearPagePrivate(page); + if (v & BIT(Z_EROFS_ONLINEPAGE_DIRTY)) + flush_dcache_page(page); + if (!(v & BIT(Z_EROFS_ONLINEPAGE_EIO))) + SetPageUptodate(page); + unlock_page(page); } #define Z_EROFS_ONSTACK_PAGES 32 @@ -1060,7 +1066,7 @@ static int z_erofs_do_read_page(struct z_erofs_decompress_frontend *fe, goto repeat; out: - z_erofs_onlinepage_endio(page, err); + z_erofs_onlinepage_end(page, err, false); return err; } @@ -1163,7 +1169,7 @@ static void z_erofs_fill_other_copies(struct z_erofs_decompress_backend *be, cur += len; } kunmap_local(dst); - z_erofs_onlinepage_endio(bvi->bvec.page, err); + z_erofs_onlinepage_end(bvi->bvec.page, err, true); list_del(p); kfree(bvi); } @@ -1333,7 +1339,7 @@ static int z_erofs_decompress_pcluster(struct z_erofs_decompress_backend *be, /* recycle all individual short-lived pages */ if (z_erofs_put_shortlivedpage(be->pagepool, page)) continue; - z_erofs_onlinepage_endio(page, err); + z_erofs_onlinepage_end(page, err, true); } if (be->decompressed_pages != be->onstack_pages) -- 2.43.5

1 month, 1 week

2
1
0 0

FAILED: patch "[PATCH] x86/mce/amd: Add default names for MCA banks and blocks" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x d66e1e90b16055d2f0ee76e5384e3f119c3c2773 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071202-cycling-woof-6cf6@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Tue, 24 Jun 2025 14:15:58 +0000 Subject: [PATCH] x86/mce/amd: Add default names for MCA banks and blocks Ensure that sysfs init doesn't fail for new/unrecognized bank types or if a bank has additional blocks available. Most MCA banks have a single thresholding block, so the block takes the same name as the bank. Unified Memory Controllers (UMCs) are a special case where there are two blocks and each has a unique name. However, the microarchitecture allows for five blocks. Any new MCA bank types with more than one block will be missing names for the extra blocks. The MCE sysfs will fail to initialize in this case. Fixes: 87a6d4091bd7 ("x86/mce/AMD: Update sysfs bank names for SMCA systems") Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-3-236dd74f645f@amd.com diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c index 9d852c3b2cb5..6820ebce5d46 100644 --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -1113,13 +1113,20 @@ static const char *get_name(unsigned int cpu, unsigned int bank, struct threshol } bank_type = smca_get_bank_type(cpu, bank); - if (bank_type >= N_SMCA_BANK_TYPES) - return NULL; if (b && (bank_type == SMCA_UMC || bank_type == SMCA_UMC_V2)) { if (b->block < ARRAY_SIZE(smca_umc_block_names)) return smca_umc_block_names[b->block]; - return NULL; + } + + if (b && b->block) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_block_%u", b->block); + return buf_mcatype; + } + + if (bank_type >= N_SMCA_BANK_TYPES) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_bank_%u", bank); + return buf_mcatype; } if (per_cpu(smca_bank_counts, cpu)[bank_type] == 1)

1 month, 1 week

2
1
0 0

[PATCH 1/2] dt-bindings: display: sprd,sharkl3-dpu: Fix missing clocks constraints

by Krzysztof Kozlowski

'minItems' alone does not impose upper bound, unlike 'maxItems' which implies lower bound. Add missing clock constraint so the list will have exact number of items (clocks). Fixes: 8cae15c60cf0 ("dt-bindings: display: add Unisoc's dpu bindings") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- .../devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml index 4ebea60b8c5b..8c52fa0ea5f8 100644 --- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml @@ -25,7 +25,7 @@ properties: maxItems: 1 clocks: - minItems: 2 + maxItems: 2 clock-names: items: -- 2.48.1

1 month, 1 week

2
3
0 0

FAILED: patch "[PATCH] x86/mce/amd: Add default names for MCA banks and blocks" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x d66e1e90b16055d2f0ee76e5384e3f119c3c2773 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071201-coping-motto-1a12@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Tue, 24 Jun 2025 14:15:58 +0000 Subject: [PATCH] x86/mce/amd: Add default names for MCA banks and blocks Ensure that sysfs init doesn't fail for new/unrecognized bank types or if a bank has additional blocks available. Most MCA banks have a single thresholding block, so the block takes the same name as the bank. Unified Memory Controllers (UMCs) are a special case where there are two blocks and each has a unique name. However, the microarchitecture allows for five blocks. Any new MCA bank types with more than one block will be missing names for the extra blocks. The MCE sysfs will fail to initialize in this case. Fixes: 87a6d4091bd7 ("x86/mce/AMD: Update sysfs bank names for SMCA systems") Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-3-236dd74f645f@amd.com diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c index 9d852c3b2cb5..6820ebce5d46 100644 --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -1113,13 +1113,20 @@ static const char *get_name(unsigned int cpu, unsigned int bank, struct threshol } bank_type = smca_get_bank_type(cpu, bank); - if (bank_type >= N_SMCA_BANK_TYPES) - return NULL; if (b && (bank_type == SMCA_UMC || bank_type == SMCA_UMC_V2)) { if (b->block < ARRAY_SIZE(smca_umc_block_names)) return smca_umc_block_names[b->block]; - return NULL; + } + + if (b && b->block) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_block_%u", b->block); + return buf_mcatype; + } + + if (bank_type >= N_SMCA_BANK_TYPES) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_bank_%u", bank); + return buf_mcatype; } if (per_cpu(smca_bank_counts, cpu)[bank_type] == 1)

1 month, 1 week

2
1
0 0

FAILED: patch "[PATCH] x86/mce/amd: Add default names for MCA banks and blocks" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x d66e1e90b16055d2f0ee76e5384e3f119c3c2773 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071200-cone-ogle-b45b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Tue, 24 Jun 2025 14:15:58 +0000 Subject: [PATCH] x86/mce/amd: Add default names for MCA banks and blocks Ensure that sysfs init doesn't fail for new/unrecognized bank types or if a bank has additional blocks available. Most MCA banks have a single thresholding block, so the block takes the same name as the bank. Unified Memory Controllers (UMCs) are a special case where there are two blocks and each has a unique name. However, the microarchitecture allows for five blocks. Any new MCA bank types with more than one block will be missing names for the extra blocks. The MCE sysfs will fail to initialize in this case. Fixes: 87a6d4091bd7 ("x86/mce/AMD: Update sysfs bank names for SMCA systems") Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-3-236dd74f645f@amd.com diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c index 9d852c3b2cb5..6820ebce5d46 100644 --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -1113,13 +1113,20 @@ static const char *get_name(unsigned int cpu, unsigned int bank, struct threshol } bank_type = smca_get_bank_type(cpu, bank); - if (bank_type >= N_SMCA_BANK_TYPES) - return NULL; if (b && (bank_type == SMCA_UMC || bank_type == SMCA_UMC_V2)) { if (b->block < ARRAY_SIZE(smca_umc_block_names)) return smca_umc_block_names[b->block]; - return NULL; + } + + if (b && b->block) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_block_%u", b->block); + return buf_mcatype; + } + + if (bank_type >= N_SMCA_BANK_TYPES) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_bank_%u", bank); + return buf_mcatype; } if (per_cpu(smca_bank_counts, cpu)[bank_type] == 1)

1 month, 1 week

2
1
0 0

[PATCH] platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()

by Tzung-Bi Shih

The blocking notifier is registered in cros_ec_register(); however, it isn't unregistered in cros_ec_unregister(). Fix it. Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW") Cc: stable(a)vger.kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> --- This is separated from a series (https://lore.kernel.org/chrome-platform/20250721044456.2736300-3-tzungbi@ke…). While I'm still figuring out/testing the series, it'd be better to send the fix earlier (to catch up the upcoming merge window for example). drivers/platform/chrome/cros_ec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/chrome/cros_ec.c b/drivers/platform/chrome/cros_ec.c index 110771a8645e..fd58781a2fb7 100644 --- a/drivers/platform/chrome/cros_ec.c +++ b/drivers/platform/chrome/cros_ec.c @@ -318,6 +318,9 @@ EXPORT_SYMBOL(cros_ec_register); */ void cros_ec_unregister(struct cros_ec_device *ec_dev) { + if (ec_dev->mkbp_event_supported) + blocking_notifier_chain_unregister(&ec_dev->event_notifier, + &ec_dev->notifier_ready); platform_device_unregister(ec_dev->pd); platform_device_unregister(ec_dev->ec); mutex_destroy(&ec_dev->lock); -- 2.50.0.727.gbf7dc18ff4-goog

1 month, 1 week

2
2
0 0

[PATCH v10 1/1] serial: 8250: fix panic due to PSLVERR

by Yunhui Cui

When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable(a)vger.kernel.org --- drivers/tty/serial/8250/8250_port.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4b..2da9db960d09f 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags); -- 2.39.5

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] x86/mce/amd: Add default names for MCA banks and blocks" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x d66e1e90b16055d2f0ee76e5384e3f119c3c2773 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025071200-bath-copartner-6a91@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Tue, 24 Jun 2025 14:15:58 +0000 Subject: [PATCH] x86/mce/amd: Add default names for MCA banks and blocks Ensure that sysfs init doesn't fail for new/unrecognized bank types or if a bank has additional blocks available. Most MCA banks have a single thresholding block, so the block takes the same name as the bank. Unified Memory Controllers (UMCs) are a special case where there are two blocks and each has a unique name. However, the microarchitecture allows for five blocks. Any new MCA bank types with more than one block will be missing names for the extra blocks. The MCE sysfs will fail to initialize in this case. Fixes: 87a6d4091bd7 ("x86/mce/AMD: Update sysfs bank names for SMCA systems") Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-3-236dd74f645f@amd.com diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c index 9d852c3b2cb5..6820ebce5d46 100644 --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -1113,13 +1113,20 @@ static const char *get_name(unsigned int cpu, unsigned int bank, struct threshol } bank_type = smca_get_bank_type(cpu, bank); - if (bank_type >= N_SMCA_BANK_TYPES) - return NULL; if (b && (bank_type == SMCA_UMC || bank_type == SMCA_UMC_V2)) { if (b->block < ARRAY_SIZE(smca_umc_block_names)) return smca_umc_block_names[b->block]; - return NULL; + } + + if (b && b->block) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_block_%u", b->block); + return buf_mcatype; + } + + if (bank_type >= N_SMCA_BANK_TYPES) { + snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_bank_%u", bank); + return buf_mcatype; } if (per_cpu(smca_bank_counts, cpu)[bank_type] == 1)

1 month, 1 week

2
1
0 0

[PATCH AUTOSEL 5.4 1/2] ethernet: intel: fix building with large NR_CPUS

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 24171a5a4a952c26568ff0d2a0bc8c4708a95e1d ] With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to compile like: In function ‘i40e_free_q_vector’, inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3: 571 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’ 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \ drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’ 5113 | kfree_rcu(q_vector, rcu); | ^~~~~~~~~ The problem is that the 'rcu' member in 'q_vector' is too far from the start of the structure. Move this member before the CPU mask instead, in all three drivers. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: David S. Miller <davem(a)davemloft.net> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin(a)intel.com> Tested-by: Sunitha Mekala <sunithax.d.mekala(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Compilation Failure Fix**: This fixes a build-time compilation failure that occurs with large values of CONFIG_NR_CPUS. The error prevents the kernel from building successfully, which is a significant issue for systems configured with high CPU counts. 2. **Root Cause**: The issue stems from the `kfree_rcu()` macro in `include/linux/rcupdate.h:1084` which includes a `BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096)` check. This compile-time assertion ensures that the RCU head field is within the first 4096 bytes of the structure. 3. **Simple and Safe Fix**: The fix is straightforward - it moves the `struct rcu_head rcu` member earlier in the structure, placing it before the `cpumask_t affinity_mask` member. This is a safe change because: - It only reorders structure members - The RCU head doesn't need to be at any specific location functionally - Moving it earlier reduces the offset from the structure start - No functional code changes are required 4. **Affects Multiple Drivers**: The issue affects three Intel ethernet drivers (i40e, ixgbe, fm10k), all of which are fixed identically by moving the rcu member earlier in their respective q_vector structures. 5. **Configuration-Dependent Bug**: This bug only manifests with large CONFIG_NR_CPUS values (likely >= 512 or higher), where the `cpumask_t` type becomes large enough to push the rcu member beyond the 4096-byte offset limit. Systems with high core counts are becoming more common in production environments. 6. **No Risk of Regression**: The change is minimal and doesn't alter any functionality. It's purely a structural reordering that maintains all existing behavior while fixing the compilation issue. 7. **Meets Stable Criteria**: This fix clearly meets the stable kernel criteria as it: - Fixes a real bug (compilation failure) - Is minimal and contained - Has no risk of introducing new issues - Affects users with legitimate configurations The commit is an excellent candidate for stable backporting as it fixes a real compilation issue that prevents kernel builds on systems with large CPU counts, and the fix is trivial with no risk of regression. drivers/net/ethernet/intel/fm10k/fm10k.h | 3 ++- drivers/net/ethernet/intel/i40e/i40e.h | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k.h b/drivers/net/ethernet/intel/fm10k/fm10k.h index b14441944b4b2..db72e5e4acd36 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k.h +++ b/drivers/net/ethernet/intel/fm10k/fm10k.h @@ -189,13 +189,14 @@ struct fm10k_q_vector { struct fm10k_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; char name[IFNAMSIZ + 9]; #ifdef CONFIG_DEBUG_FS struct dentry *dbg_q_vector; #endif /* CONFIG_DEBUG_FS */ - struct rcu_head rcu; /* to avoid race with update stats on free */ /* for dynamic allocation of rings associated with this q_vector */ struct fm10k_ring ring[0] ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h index 4c8c31692e9e0..edb5e408c980f 100644 --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -864,6 +864,7 @@ struct i40e_q_vector { u16 reg_idx; /* register index of the interrupt */ struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ struct i40e_ring_container rx; struct i40e_ring_container tx; @@ -874,7 +875,6 @@ struct i40e_q_vector { cpumask_t affinity_mask; struct irq_affinity_notify affinity_notify; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[I40E_INT_NAME_STR_LEN]; bool arm_wb_state; } ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h index 0142ca226bf50..0f9a1fce0dee9 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h @@ -458,9 +458,10 @@ struct ixgbe_q_vector { struct ixgbe_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; int numa_node; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[IFNAMSIZ + 9]; /* for dynamic allocation of rings associated with this q_vector */ -- 2.39.5

1 month, 1 week

1
1
0 0

[PATCH AUTOSEL 5.10 1/2] ethernet: intel: fix building with large NR_CPUS

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 24171a5a4a952c26568ff0d2a0bc8c4708a95e1d ] With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to compile like: In function ‘i40e_free_q_vector’, inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3: 571 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’ 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \ drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’ 5113 | kfree_rcu(q_vector, rcu); | ^~~~~~~~~ The problem is that the 'rcu' member in 'q_vector' is too far from the start of the structure. Move this member before the CPU mask instead, in all three drivers. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: David S. Miller <davem(a)davemloft.net> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin(a)intel.com> Tested-by: Sunitha Mekala <sunithax.d.mekala(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Compilation Failure Fix**: This fixes a build-time compilation failure that occurs with large values of CONFIG_NR_CPUS. The error prevents the kernel from building successfully, which is a significant issue for systems configured with high CPU counts. 2. **Root Cause**: The issue stems from the `kfree_rcu()` macro in `include/linux/rcupdate.h:1084` which includes a `BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096)` check. This compile-time assertion ensures that the RCU head field is within the first 4096 bytes of the structure. 3. **Simple and Safe Fix**: The fix is straightforward - it moves the `struct rcu_head rcu` member earlier in the structure, placing it before the `cpumask_t affinity_mask` member. This is a safe change because: - It only reorders structure members - The RCU head doesn't need to be at any specific location functionally - Moving it earlier reduces the offset from the structure start - No functional code changes are required 4. **Affects Multiple Drivers**: The issue affects three Intel ethernet drivers (i40e, ixgbe, fm10k), all of which are fixed identically by moving the rcu member earlier in their respective q_vector structures. 5. **Configuration-Dependent Bug**: This bug only manifests with large CONFIG_NR_CPUS values (likely >= 512 or higher), where the `cpumask_t` type becomes large enough to push the rcu member beyond the 4096-byte offset limit. Systems with high core counts are becoming more common in production environments. 6. **No Risk of Regression**: The change is minimal and doesn't alter any functionality. It's purely a structural reordering that maintains all existing behavior while fixing the compilation issue. 7. **Meets Stable Criteria**: This fix clearly meets the stable kernel criteria as it: - Fixes a real bug (compilation failure) - Is minimal and contained - Has no risk of introducing new issues - Affects users with legitimate configurations The commit is an excellent candidate for stable backporting as it fixes a real compilation issue that prevents kernel builds on systems with large CPU counts, and the fix is trivial with no risk of regression. drivers/net/ethernet/intel/fm10k/fm10k.h | 3 ++- drivers/net/ethernet/intel/i40e/i40e.h | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k.h b/drivers/net/ethernet/intel/fm10k/fm10k.h index 6119a41088381..65a2816142d96 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k.h +++ b/drivers/net/ethernet/intel/fm10k/fm10k.h @@ -189,13 +189,14 @@ struct fm10k_q_vector { struct fm10k_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; char name[IFNAMSIZ + 9]; #ifdef CONFIG_DEBUG_FS struct dentry *dbg_q_vector; #endif /* CONFIG_DEBUG_FS */ - struct rcu_head rcu; /* to avoid race with update stats on free */ /* for dynamic allocation of rings associated with this q_vector */ struct fm10k_ring ring[] ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h index dd630b6bc74bd..add9a3107d9a0 100644 --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -863,6 +863,7 @@ struct i40e_q_vector { u16 reg_idx; /* register index of the interrupt */ struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ struct i40e_ring_container rx; struct i40e_ring_container tx; @@ -873,7 +874,6 @@ struct i40e_q_vector { cpumask_t affinity_mask; struct irq_affinity_notify affinity_notify; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[I40E_INT_NAME_STR_LEN]; bool arm_wb_state; } ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h index 18251edbfabfb..3ea7095fc04f5 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h @@ -457,9 +457,10 @@ struct ixgbe_q_vector { struct ixgbe_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; int numa_node; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[IFNAMSIZ + 9]; /* for dynamic allocation of rings associated with this q_vector */ -- 2.39.5

1 month, 1 week

1
1
0 0

[PATCH AUTOSEL 5.15 1/2] ethernet: intel: fix building with large NR_CPUS

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 24171a5a4a952c26568ff0d2a0bc8c4708a95e1d ] With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to compile like: In function ‘i40e_free_q_vector’, inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3: 571 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’ 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \ drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’ 5113 | kfree_rcu(q_vector, rcu); | ^~~~~~~~~ The problem is that the 'rcu' member in 'q_vector' is too far from the start of the structure. Move this member before the CPU mask instead, in all three drivers. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: David S. Miller <davem(a)davemloft.net> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin(a)intel.com> Tested-by: Sunitha Mekala <sunithax.d.mekala(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Compilation Failure Fix**: This fixes a build-time compilation failure that occurs with large values of CONFIG_NR_CPUS. The error prevents the kernel from building successfully, which is a significant issue for systems configured with high CPU counts. 2. **Root Cause**: The issue stems from the `kfree_rcu()` macro in `include/linux/rcupdate.h:1084` which includes a `BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096)` check. This compile-time assertion ensures that the RCU head field is within the first 4096 bytes of the structure. 3. **Simple and Safe Fix**: The fix is straightforward - it moves the `struct rcu_head rcu` member earlier in the structure, placing it before the `cpumask_t affinity_mask` member. This is a safe change because: - It only reorders structure members - The RCU head doesn't need to be at any specific location functionally - Moving it earlier reduces the offset from the structure start - No functional code changes are required 4. **Affects Multiple Drivers**: The issue affects three Intel ethernet drivers (i40e, ixgbe, fm10k), all of which are fixed identically by moving the rcu member earlier in their respective q_vector structures. 5. **Configuration-Dependent Bug**: This bug only manifests with large CONFIG_NR_CPUS values (likely >= 512 or higher), where the `cpumask_t` type becomes large enough to push the rcu member beyond the 4096-byte offset limit. Systems with high core counts are becoming more common in production environments. 6. **No Risk of Regression**: The change is minimal and doesn't alter any functionality. It's purely a structural reordering that maintains all existing behavior while fixing the compilation issue. 7. **Meets Stable Criteria**: This fix clearly meets the stable kernel criteria as it: - Fixes a real bug (compilation failure) - Is minimal and contained - Has no risk of introducing new issues - Affects users with legitimate configurations The commit is an excellent candidate for stable backporting as it fixes a real compilation issue that prevents kernel builds on systems with large CPU counts, and the fix is trivial with no risk of regression. drivers/net/ethernet/intel/fm10k/fm10k.h | 3 ++- drivers/net/ethernet/intel/i40e/i40e.h | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k.h b/drivers/net/ethernet/intel/fm10k/fm10k.h index 6119a41088381..65a2816142d96 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k.h +++ b/drivers/net/ethernet/intel/fm10k/fm10k.h @@ -189,13 +189,14 @@ struct fm10k_q_vector { struct fm10k_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; char name[IFNAMSIZ + 9]; #ifdef CONFIG_DEBUG_FS struct dentry *dbg_q_vector; #endif /* CONFIG_DEBUG_FS */ - struct rcu_head rcu; /* to avoid race with update stats on free */ /* for dynamic allocation of rings associated with this q_vector */ struct fm10k_ring ring[] ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h index a143440f3db62..223d5831a5bbe 100644 --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -961,6 +961,7 @@ struct i40e_q_vector { u16 reg_idx; /* register index of the interrupt */ struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ struct i40e_ring_container rx; struct i40e_ring_container tx; @@ -971,7 +972,6 @@ struct i40e_q_vector { cpumask_t affinity_mask; struct irq_affinity_notify affinity_notify; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[I40E_INT_NAME_STR_LEN]; bool arm_wb_state; bool in_busy_poll; diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h index 737590a0d849e..09f7a3787f272 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h @@ -458,9 +458,10 @@ struct ixgbe_q_vector { struct ixgbe_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; int numa_node; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[IFNAMSIZ + 9]; /* for dynamic allocation of rings associated with this q_vector */ -- 2.39.5

1 month, 1 week

1
1
0 0

[PATCH AUTOSEL 6.1 1/3] ethernet: intel: fix building with large NR_CPUS

by Sasha Levin

From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 24171a5a4a952c26568ff0d2a0bc8c4708a95e1d ] With large values of CONFIG_NR_CPUS, three Intel ethernet drivers fail to compile like: In function ‘i40e_free_q_vector’, inlined from ‘i40e_vsi_alloc_q_vectors’ at drivers/net/ethernet/intel/i40e/i40e_main.c:12112:3: 571 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) include/linux/rcupdate.h:1084:17: note: in expansion of macro ‘BUILD_BUG_ON’ 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \ drivers/net/ethernet/intel/i40e/i40e_main.c:5113:9: note: in expansion of macro ‘kfree_rcu’ 5113 | kfree_rcu(q_vector, rcu); | ^~~~~~~~~ The problem is that the 'rcu' member in 'q_vector' is too far from the start of the structure. Move this member before the CPU mask instead, in all three drivers. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Acked-by: David S. Miller <davem(a)davemloft.net> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin(a)intel.com> Tested-by: Sunitha Mekala <sunithax.d.mekala(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Compilation Failure Fix**: This fixes a build-time compilation failure that occurs with large values of CONFIG_NR_CPUS. The error prevents the kernel from building successfully, which is a significant issue for systems configured with high CPU counts. 2. **Root Cause**: The issue stems from the `kfree_rcu()` macro in `include/linux/rcupdate.h:1084` which includes a `BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096)` check. This compile-time assertion ensures that the RCU head field is within the first 4096 bytes of the structure. 3. **Simple and Safe Fix**: The fix is straightforward - it moves the `struct rcu_head rcu` member earlier in the structure, placing it before the `cpumask_t affinity_mask` member. This is a safe change because: - It only reorders structure members - The RCU head doesn't need to be at any specific location functionally - Moving it earlier reduces the offset from the structure start - No functional code changes are required 4. **Affects Multiple Drivers**: The issue affects three Intel ethernet drivers (i40e, ixgbe, fm10k), all of which are fixed identically by moving the rcu member earlier in their respective q_vector structures. 5. **Configuration-Dependent Bug**: This bug only manifests with large CONFIG_NR_CPUS values (likely >= 512 or higher), where the `cpumask_t` type becomes large enough to push the rcu member beyond the 4096-byte offset limit. Systems with high core counts are becoming more common in production environments. 6. **No Risk of Regression**: The change is minimal and doesn't alter any functionality. It's purely a structural reordering that maintains all existing behavior while fixing the compilation issue. 7. **Meets Stable Criteria**: This fix clearly meets the stable kernel criteria as it: - Fixes a real bug (compilation failure) - Is minimal and contained - Has no risk of introducing new issues - Affects users with legitimate configurations The commit is an excellent candidate for stable backporting as it fixes a real compilation issue that prevents kernel builds on systems with large CPU counts, and the fix is trivial with no risk of regression. drivers/net/ethernet/intel/fm10k/fm10k.h | 3 ++- drivers/net/ethernet/intel/i40e/i40e.h | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/fm10k/fm10k.h b/drivers/net/ethernet/intel/fm10k/fm10k.h index 6119a41088381..65a2816142d96 100644 --- a/drivers/net/ethernet/intel/fm10k/fm10k.h +++ b/drivers/net/ethernet/intel/fm10k/fm10k.h @@ -189,13 +189,14 @@ struct fm10k_q_vector { struct fm10k_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; char name[IFNAMSIZ + 9]; #ifdef CONFIG_DEBUG_FS struct dentry *dbg_q_vector; #endif /* CONFIG_DEBUG_FS */ - struct rcu_head rcu; /* to avoid race with update stats on free */ /* for dynamic allocation of rings associated with this q_vector */ struct fm10k_ring ring[] ____cacheline_internodealigned_in_smp; diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h index 22ac8c48ca340..61590e92f3abc 100644 --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -980,6 +980,7 @@ struct i40e_q_vector { u16 reg_idx; /* register index of the interrupt */ struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ struct i40e_ring_container rx; struct i40e_ring_container tx; @@ -990,7 +991,6 @@ struct i40e_q_vector { cpumask_t affinity_mask; struct irq_affinity_notify affinity_notify; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[I40E_INT_NAME_STR_LEN]; bool arm_wb_state; bool in_busy_poll; diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h index 2bf387e52e202..f49b99b175ef4 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h @@ -498,9 +498,10 @@ struct ixgbe_q_vector { struct ixgbe_ring_container rx, tx; struct napi_struct napi; + struct rcu_head rcu; /* to avoid race with update stats on free */ + cpumask_t affinity_mask; int numa_node; - struct rcu_head rcu; /* to avoid race with update stats on free */ char name[IFNAMSIZ + 9]; /* for dynamic allocation of rings associated with this q_vector */ -- 2.39.5

1 month, 1 week

1
2
0 0

[PATCH AUTOSEL 6.6 1/5] ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx

by Sasha Levin

From: Lane Odenbach <laodenbach(a)gmail.com> [ Upstream commit 7bab1bd9fdf15b9fa7e6a4b0151deab93df3c80d ] This fixes the internal microphone in the stated device Signed-off-by: Lane Odenbach <laodenbach(a)gmail.com> Link: https://patch.msgid.link/20250715182038.10048-1-laodenbach@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Bug Fix for Hardware Functionality**: The commit fixes a non- functional internal microphone on the HP Laptop 17 cp-2033dx. This is a hardware enablement bug fix that prevents users from using a core functionality of their laptop. 2. **Minimal and Contained Change**: The change is extremely minimal - it only adds 7 lines to the DMI quirk table: ```c + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "HP"), + DMI_MATCH(DMI_BOARD_NAME, "8A81"), + } + }, ``` This is a simple DMI match addition with no algorithmic changes or side effects. 3. **Low Risk of Regression**: DMI quirk additions are inherently safe as they only affect the specific hardware model being added. The change cannot impact any other system that doesn't match the exact DMI strings. 4. **Follows Established Pattern**: All five similar commits provided as reference (for HP models with board names 8BD6, 8A3E, 8A22, 8A27, and other manufacturers) were marked as "Backport Status: YES". This type of commit has a well-established history of being backported. 5. **User-Impacting Issue**: Without this quirk, users of the HP Laptop 17 cp-2033dx cannot use their internal microphone, which is essential functionality for video calls, recording, and voice commands. This significantly degrades the user experience. 6. **Consistent with Stable Tree Rules**: The commit meets the stable kernel criteria: - It fixes a real bug that bothers users (non-functional microphone) - It's obviously correct and tested (standard DMI quirk pattern) - It's small (7 lines) - It doesn't add new features, only fixes existing functionality The AMD Yellow Carp (YC) audio driver uses DMI quirks to enable the internal microphone on specific laptop models. Without these quirks, the DMIC (Digital Microphone) won't be properly initialized on affected systems. This is a common pattern in the Linux kernel for handling hardware-specific configurations. sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 66ef8f4fd02cd..74f8e12aa7107 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -577,6 +577,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_BOARD_NAME, "8A7F"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "HP"), + DMI_MATCH(DMI_BOARD_NAME, "8A81"), + } + }, { .driver_data = &acp6x_card, .matches = { -- 2.39.5

1 month, 1 week

1
4
0 0

[PATCH AUTOSEL 6.12 1/6] ASoC: amd: yc: Add DMI quirk for HP Laptop 17 cp-2033dx

by Sasha Levin

From: Lane Odenbach <laodenbach(a)gmail.com> [ Upstream commit 7bab1bd9fdf15b9fa7e6a4b0151deab93df3c80d ] This fixes the internal microphone in the stated device Signed-off-by: Lane Odenbach <laodenbach(a)gmail.com> Link: https://patch.msgid.link/20250715182038.10048-1-laodenbach@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Bug Fix for Hardware Functionality**: The commit fixes a non- functional internal microphone on the HP Laptop 17 cp-2033dx. This is a hardware enablement bug fix that prevents users from using a core functionality of their laptop. 2. **Minimal and Contained Change**: The change is extremely minimal - it only adds 7 lines to the DMI quirk table: ```c + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "HP"), + DMI_MATCH(DMI_BOARD_NAME, "8A81"), + } + }, ``` This is a simple DMI match addition with no algorithmic changes or side effects. 3. **Low Risk of Regression**: DMI quirk additions are inherently safe as they only affect the specific hardware model being added. The change cannot impact any other system that doesn't match the exact DMI strings. 4. **Follows Established Pattern**: All five similar commits provided as reference (for HP models with board names 8BD6, 8A3E, 8A22, 8A27, and other manufacturers) were marked as "Backport Status: YES". This type of commit has a well-established history of being backported. 5. **User-Impacting Issue**: Without this quirk, users of the HP Laptop 17 cp-2033dx cannot use their internal microphone, which is essential functionality for video calls, recording, and voice commands. This significantly degrades the user experience. 6. **Consistent with Stable Tree Rules**: The commit meets the stable kernel criteria: - It fixes a real bug that bothers users (non-functional microphone) - It's obviously correct and tested (standard DMI quirk pattern) - It's small (7 lines) - It doesn't add new features, only fixes existing functionality The AMD Yellow Carp (YC) audio driver uses DMI quirks to enable the internal microphone on specific laptop models. Without these quirks, the DMIC (Digital Microphone) won't be properly initialized on affected systems. This is a common pattern in the Linux kernel for handling hardware-specific configurations. sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index 1689b6b22598e..42d123cb8b4c6 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -577,6 +577,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_BOARD_NAME, "8A7F"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "HP"), + DMI_MATCH(DMI_BOARD_NAME, "8A81"), + } + }, { .driver_data = &acp6x_card, .matches = { -- 2.39.5

1 month, 1 week

1
5
0 0

[PATCH AUTOSEL 6.15 1/8] drm/radeon: Do not hold console lock while suspending clients

by Sasha Levin

From: Thomas Zimmermann <tzimmermann(a)suse.de> [ Upstream commit 5dd0b96118e09a3725e3f83543e133b1fd02c18c ] The radeon driver holds the console lock while suspending in-kernel DRM clients. This creates a circular dependency with the client-list mutex, which is supposed to be acquired first. Reported when combining radeon with another DRM driver. Therefore, do not take the console lock in radeon, but let the fbdev DRM client acquire the lock when needed. This is what all other DRM drivers so. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reported-by: Jeff Johnson <jeff.johnson(a)oss.qualcomm.com> Closes: https://lore.kernel.org/dri-devel/0a087cfd-bd4c-48f1-aa2f-4a3b12593935@oss.… Suggested-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 612ec7c69d04cb58beb1332c2806da9f2f47a3ae) Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my analysis of the commit and the code changes, here is my assessment: **Answer: YES** This commit should be backported to stable kernel trees. Here's my extensive explanation: ## 1. **The commit fixes a real circular locking dependency bug** The commit message clearly states this fixes a "circular dependency with the client-list mutex" that was "Reported when combining radeon with another DRM driver." This is a real bug that can lead to deadlocks in production systems. ## 2. **The fix is minimal and focused** The code changes are very small and targeted: - In `radeon_suspend_kms()`: Changed from calling `drm_client_dev_suspend(dev, true)` with console_lock held to `drm_client_dev_suspend(dev, false)` without holding the lock - In `radeon_resume_kms()`: Removed the console_lock/unlock calls around `drm_client_dev_resume()` The second parameter to `drm_client_dev_suspend()` indicates whether the caller holds the console lock. By changing it from `true` to `false`, radeon now follows the same pattern as other DRM drivers. ## 3. **This aligns radeon with other DRM drivers** The commit message explicitly states: "This is what all other DRM drivers so." Looking at the similar commits provided: - Similar Commit #1 shows radeon being updated to use the new client suspend/resume infrastructure - Similar Commit #4 shows amdgpu (the successor to radeon) already using `drm_client_dev_suspend(dev, false)` without holding the console lock ## 4. **The bug has real-world impact** The issue was reported by a real user (Jeff Johnson) and occurs "when combining radeon with another DRM driver." Multi-GPU systems are increasingly common, especially with integrated + discrete GPU configurations. ## 5. **Low regression risk** The change removes lock acquisition rather than adding it, which generally has lower risk. The fbdev DRM client will acquire the console lock when needed (as mentioned in the commit message), so the necessary locking still occurs - just at the correct layer to avoid the circular dependency. ## 6. **Similar to historical fixes** Looking at Similar Commit #5 (amdgpu console lock restructuring), we can see there's a history of console lock ordering issues in AMD GPU drivers that have been fixed in the past. This suggests these types of fixes are considered important enough for the maintainers. ## 7. **The fix is already cherry-picked** The commit message shows "(cherry picked from commit 612ec7c69d04cb58beb1332c2806da9f2f47a3ae)" indicating this was already selected for backporting by maintainers. The only potential concern would be ensuring that the DRM client infrastructure this depends on is present in the stable kernels being targeted, but given that this is fixing a bug in existing code paths, the infrastructure must already be there. drivers/gpu/drm/radeon/radeon_device.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index bbd39348a7aba..6f50cfdfe5a2e 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1635,11 +1635,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend, pci_set_power_state(pdev, PCI_D3hot); } - if (notify_clients) { - console_lock(); - drm_client_dev_suspend(dev, true); - console_unlock(); - } + if (notify_clients) + drm_client_dev_suspend(dev, false); + return 0; } -- 2.39.5

1 month, 1 week

1
7
0 0

Re: Follow Up

by Clint Carnell

Hi, I wanted to check with you if you had time to go through my previous email. Let me know your thoughts about acquiring this email list. Regards, *Clint* *____________________________________________________________________________* Hi, We have successfully built a verified file of *Healthcare Industry *contacts with accurate emails. Would you be interested in acquiring* Healthcare Industry Professionals List* across North America, UK, Europe and Global? *Few Lists**:* Physicians and Surgeons Lists, Nurses Lists, Hospitals Lists, Ambulatory Surgery Centers List, Hospitals Executives Decision Makers list, Home Healthcare Lists, Pharmacy Lists, Clinical Director/Managers Email List, Facility Manager Lists, Hospital Administrator Lists, Nurse Manager Lists, Clinical Director Email List, Laboratory Managers & Directors Email List, General Medical & Surgical Hospitals Executives Email List, Pharmacy Decision Makers List, NP’s & PA’s Email list many more. *Few Physician Specialties**:* Anesthesiologist, Cardiologist, Dermatologist, Dentist, Emergency Medicine, Family Practitioners, Gastroenterologist, General Practitioners, Gynecologist, Hospitalist, Hematologist, Internal Medicine, Nephrologists, Neurologist, Oncologist, Ophthalmologist, Optometrist, Pathologist, Pediatrician, Psychiatrist, Psychologist, Plastic Surgeon, Podiatrist, Pulmonologist, Radiologist, Rheumatologist, Urologist, Physician Assistants, Nurse Practitioners, Registered Nurses, etc. *Our list comes with*: Company/Organization, Website, Contacts, Title, Address, Direct Number and Email Address, Revenue Size, Employee Size, Industry segment. Please send me your *target audience and geographical area*, so that I can give you more information, *Counts and Pricing *for your review. Looking forward to hearing from you. Regards, *Clint Carnell| Customer Success Manager* *B2B Marketing & Tradeshow Specialist*Clint(a)b2bleadsonline.us P *We have a responsibility to the environment* *Before printing this e-mail or any other document, let's ask ourselves whether we need a hard copy*

1 month, 1 week

1
0
0 0

[PATCH net, 1/2] net: core: Fix missing init of llist_node in setup_net()

by Haiyang Zhang

From: Haiyang Zhang <haiyangz(a)microsoft.com> Add init_llist_node for lock-less list nodes in struct net in setup_net(), so we can test if a node is on a list or not. Cc: stable(a)vger.kernel.org Fixes: d6b3358a2813 ("llist: add interface to check if a node is on a list.") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> --- net/core/net_namespace.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c index ae54f26709ca..2a821849558f 100644 --- a/net/core/net_namespace.c +++ b/net/core/net_namespace.c @@ -434,6 +434,9 @@ static __net_init int setup_net(struct net *net) LIST_HEAD(net_exit_list); int error = 0; + init_llist_node(&net->defer_free_list); + init_llist_node(&net->cleanup_list); + preempt_disable(); net->net_cookie = gen_cookie_next(&net_cookie); preempt_enable(); -- 2.34.1

1 month, 1 week

3
2
0 0

[PATCH v2] media: cec: extron-da-hd-4k-plus: drop external-module make commands

by Randy Dunlap

Delete the external-module style Makefile commands. They are not needed for in-tree modules. This is the only Makefile in the kernel tree (aside from tools/ and samples/) that uses this Makefile style. The same files are built with or without this patch. Fixes: 056f2821b631 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: stable(a)vger.kernel.org --- v2 changes, per the Media CI bot: - add Cc: stable(a)vger.kernel.org - move other Cc:s to mail headers only, not in the signoff area Cc: Hans Verkuil <hverkuil(a)kernel.org> Cc: Masahiro Yamada <masahiroy(a)kernel.org> drivers/media/cec/usb/extron-da-hd-4k-plus/Makefile | 6 ------ 1 file changed, 6 deletions(-) --- linux-next-20250718.orig/drivers/media/cec/usb/extron-da-hd-4k-plus/Makefile +++ linux-next-20250718/drivers/media/cec/usb/extron-da-hd-4k-plus/Makefile @@ -1,8 +1,2 @@ extron-da-hd-4k-plus-cec-objs := extron-da-hd-4k-plus.o cec-splitter.o obj-$(CONFIG_USB_EXTRON_DA_HD_4K_PLUS_CEC) := extron-da-hd-4k-plus-cec.o - -all: - $(MAKE) -C $(KDIR) M=$(shell pwd) modules - -install: - $(MAKE) -C $(KDIR) M=$(shell pwd) modules_install

1 month, 1 week

1
0
0 0

[PATCH net, 2/2] hv_netvsc: Fix panic during namespace deletion with VF

by Haiyang Zhang

From: Haiyang Zhang <haiyangz(a)microsoft.com> The existing code move the VF NIC to new namespace when NETDEV_REGISTER is received on netvsc NIC. During deletion of the namespace, default_device_exit_batch() >> default_device_exit_net() is called. When netvsc NIC is moved back and registered to the default namespace, it automatically brings VF NIC back to the default namespace. This will cause the default_device_exit_net() >> for_each_netdev_safe loop unable to detect the list end, and hit NULL ptr: [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0 [ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 231.450246] #PF: supervisor read access in kernel mode [ 231.450579] #PF: error_code(0x0000) - not-present page [ 231.450916] PGD 17b8a8067 P4D 0 [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024 [ 231.452692] Workqueue: netns cleanup_net [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0 [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00 [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246 [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564 [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000 [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340 [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340 [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000 [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0 [ 231.458434] Call Trace: [ 231.458600] <TASK> [ 231.458777] ops_undo_list+0x100/0x220 [ 231.459015] cleanup_net+0x1b8/0x300 [ 231.459285] process_one_work+0x184/0x340 To fix it, skip the VF NIC's namespace change with netvsc when the VF namespace is being cleaned up, because the default_device_exit_net() will do it later. Cc: stable(a)vger.kernel.org Fixes: 4c262801ea60 ("hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> --- drivers/net/hyperv/netvsc_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 8be9bce66a4e..8fc05a8c0018 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2788,13 +2788,21 @@ static void netvsc_event_set_vf_ns(struct net_device *ndev) { struct net_device_context *ndev_ctx = netdev_priv(ndev); struct net_device *vf_netdev; + struct net *vfnet; int ret; vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev); if (!vf_netdev) return; - if (!net_eq(dev_net(ndev), dev_net(vf_netdev))) { + vfnet = dev_net(vf_netdev); + /* Do not move it now if its net is being cleaned up, + * net_cleanup_work will move it. + */ + if (llist_on_list(&vfnet->cleanup_list)) + return; + + if (!net_eq(dev_net(ndev), vfnet)) { ret = dev_change_net_namespace(vf_netdev, dev_net(ndev), "eth%d"); if (ret) -- 2.34.1

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] usb: hub: Don't try to recover devices lost during warm" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 2521106fc732b0b75fd3555c689b1ed1d29d273c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072256-verbally-zippy-bbd6@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2521106fc732b0b75fd3555c689b1ed1d29d273c Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Mon, 23 Jun 2025 16:39:47 +0300 Subject: [PATCH] usb: hub: Don't try to recover devices lost during warm reset. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hub driver warm-resets ports in SS.Inactive or Compliance mode to recover a possible connected device. The port reset code correctly detects if a connection is lost during reset, but hub driver port_event() fails to take this into account in some cases. port_event() ends up using stale values and assumes there is a connected device, and will try all means to recover it, including power-cycling the port. Details: This case was triggered when xHC host was suspended with DbC (Debug Capability) enabled and connected. DbC turns one xHC port into a simple usb debug device, allowing debugging a system with an A-to-A USB debug cable. xhci DbC code disables DbC when xHC is system suspended to D3, and enables it back during resume. We essentially end up with two hosts connected to each other during suspend, and, for a short while during resume, until DbC is enabled back. The suspended xHC host notices some activity on the roothub port, but can't train the link due to being suspended, so xHC hardware sets a CAS (Cold Attach Status) flag for this port to inform xhci host driver that the port needs to be warm reset once xHC resumes. CAS is xHCI specific, and not part of USB specification, so xhci driver tells usb core that the port has a connection and link is in compliance mode. Recovery from complinace mode is similar to CAS recovery. xhci CAS driver support that fakes a compliance mode connection was added in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Once xHCI resumes and DbC is enabled back, all activity on the xHC roothub host side port disappears. The hub driver will anyway think port has a connection and link is in compliance mode, and hub driver will try to recover it. The port power-cycle during recovery seems to cause issues to the active DbC connection. Fix this by clearing connect_change flag if hub_port_reset() returns -ENOTCONN, thus avoiding the whole unnecessary port recovery and initialization attempt. Cc: stable(a)vger.kernel.org Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 3e1215f7a9a0..256fe8c86828 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1) struct usb_device *hdev = hub->hdev; u16 portstatus, portchange; int i = 0; + int err; connect_change = test_bit(port1, hub->change_bits); clear_bit(port1, hub->event_bits); @@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1) } else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION) || udev->state == USB_STATE_NOTATTACHED) { dev_dbg(&port_dev->dev, "do warm reset, port only\n"); - if (hub_port_reset(hub, port1, NULL, - HUB_BH_RESET_TIME, true) < 0) + err = hub_port_reset(hub, port1, NULL, + HUB_BH_RESET_TIME, true); + if (!udev && err == -ENOTCONN) + connect_change = 0; + else if (err < 0) hub_port_disable(hub, port1, 1); } else { dev_dbg(&port_dev->dev, "do warm reset, full device\n");

1 month, 1 week

2
2
0 0

FAILED: patch "[PATCH] usb: hub: Don't try to recover devices lost during warm" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 2521106fc732b0b75fd3555c689b1ed1d29d273c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072258-fervor-reabsorb-1b7a@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2521106fc732b0b75fd3555c689b1ed1d29d273c Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Mon, 23 Jun 2025 16:39:47 +0300 Subject: [PATCH] usb: hub: Don't try to recover devices lost during warm reset. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hub driver warm-resets ports in SS.Inactive or Compliance mode to recover a possible connected device. The port reset code correctly detects if a connection is lost during reset, but hub driver port_event() fails to take this into account in some cases. port_event() ends up using stale values and assumes there is a connected device, and will try all means to recover it, including power-cycling the port. Details: This case was triggered when xHC host was suspended with DbC (Debug Capability) enabled and connected. DbC turns one xHC port into a simple usb debug device, allowing debugging a system with an A-to-A USB debug cable. xhci DbC code disables DbC when xHC is system suspended to D3, and enables it back during resume. We essentially end up with two hosts connected to each other during suspend, and, for a short while during resume, until DbC is enabled back. The suspended xHC host notices some activity on the roothub port, but can't train the link due to being suspended, so xHC hardware sets a CAS (Cold Attach Status) flag for this port to inform xhci host driver that the port needs to be warm reset once xHC resumes. CAS is xHCI specific, and not part of USB specification, so xhci driver tells usb core that the port has a connection and link is in compliance mode. Recovery from complinace mode is similar to CAS recovery. xhci CAS driver support that fakes a compliance mode connection was added in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Once xHCI resumes and DbC is enabled back, all activity on the xHC roothub host side port disappears. The hub driver will anyway think port has a connection and link is in compliance mode, and hub driver will try to recover it. The port power-cycle during recovery seems to cause issues to the active DbC connection. Fix this by clearing connect_change flag if hub_port_reset() returns -ENOTCONN, thus avoiding the whole unnecessary port recovery and initialization attempt. Cc: stable(a)vger.kernel.org Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 3e1215f7a9a0..256fe8c86828 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1) struct usb_device *hdev = hub->hdev; u16 portstatus, portchange; int i = 0; + int err; connect_change = test_bit(port1, hub->change_bits); clear_bit(port1, hub->event_bits); @@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1) } else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION) || udev->state == USB_STATE_NOTATTACHED) { dev_dbg(&port_dev->dev, "do warm reset, port only\n"); - if (hub_port_reset(hub, port1, NULL, - HUB_BH_RESET_TIME, true) < 0) + err = hub_port_reset(hub, port1, NULL, + HUB_BH_RESET_TIME, true); + if (!udev && err == -ENOTCONN) + connect_change = 0; + else if (err < 0) hub_port_disable(hub, port1, 1); } else { dev_dbg(&port_dev->dev, "do warm reset, full device\n");

1 month, 1 week

2
2
0 0

FAILED: patch "[PATCH] usb: hub: Don't try to recover devices lost during warm" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 2521106fc732b0b75fd3555c689b1ed1d29d273c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072257-ranging-salvaging-2f13@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2521106fc732b0b75fd3555c689b1ed1d29d273c Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Mon, 23 Jun 2025 16:39:47 +0300 Subject: [PATCH] usb: hub: Don't try to recover devices lost during warm reset. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hub driver warm-resets ports in SS.Inactive or Compliance mode to recover a possible connected device. The port reset code correctly detects if a connection is lost during reset, but hub driver port_event() fails to take this into account in some cases. port_event() ends up using stale values and assumes there is a connected device, and will try all means to recover it, including power-cycling the port. Details: This case was triggered when xHC host was suspended with DbC (Debug Capability) enabled and connected. DbC turns one xHC port into a simple usb debug device, allowing debugging a system with an A-to-A USB debug cable. xhci DbC code disables DbC when xHC is system suspended to D3, and enables it back during resume. We essentially end up with two hosts connected to each other during suspend, and, for a short while during resume, until DbC is enabled back. The suspended xHC host notices some activity on the roothub port, but can't train the link due to being suspended, so xHC hardware sets a CAS (Cold Attach Status) flag for this port to inform xhci host driver that the port needs to be warm reset once xHC resumes. CAS is xHCI specific, and not part of USB specification, so xhci driver tells usb core that the port has a connection and link is in compliance mode. Recovery from complinace mode is similar to CAS recovery. xhci CAS driver support that fakes a compliance mode connection was added in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Once xHCI resumes and DbC is enabled back, all activity on the xHC roothub host side port disappears. The hub driver will anyway think port has a connection and link is in compliance mode, and hub driver will try to recover it. The port power-cycle during recovery seems to cause issues to the active DbC connection. Fix this by clearing connect_change flag if hub_port_reset() returns -ENOTCONN, thus avoiding the whole unnecessary port recovery and initialization attempt. Cc: stable(a)vger.kernel.org Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 3e1215f7a9a0..256fe8c86828 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1) struct usb_device *hdev = hub->hdev; u16 portstatus, portchange; int i = 0; + int err; connect_change = test_bit(port1, hub->change_bits); clear_bit(port1, hub->event_bits); @@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1) } else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION) || udev->state == USB_STATE_NOTATTACHED) { dev_dbg(&port_dev->dev, "do warm reset, port only\n"); - if (hub_port_reset(hub, port1, NULL, - HUB_BH_RESET_TIME, true) < 0) + err = hub_port_reset(hub, port1, NULL, + HUB_BH_RESET_TIME, true); + if (!udev && err == -ENOTCONN) + connect_change = 0; + else if (err < 0) hub_port_disable(hub, port1, 1); } else { dev_dbg(&port_dev->dev, "do warm reset, full device\n");

1 month, 1 week

2
2
0 0

FAILED: patch "[PATCH] usb: hub: fix detection of high tier USB3 devices behind" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 8f5b7e2bec1c36578fdaa74a6951833541103e27 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072211-wolverine-heroics-ee1b@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8f5b7e2bec1c36578fdaa74a6951833541103e27 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Wed, 11 Jun 2025 14:24:41 +0300 Subject: [PATCH] usb: hub: fix detection of high tier USB3 devices behind suspended hubs USB3 devices connected behind several external suspended hubs may not be detected when plugged in due to aggressive hub runtime pm suspend. The hub driver immediately runtime-suspends hubs if there are no active children or port activity. There is a delay between the wake signal causing hub resume, and driver visible port activity on the hub downstream facing ports. Most of the LFPS handshake, resume signaling and link training done on the downstream ports is not visible to the hub driver until completed, when device then will appear fully enabled and running on the port. This delay between wake signal and detectable port change is even more significant with chained suspended hubs where the wake signal will propagate upstream first. Suspended hubs will only start resuming downstream ports after upstream facing port resumes. The hub driver may resume a USB3 hub, read status of all ports, not yet see any activity, and runtime suspend back the hub before any port activity is visible. This exact case was seen when conncting USB3 devices to a suspended Thunderbolt dock. USB3 specification defines a 100ms tU3WakeupRetryDelay, indicating USB3 devices expect to be resumed within 100ms after signaling wake. if not then device will resend the wake signal. Give the USB3 hubs twice this time (200ms) to detect any port changes after resume, before allowing hub to runtime suspend again. Cc: stable <stable(a)kernel.org> Fixes: 2839f5bcfcfc ("USB: Turn on auto-suspend for USB 3.0 hubs.") Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20250611112441.2267883-1-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 770d1e91183c..5c12dfdef569 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -68,6 +68,12 @@ */ #define USB_SHORT_SET_ADDRESS_REQ_TIMEOUT 500 /* ms */ +/* + * Give SS hubs 200ms time after wake to train downstream links before + * assuming no port activity and allowing hub to runtime suspend back. + */ +#define USB_SS_PORT_U0_WAKE_TIME 200 /* ms */ + /* Protect struct usb_device->state and ->children members * Note: Both are also protected by ->dev.sem, except that ->state can * change to USB_STATE_NOTATTACHED even when the semaphore isn't held. */ @@ -1068,11 +1074,12 @@ int usb_remove_device(struct usb_device *udev) enum hub_activation_type { HUB_INIT, HUB_INIT2, HUB_INIT3, /* INITs must come first */ - HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME, + HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME, HUB_POST_RESUME, }; static void hub_init_func2(struct work_struct *ws); static void hub_init_func3(struct work_struct *ws); +static void hub_post_resume(struct work_struct *ws); static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) { @@ -1095,6 +1102,13 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) goto init2; goto init3; } + + if (type == HUB_POST_RESUME) { + usb_autopm_put_interface_async(to_usb_interface(hub->intfdev)); + hub_put(hub); + return; + } + hub_get(hub); /* The superspeed hub except for root hub has to use Hub Depth @@ -1343,6 +1357,16 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) device_unlock(&hdev->dev); } + if (type == HUB_RESUME && hub_is_superspeed(hub->hdev)) { + /* give usb3 downstream links training time after hub resume */ + INIT_DELAYED_WORK(&hub->init_work, hub_post_resume); + queue_delayed_work(system_power_efficient_wq, &hub->init_work, + msecs_to_jiffies(USB_SS_PORT_U0_WAKE_TIME)); + usb_autopm_get_interface_no_resume( + to_usb_interface(hub->intfdev)); + return; + } + hub_put(hub); } @@ -1361,6 +1385,13 @@ static void hub_init_func3(struct work_struct *ws) hub_activate(hub, HUB_INIT3); } +static void hub_post_resume(struct work_struct *ws) +{ + struct usb_hub *hub = container_of(ws, struct usb_hub, init_work.work); + + hub_activate(hub, HUB_POST_RESUME); +} + enum hub_quiescing_type { HUB_DISCONNECT, HUB_PRE_RESET, HUB_SUSPEND };

1 month, 1 week

2
1
0 0

FAILED: patch "[PATCH] comedi: Fix initialization of data for instructions that" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 46d8c744136ce2454aa4c35c138cc06817f92b8e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072152-submitter-sterile-1681@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 46d8c744136ce2454aa4c35c138cc06817f92b8e Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Mon, 7 Jul 2025 17:14:39 +0100 Subject: [PATCH] comedi: Fix initialization of data for instructions that write to subdevice Some Comedi subdevice instruction handlers are known to access instruction data elements beyond the first `insn->n` elements in some cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions allocate at least `MIN_SAMPLES` (16) data elements to deal with this, but they do not initialize all of that. For Comedi instruction codes that write to the subdevice, the first `insn->n` data elements are copied from user-space, but the remaining elements are left uninitialized. That could be a problem if the subdevice instruction handler reads the uninitialized data. Ensure that the first `MIN_SAMPLES` elements are initialized before calling these instruction handlers, filling the uncopied elements with 0. For `do_insnlist_ioctl()`, the same data buffer elements are used for handling a list of instructions, so ensure the first `MIN_SAMPLES` elements are initialized for each instruction that writes to the subdevice. Fixes: ed9eccbe8970 ("Staging: add comedi core") Cc: stable(a)vger.kernel.org # 5.13+ Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Link: https://lore.kernel.org/r/20250707161439.88385-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/comedi/comedi_fops.c b/drivers/comedi/comedi_fops.c index 962fb9b18a52..c83fd14dd7ad 100644 --- a/drivers/comedi/comedi_fops.c +++ b/drivers/comedi/comedi_fops.c @@ -1556,21 +1556,27 @@ static int do_insnlist_ioctl(struct comedi_device *dev, } for (i = 0; i < n_insns; ++i) { + unsigned int n = insns[i].n; + if (insns[i].insn & INSN_MASK_WRITE) { if (copy_from_user(data, insns[i].data, - insns[i].n * sizeof(unsigned int))) { + n * sizeof(unsigned int))) { dev_dbg(dev->class_dev, "copy_from_user failed\n"); ret = -EFAULT; goto error; } + if (n < MIN_SAMPLES) { + memset(&data[n], 0, (MIN_SAMPLES - n) * + sizeof(unsigned int)); + } } ret = parse_insn(dev, insns + i, data, file); if (ret < 0) goto error; if (insns[i].insn & INSN_MASK_READ) { if (copy_to_user(insns[i].data, data, - insns[i].n * sizeof(unsigned int))) { + n * sizeof(unsigned int))) { dev_dbg(dev->class_dev, "copy_to_user failed\n"); ret = -EFAULT; @@ -1643,6 +1649,10 @@ static int do_insn_ioctl(struct comedi_device *dev, ret = -EFAULT; goto error; } + if (insn->n < MIN_SAMPLES) { + memset(&data[insn->n], 0, + (MIN_SAMPLES - insn->n) * sizeof(unsigned int)); + } } ret = parse_insn(dev, insn, data, file); if (ret < 0)

1 month, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror