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

[PATCH 0/2] drm/xe: Fix and refactor CONFIG_DRM_XE_DEBUG_GUC

by Lucas De Marchi

There was a missing call to stack_depot_init() that is needed if CONFIG_DRM_XE_DEBUG_GUC is defined. That is fixed in the simplest possible way in the first patch. Second patch refactors it to try to isolate the ifdefs in specific functions related to CONFIG_DRM_XE_DEBUG and CONFIG_DRM_XE_DEBUG_GUC. Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- Lucas De Marchi (2): drm/xe/guc: Fix stack_depot usage drm/xe/guc_ct: Cleanup ifdef'ry drivers/gpu/drm/xe/xe_guc_ct.c | 204 +++++++++++++++++++++-------------------- 1 file changed, 107 insertions(+), 97 deletions(-) base-commit: b603326a067916accf680fd623f4fc3c22bba487 change-id: 20251117-fix-debug-guc-3d79bbe9dead Lucas De Marchi

2 days, 5 hours

3
7
0 0

Re: RFQ

by Zarja®

2 days, 6 hours

1
0
0 0

+ unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path has been added to the -mm mm-nonmm-unstable branch. Its filename is unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path Date: Tue, 18 Nov 2025 14:45:50 +0800 If unshare_nsproxy_namespaces() successfully creates the new_nsproxy, but then set_cred_ucounts() fails, on its error path there is no cleanup for new_nsproxy, so it is leaked. Let's fix that by freeing new_nsproxy if it's not NULL on this error path. Link: https://lkml.kernel.org/r/20251118064552.936962-1-ptikhomirov@virtuozzo.com Fixes: 905ae01c4ae2a ("Add a reference to ucounts for each cred") Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Acked-by: Alexey Gladkov <legion(a)kernel.org> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Ben Segall <bsegall(a)google.com> Cc: Dietmar Eggemann <dietmar.eggemann(a)arm.com> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mel Gorman <mgorman <mgorman(a)suse.de> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Valentin Schneider <vschneid(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/fork.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/kernel/fork.c~unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path +++ a/kernel/fork.c @@ -3133,8 +3133,11 @@ int ksys_unshare(unsigned long unshare_f if (new_cred) { err = set_cred_ucounts(new_cred); - if (err) + if (err) { + if (new_nsproxy) + free_nsproxy(new_nsproxy); goto bad_unshare_cleanup_cred; + } } if (new_fs || new_fd || do_sysvsem || new_cred || new_nsproxy) { _ Patches currently in -mm which might be from ptikhomirov(a)virtuozzo.com are unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch

2 days, 8 hours

1
0
0 0

[PATCH v2 0/3] SDM630/660: Add missing MDSS reset

by Alexey Minnekhanov

Since kernel 6.17 display stack needs to reset the hardware properly to ensure that we don't run into issues with the hardware configured by the bootloader. MDSS reset is necessary to have working display when the bootloader has already initialized it for the boot splash screen. Signed-off-by: Alexey Minnekhanov <alexeymin(a)postmarketos.org> --- Changes in v2: - Added "Fixes" tag, pointing to commit which is the root cause for exposing this "bug", which is only present since 6.17 - Extended commit messages - Prepared series using correct user.email git setting - Link to v1: https://lore.kernel.org/r/20251031-sdm660-mdss-reset-v1-0-14cb4e6836f2@post… --- Alexey Minnekhanov (3): dt-bindings: clock: mmcc-sdm660: Add missing MDSS reset clk: qcom: mmcc-sdm660: Add missing MDSS reset arm64: dts: qcom: sdm630: Add missing MDSS reset arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 + drivers/clk/qcom/mmcc-sdm660.c | 1 + include/dt-bindings/clock/qcom,mmcc-sdm660.h | 1 + 3 files changed, 3 insertions(+) --- base-commit: 1cc41c88ef00de0f3216c5f4b9cfab47de1c49d3 change-id: 20251031-sdm660-mdss-reset-015a46a238b5 Best regards, -- Alexey Minnekhanov <alexeymin(a)postmarketos.org>

2 days, 8 hours

5
8
0 0

[PATCH] scsi: target: reset t_task_cdb pointer in error case

by Ваторопин Андрей

From: Andrey Vatoropin <a.vatoropin(a)crpt.ru> If allocation of cmd->t_task_cdb fails, it remains NULL but is later dereferenced at the 'err' path. In case of error reset NULL t_task_cdb value to point at the default fixed-size buffer. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9e95fb805dc0 ("scsi: target: Fix NULL pointer dereference") Cc: stable(a)vger.kernel.org Signed-off-by: Andrey Vatoropin <a.vatoropin(a)crpt.ru> --- drivers/target/target_core_transport.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 0a76bdfe5528..88544c911949 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -1524,6 +1524,7 @@ target_cmd_init_cdb(struct se_cmd *cmd, unsigned char *cdb, gfp_t gfp) if (scsi_command_size(cdb) > sizeof(cmd->__t_task_cdb)) { cmd->t_task_cdb = kzalloc(scsi_command_size(cdb), gfp); if (!cmd->t_task_cdb) { + cmd->t_task_cdb = &cmd->__t_task_cdb[0]; pr_err("Unable to allocate cmd->t_task_cdb" " %u > sizeof(cmd->__t_task_cdb): %lu ops\n", scsi_command_size(cdb), -- 2.43.0

2 days, 10 hours

2
1
0 0

[PATCH v2] rust: list: Add unsafe for container_of

by Philipp Stanner

impl_list_item_mod.rs calls container_of() without unsafe blocks at a couple of places. Since container_of() is an unsafe macro / function, the blocks are strictly necessary. For unknown reasons, that problem was so far not visible and only gets visible once one utilizes the list implementation from within the core crate: error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub` is unsafe and requires unsafe block --> rust/kernel/lib.rs:252:29 | 252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation | note: an unsafe function restricts its caller, but its body is safe by default --> rust/kernel/list/impl_list_item_mod.rs:216:13 | 216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation = note: requested on the command line with `-D unsafe-op-in-unsafe-fn` = note: this error originates in the macro `$crate::container_of` which comes from the expansion of the macro `impl_list_item` Add unsafe blocks to container_of to fix the issue. Cc: stable(a)vger.kernel.org # v6.17+ Fixes: c77f85b347dd ("rust: list: remove OFFSET constants") Suggested-by: Alice Ryhl <aliceryhl(a)google.com> Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- Changes in v2: - Add unsafes to the list implementation instead of container_of itself. (Alice, Miguel) - Adjust commit message and Fixes: tag. - Add stable-kernel for completeness. --- rust/kernel/list/impl_list_item_mod.rs | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/rust/kernel/list/impl_list_item_mod.rs b/rust/kernel/list/impl_list_item_mod.rs index 202bc6f97c13..7052095efde5 100644 --- a/rust/kernel/list/impl_list_item_mod.rs +++ b/rust/kernel/list/impl_list_item_mod.rs @@ -217,7 +217,7 @@ unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self { // SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it // points at the field `$field` in a value of type `Self`. Thus, reversing that // operation is still in-bounds of the allocation. - $crate::container_of!(me, Self, $($field).*) + unsafe { $crate::container_of!(me, Self, $($field).*) } } // GUARANTEES: @@ -242,7 +242,7 @@ unsafe fn post_remove(me: *mut $crate::list::ListLinks<$num>) -> *const Self { // SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it // points at the field `$field` in a value of type `Self`. Thus, reversing that // operation is still in-bounds of the allocation. - $crate::container_of!(me, Self, $($field).*) + unsafe { $crate::container_of!(me, Self, $($field).*) } } } )*}; @@ -270,9 +270,9 @@ unsafe fn prepare_to_insert(me: *const Self) -> *mut $crate::list::ListLinks<$nu // SAFETY: The caller promises that `me` points at a valid value of type `Self`. let links_field = unsafe { <Self as $crate::list::ListItem<$num>>::view_links(me) }; - let container = $crate::container_of!( + let container = unsafe { $crate::container_of!( links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner - ); + ) }; // SAFETY: By the same reasoning above, `links_field` is a valid pointer. let self_ptr = unsafe { @@ -319,9 +319,9 @@ unsafe fn view_links(me: *const Self) -> *mut $crate::list::ListLinks<$num> { // `ListArc` containing `Self` until the next call to `post_remove`. The value cannot // be destroyed while a `ListArc` reference exists. unsafe fn view_value(links_field: *mut $crate::list::ListLinks<$num>) -> *const Self { - let container = $crate::container_of!( + let container = unsafe { $crate::container_of!( links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner - ); + ) }; // SAFETY: By the same reasoning above, `links_field` is a valid pointer. let self_ptr = unsafe { -- 2.49.0

2 days, 13 hours

3
5
0 0

[PATCH] libfs: Fix NULL pointer access in simple_recursive_removal

by rom.wang

From: Yufeng Wang <wangyufeng(a)kylinos.cn> There is an issue in the kernel: if inode is NULL pointer. the function "inode_lock_nested" (or function "inode_lock" before) a crash will happen at code "&inode->i_rwsem". [292618.520532] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 [...] [292618.560398] RIP: 0010:down_write+0x12/0x30 [292618.565580] Code: 83 f8 01 74 08 48 c7 47 20 01 00 00 00 f3 c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 ba 01 00 00 00 ff ff ff ff 48 89 f8 <f0> 48 0f c1 10 85 d2 74 05 e8 00 43 ff ff 65 48 8b 04 25 80 5c 01 [292618.587219] RSP: 0018:ffffb898dc86fc20 EFLAGS: 00010246 [292618.593666] RAX: 00000000000000a0 RBX: ffff94c84f363950 RCX: ffffff8000000000 [292618.602255] RDX: ffffffff00000001 RSI: 0000000000000063 RDI: 00000000000000a0 [292618.610844] RBP: ffffb898dc86fc78 R08: 0000000000000000 R09: 0000000000000000 [292618.619434] R10: ffffb898dc86fca8 R11: 0000000000000000 R12: 0000000000000000 [292618.628022] R13: ffff94c84f362a20 R14: ffff954d3f2fb4a0 R15: ffff954c3afa5010 [292618.636612] FS: 0000555555989cc0(0000) GS:ffff956dbf900000(0000) knlGS:0000000000000000 [292618.646271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [292618.653300] CR2: 00000000000000a0 CR3: 000000fc7f25a000 CR4: 00000000003406e0 [292618.661888] Call Trace: [292618.665225] simple_recursive_removal+0x4f/0x230 [292618.670994] ? debug_fill_super+0xe0/0xe0 [292618.676079] debugfs_remove+0x40/0x60 [292618.680799] kvm_vcpu_release+0x19/0x30 [kvm] Fixes: a3d1e7eb5abe ("simple_recursive_removal(): kernel-side rm -rf for ramfs-style filesystems") Cc: stable(a)vger.kernel.org Signed-off-by: Yufeng Wang <wangyufeng(a)kylinos.cn> --- fs/libfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/libfs.c b/fs/libfs.c index 1661dcb7d983..9090cd1f97c4 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -611,6 +611,8 @@ static void __simple_recursive_removal(struct dentry *dentry, struct dentry *victim = NULL, *child; struct inode *inode = this->d_inode; + if (!inode) + return; inode_lock_nested(inode, I_MUTEX_CHILD); if (d_is_dir(this)) inode->i_flags |= S_DEAD; -- 2.34.1

2 days, 13 hours

3
2
0 0

[PATCH v2] gendwarfksyms: Skip files with no exports

by Miguel Ojeda

From: Sami Tolvanen <samitolvanen(a)google.com> Starting with Rust 1.91.0 (released 2025-10-30), in upstream commit ab91a63d403b ("Ignore intrinsic calls in cross-crate-inlining cost model") [1][2], `bindings.o` stops containing DWARF debug information because the `Default` implementations contained `write_bytes()` calls which are now ignored in that cost model (note that `CLIPPY=1` does not reproduce it). This means `gendwarfksyms` complains: RUSTC L rust/bindings.o error: gendwarfksyms: process_module: dwarf_get_units failed: no debugging information? There are several alternatives that would work here: conditionally skipping in the cases needed (but that is subtle and brittle), forcing DWARF generation with e.g. a dummy `static` (ugly and we may need to do it in several crates), skipping the call to the tool in the Kbuild command when there are no exports (fine) or teaching the tool to do so itself (simple and clean). Thus do the last one: don't attempt to process files if we have no symbol versions to calculate. [ I used the commit log of my patch linked below since it explained the root issue and expanded it a bit more to summarize the alternatives. - Miguel ] Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Haiyue Wang <haiyuewa(a)163.com> Closes: https://lore.kernel.org/rust-for-linux/b8c1c73d-bf8b-4bf2-beb1-84ffdcd60547… Suggested-by: Miguel Ojeda <ojeda(a)kernel.org> Link: https://lore.kernel.org/rust-for-linux/CANiq72nKC5r24VHAp9oUPR1HVPqT+=0ab9N… Link: https://github.com/rust-lang/rust/commit/ab91a63d403b0105cacd72809cd292a729… [1] Link: https://github.com/rust-lang/rust/pull/145910 [2] Signed-off-by: Sami Tolvanen <samitolvanen(a)google.com> Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- scripts/gendwarfksyms/gendwarfksyms.c | 3 ++- scripts/gendwarfksyms/gendwarfksyms.h | 2 +- scripts/gendwarfksyms/symbols.c | 4 +++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/scripts/gendwarfksyms/gendwarfksyms.c b/scripts/gendwarfksyms/gendwarfksyms.c index 08ae61eb327e..f5203d1640ee 100644 --- a/scripts/gendwarfksyms/gendwarfksyms.c +++ b/scripts/gendwarfksyms/gendwarfksyms.c @@ -138,7 +138,8 @@ int main(int argc, char **argv) error("no input files?"); } - symbol_read_exports(stdin); + if (!symbol_read_exports(stdin)) + return 0; if (symtypes_file) { symfile = fopen(symtypes_file, "w"); diff --git a/scripts/gendwarfksyms/gendwarfksyms.h b/scripts/gendwarfksyms/gendwarfksyms.h index d9c06d2cb1df..32cec8f7695a 100644 --- a/scripts/gendwarfksyms/gendwarfksyms.h +++ b/scripts/gendwarfksyms/gendwarfksyms.h @@ -123,7 +123,7 @@ struct symbol { typedef void (*symbol_callback_t)(struct symbol *, void *arg); bool is_symbol_ptr(const char *name); -void symbol_read_exports(FILE *file); +int symbol_read_exports(FILE *file); void symbol_read_symtab(int fd); struct symbol *symbol_get(const char *name); void symbol_set_ptr(struct symbol *sym, Dwarf_Die *ptr); diff --git a/scripts/gendwarfksyms/symbols.c b/scripts/gendwarfksyms/symbols.c index 35ed594f0749..ecddcb5ffcdf 100644 --- a/scripts/gendwarfksyms/symbols.c +++ b/scripts/gendwarfksyms/symbols.c @@ -128,7 +128,7 @@ static bool is_exported(const char *name) return for_each(name, NULL, NULL) > 0; } -void symbol_read_exports(FILE *file) +int symbol_read_exports(FILE *file) { struct symbol *sym; char *line = NULL; @@ -159,6 +159,8 @@ void symbol_read_exports(FILE *file) free(line); debug("%d exported symbols", nsym); + + return nsym; } static void get_symbol(struct symbol *sym, void *arg) base-commit: e9a6fb0bcdd7609be6969112f3fbfcce3b1d4a7c -- 2.51.2

2 days, 14 hours

7
14
0 0

[PATCH] arm64: dts: imx95: correct I3C2 pclk to IMX95_CLK_BUSWAKEUP

by Carlos Song

I3C2 is in WAKEUP domain. Its pclk should be IMX95_CLK_BUSWAKEUP. Fixes: 969497ebefcf ("arm64: dts: imx95: Add i3c1 and i3c2") Signed-off-by: Carlos Song <carlos.song(a)nxp.com> Cc: <stable(a)vger.kernel.org> --- arch/arm64/boot/dts/freescale/imx95.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi index e45014d50abe..a4d854817559 100644 --- a/arch/arm64/boot/dts/freescale/imx95.dtsi +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi @@ -828,7 +828,7 @@ i3c2: i3c@42520000 { interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>; #address-cells = <3>; #size-cells = <0>; - clocks = <&scmi_clk IMX95_CLK_BUSAON>, + clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>, <&scmi_clk IMX95_CLK_I3C2SLOW>; clock-names = "pclk", "fast_clk"; status = "disabled"; -- 2.34.1

2 days, 14 hours

2
1
0 0

Need LDI 2025 Business Contacts

by Juanita Garcia

Hi, We’re offering verified business contact data for the upcoming Live Design International Show 2025, tailored for effective outreach before and after the event. Place: Vegas, USA Date:Dec 03 - 09, 2025 Contact Overview: 14,851 Attendees 316 Exhibiting Companies 948 Verified Exhibitor Contacts 15,799 Total Business Contacts Each entry includes: Name, Job Title, Company, Website, Address, Phone, Official Email, LinkedIn Profile, and more. Note: We provide full data-protection compliance at a low cost. A limited-time 20% reduction is currently available. If you'd like more details, just reply: “Send me pricing” Best regards, Juanita Garcia Sr. Marketing Manager To opt out reply “Not Interested.”

2 days, 14 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror