Uh oh!
There was an error while loading. Please reload this page.
ci: Reusable workflow for sync - #15
Merged
Shiraz Hashim (shashim-quic) merged 1 commit intoMay 28, 2025
Merged
Conversation
VISHAL KUMAR (quic-viskuma)force-pushed
the
qcom-next-staging
branch
6 times, most recently
from
May 27, 2025 17:41
16730f8 to
48397b3CompareReusable workflow for syncing kernel & kernel-topics workspace Kernel - It will be having only the checkout code with PR data Kernel topics - It needs to clone the kernel repo and automerge tool, Creates a merge.conf which will be containing git remotes of qcom-next and topic branch then it fetches the PR data and merge on top of integration branch. Signed-off-by: Vishal Kumar <viskuma@qti.qualcomm.com>
VISHAL KUMAR (quic-viskuma)force-pushed
the
qcom-next-staging
branch
from
May 28, 2025 04:44
48397b3 to
6924ecfCompareShiraz Hashim (shashim-quic)
merged commit May 28, 2025
a80388e
into
qualcomm-linux:qcom-next-stagingSalendarsingh Gaud (sgaud-quic) pushed a commit
that referenced
this pull request
Jul 21, 2025
The 'icc_bw_lock' mutex is introduced in commit af42269 ("interconnect: Fix locking for runpm vs reclaim") in order to decouple serialization of bw aggregation from codepaths that require memory allocation. However commit d30f83d ("interconnect: core: Add dynamic id allocation support") added a devm_kasprintf() call into a path protected by the 'icc_bw_lock' which causes the following lockdep warning on machines like the Lenovo ThinkPad X13s: ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3 #15 Not tainted ------------------------------------------------------ (udev-worker)/342 is trying to acquire lock: ffffb973f7ec4638 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_node_track_caller_noprof+0xa0/0x3e0 but task is already holding lock: ffffb973f7f7f0e8 (icc_bw_lock){+.+.}-{4:4}, at: icc_node_add+0x44/0x154 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (icc_bw_lock){+.+.}-{4:4}: icc_init+0x48/0x108 do_one_initcall+0x64/0x30c kernel_init_freeable+0x27c/0x500 kernel_init+0x20/0x1d8 ret_from_fork+0x10/0x20 -> #0 (fs_reclaim){+.+.}-{0:0}: __lock_acquire+0x136c/0x2114 lock_acquire+0x1c8/0x354 fs_reclaim_acquire+0x74/0xa8 __kmalloc_node_track_caller_noprof+0xa0/0x3e0 devm_kmalloc+0x54/0x124 devm_kvasprintf+0x74/0xd4 devm_kasprintf+0x58/0x80 icc_node_add+0xb4/0x154 qcom_osm_l3_probe+0x20c/0x314 [icc_osm_l3] platform_probe+0x68/0xd8 really_probe+0xc0/0x38c __driver_probe_device+0x7c/0x160 driver_probe_device+0x40/0x110 __driver_attach+0xfc/0x208 bus_for_each_dev+0x74/0xd0 driver_attach+0x24/0x30 bus_add_driver+0x110/0x234 driver_register+0x60/0x128 __platform_driver_register+0x24/0x30 osm_l3_driver_init+0x20/0x1000 [icc_osm_l3] do_one_initcall+0x64/0x30c do_init_module+0x58/0x23c load_module+0x1df8/0x1f70 init_module_from_file+0x88/0xc4 idempotent_init_module+0x188/0x280 __arm64_sys_finit_module+0x6c/0xd8 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x158 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(icc_bw_lock); lock(fs_reclaim); lock(icc_bw_lock); lock(fs_reclaim); *** DEADLOCK *** The icc_node_add() functions is not designed to fail, and as such it should not do any memory allocation. In order to avoid this, add a new helper function for the name generation to be called by drivers which are using the new dynamic id feature. Fixes: d30f83d ("interconnect: core: Add dynamic id allocation support") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://lore.kernel.org/r/20250625-icc-bw-lockdep-v3-1-2b8f8b8987c4@gmail.com Co-developed-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250627075854.26943-1-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
Salendarsingh Gaud (sgaud-quic) pushed a commit
that referenced
this pull request
Oct 23, 2025
syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode. Cc: stable@kernel.org Reported-and-tested-by: syzbot+038b7bf43423e132b308@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=038b7bf43423e132b308 Suggested-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Message-ID: <20250930112810.315095-1-kartikey406@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Salendarsingh Gaud (sgaud-quic) pushed a commit
that referenced
this pull request
Nov 26, 2025
The namespaces can access the controller's admin request_queue, and stale references on the namespaces may exist after tearing down the controller. Ensure the admin request_queue is active by moving the controller's 'put' to after all controller references have been released to ensure no one is can access the request_queue. This fixes a reported use-after-free bug: BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0 Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287 CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15 Tainted: [E]=UNSIGNED_MODULE Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025 Call Trace: <TASK> dump_stack_lvl+0x4f/0x60 print_report+0xc4/0x620 ? _raw_spin_lock_irqsave+0x70/0xb0 ? _raw_read_unlock_irqrestore+0x30/0x30 ? blk_queue_enter+0x41c/0x4a0 kasan_report+0xab/0xe0 ? blk_queue_enter+0x41c/0x4a0 blk_queue_enter+0x41c/0x4a0 ? __irq_work_queue_local+0x75/0x1d0 ? blk_queue_start_drain+0x70/0x70 ? irq_work_queue+0x18/0x20 ? vprintk_emit.part.0+0x1cc/0x350 ? wake_up_klogd_work_func+0x60/0x60 blk_mq_alloc_request+0x2b7/0x6b0 ? __blk_mq_alloc_requests+0x1060/0x1060 ? __switch_to+0x5b7/0x1060 nvme_submit_user_cmd+0xa9/0x330 nvme_user_cmd.isra.0+0x240/0x3f0 ? force_sigsegv+0xe0/0xe0 ? nvme_user_cmd64+0x400/0x400 ? vfs_fileattr_set+0x9b0/0x9b0 ? cgroup_update_frozen_flag+0x24/0x1c0 ? cgroup_leave_frozen+0x204/0x330 ? nvme_ioctl+0x7c/0x2c0 blkdev_ioctl+0x1a8/0x4d0 ? blkdev_common_ioctl+0x1930/0x1930 ? fdget+0x54/0x380 __x64_sys_ioctl+0x129/0x190 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f765f703b0b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003 R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60 </TASK> Reported-by: Casey Chen <cachen@purestorage.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
Salendarsingh Gaud (sgaud-quic) pushed a commit
that referenced
this pull request
Jan 20, 2026
The usage of BPF_TRAMP_F_ORIG_STACK in __arch_prepare_bpf_trampoline() is wrong, and it should be BPF_TRAMP_F_CALL_ORIG, which caused crash as Andreas reported: Insufficient stack space to handle exception! Task stack: [0xff20000000010000..0xff20000000014000] Overflow stack: [0xff600000ffdad070..0xff600000ffdae070] CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc5+ #15 PREEMPT(voluntary) Hardware name: riscv-virtio qemu/qemu, BIOS 2025.10 10/01/2025 epc : copy_from_kernel_nofault+0xa/0x198 ra : bpf_probe_read_kernel+0x20/0x60 epc : ffffffff802b732a ra : ffffffff801e6070 sp : ff2000000000ffe0 gp : ffffffff82262ed0 tp : 0000000000000000 t0 : ffffffff80022320 t1 : ffffffff801e6056 t2 : 0000000000000000 s0 : ff20000000010040 s1 : 0000000000000008 a0 : ff20000000010050 a1 : ff60000083b3d320 a2 : 0000000000000008 a3 : 0000000000000097 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000021 a7 : 0000000000000003 s2 : ff20000000010050 s3 : ff6000008459fc18 s4 : ff60000083b3d340 s5 : ff20000000010060 s6 : 0000000000000000 s7 : ff20000000013aa8 s8 : 0000000000000000 s9 : 0000000000008000 s10: 000000000058dcb0 s11: 000000000058dca7 t3 : 000000006925116d t4 : ff6000008090f026 t5 : 00007fff9b0cbaa8 t6 : 0000000000000016 status: 0000000200000120 badaddr: 0000000000000000 cause: 8000000000000005 Kernel panic - not syncing: Kernel stack overflow CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc5+ #15 PREEMPT(voluntary) Hardware name: riscv-virtio qemu/qemu, BIOS 2025.10 10/01/2025 Call Trace: [<ffffffff8001a1f8>] dump_backtrace+0x28/0x38 [<ffffffff80002502>] show_stack+0x3a/0x50 [<ffffffff800122be>] dump_stack_lvl+0x56/0x80 [<ffffffff80012300>] dump_stack+0x18/0x22 [<ffffffff80002abe>] vpanic+0xf6/0x328 [<ffffffff80002d2e>] panic+0x3e/0x40 [<ffffffff80019ef0>] handle_bad_stack+0x98/0xa0 [<ffffffff801e6070>] bpf_probe_read_kernel+0x20/0x60 Just fix it. Fixes: 47c9214 ("bpf: fix the usage of BPF_TRAMP_F_SKIP_FRAME") Link: https://lore.kernel.org/bpf/20251219142948.204312-1-dongml2@chinatelecom.cn Closes: https://lore.kernel.org/bpf/874ipnkfvt.fsf@igel.home/ Reported-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Salendarsingh Gaud (sgaud-quic) pushed a commit
that referenced
this pull request
Mar 3, 2026
Ihor Solodrai says: ==================== selftests/bpf: Fixes for userspace ASAN This series includes various fixes aiming to enable test_progs run with userspace address sanitizer on BPF CI. The first five patches add a simplified implementation of strscpy() to selftests/bpf and then replace strcpy/strncpy usages across the tests with it. See relevant discussions [1][2]. Patch #6 fixes the selftests/bpf/test_progs build with: SAN_CFLAGS="-fsanitize=address -fno-omit-frame-pointer" The subsequent patches fix bugs reported by the address sanitizer on attempt to run the tests. [1] https://lore.kernel.org/bpf/CAADnVQ+9uw2_o388j43EWiAPdMB=3FLx2jq-9zRSvqrv-wgRag@mail.gmail.com/ [2] https://lore.kernel.org/bpf/20260220182011.802116-1-ihor.solodrai@linux.dev/ --- v3->v4: - combine strscpy and ASAN series into one (Alexei) - make the count arg of strscpy() optional via macro and fixup relevant call sites (Alexei) - remove strscpy_cat() from this series (Alexei) v3: https://lore.kernel.org/bpf/20260220222604.1155148-1-ihor.solodrai@linux.dev/ v2->v3: - rebase on top of "selftests/bpf: Add and use strscpy()" - https://lore.kernel.org/bpf/20260220182011.802116-1-ihor.solodrai@linux.dev/ - uprobe_multi_test.c: memset static struct child at the beginning of a test *and* zero out child->thread in release_child (patch #9, Mykyta) - nits in test_sysctl.c (patch #11, Eduard) - bpftool_helpers.c: update to use strscpy (patch #14, Alexei) - add __asan_on_error handler to still dump test logs even with ASAN build (patch #15, Mykyta) v2: https://lore.kernel.org/bpf/20260218003041.1156774-1-ihor.solodrai@linux.dev/ v1->v2: - rebase on bpf (v1 was targeting bpf-next) - add ASAN flag handling in selftests/bpf/Makefile (Eduard) - don't override SIGSEGV handler in test_progs with ASAN (Eduard) - add error messages in detect_bpftool_path (Mykyta) - various nits (Eduard, Jiri, Mykyta, Alexis) v1: https://lore.kernel.org/bpf/20260212011356.3266753-1-ihor.solodrai@linux.dev/ ==================== Link: https://patch.msgid.link/20260223190736.649171-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
svankas (svankas) pushed a commit
to svankas/kernel
that referenced
this pull request
Mar 19, 2026
[ Upstream commit a70493e ] The ETM decoder incorrectly assumed that auxtrace queue indices were equivalent to CPU number. This assumption is used for inserting records into the queue, and for fetching queues when given a CPU number. This assumption held when Perf always opened a dummy event on every CPU, even if the user provided a subset of CPUs on the commandline, resulting in the indices aligning. For example: # event : name = cs_etm//u, , id = { 2451, 2452 }, type = 11 (cs_etm), size = 136, config = 0x4010, { sample_period, samp> # event : name = dummy:u, , id = { 2453, 2454, 2455, 2456 }, type = 1 (PERF_TYPE_SOFTWARE), size = 136, config = 0x9 (PER> 0 0 0x200 [0xd0]: PERF_RECORD_ID_INDEX nr: 6 ... id: 2451 idx: 2 cpu: 2 tid: -1 ... id: 2452 idx: 3 cpu: 3 tid: -1 ... id: 2453 idx: 0 cpu: 0 tid: -1 ... id: 2454 idx: 1 cpu: 1 tid: -1 ... id: 2455 idx: 2 cpu: 2 tid: -1 ... id: 2456 idx: 3 cpu: 3 tid: -1 Since commit 811082e ("perf parse-events: Support user CPUs mixed with threads/processes") the dummy event no longer behaves in this way, making the ETM event indices start from 0 on the first CPU recorded regardless of its ID: # event : name = cs_etm//u, , id = { 771, 772 }, type = 11 (cs_etm), size = 144, config = 0x4010, { sample_period, sample> # event : name = dummy:u, , id = { 773, 774 }, type = 1 (PERF_TYPE_SOFTWARE), size = 144, config = 0x9 (PERF_COUNT_SW_DUM> 0 0 0x200 [0x90]: PERF_RECORD_ID_INDEX nr: 4 ... id: 771 idx: 0 cpu: 2 tid: -1 ... id: 772 idx: 1 cpu: 3 tid: -1 ... id: 773 idx: 0 cpu: 2 tid: -1 ... id: 774 idx: 1 cpu: 3 tid: -1 This causes the following segfault when decoding: $ perf record -e cs_etm//u -C 2,3 -- true $ perf report perf: Segmentation fault -------- backtrace -------- #0 0xaaaabf9fd020 in ui__signal_backtrace setup.c:110 qualcomm-linux#1 0xffffab5c7930 in __kernel_rt_sigreturn [vdso][930] qualcomm-linux#2 0xaaaabfb68d30 in cs_etm_decoder__reset cs-etm-decoder.c:85 qualcomm-linux#3 0xaaaabfb65930 in cs_etm__get_data_block cs-etm.c:2032 qualcomm-linux#4 0xaaaabfb666fc in cs_etm__run_per_cpu_timeless_decoder cs-etm.c:2551 qualcomm-linux#5 0xaaaabfb6692c in (cs_etm__process_timeless_queues cs-etm.c:2612 qualcomm-linux#6 0xaaaabfb63390 in cs_etm__flush_events cs-etm.c:921 qualcomm-linux#7 0xaaaabfb324c0 in auxtrace__flush_events auxtrace.c:2915 qualcomm-linux#8 0xaaaabfaac378 in __perf_session__process_events session.c:2285 qualcomm-linux#9 0xaaaabfaacc9c in perf_session__process_events session.c:2442 qualcomm-linux#10 0xaaaabf8d3d90 in __cmd_report builtin-report.c:1085 qualcomm-linux#11 0xaaaabf8d6944 in cmd_report builtin-report.c:1866 qualcomm-linux#12 0xaaaabf95ebfc in run_builtin perf.c:351 qualcomm-linux#13 0xaaaabf95eeb0 in handle_internal_command perf.c:404 qualcomm-linux#14 0xaaaabf95f068 in run_argv perf.c:451 qualcomm-linux#15 0xaaaabf95f390 in main perf.c:558 qualcomm-linux#16 0xffffaab97400 in __libc_start_call_main libc_start_call_main.h:74 qualcomm-linux#17 0xffffaab974d8 in __libc_start_main@@GLIBC_2.34 libc-start.c:128 qualcomm-linux#18 0xaaaabf8aa8f0 in _start perf[7a8f0] Fix it by inserting into the queues based on CPU number, rather than using the index. Fixes: 811082e ("perf parse-events: Support user CPUs mixed with threads/processes") Signed-off-by: James Clark <james.clark@linaro.org> Tested-by: Leo Yan <leo.yan@arm.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: coresight@lists.linaro.org Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Garry <john.g.garry@oracle.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: Thomas Falcon <thomas.falcon@intel.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
sushrut-trivedi pushed a commit
to sushrut-trivedi/kernel-6.18
that referenced
this pull request
May 20, 2026
Currently, the initialization of loongarch_jump_ops does not contain an assignment to its .free field. This causes disasm_line__free() to fall through to ins_ops__delete() for LoongArch jump instructions. ins_ops__delete() will free ins_operands.source.raw and ins_operands.source.name, and these fields overlaps with ins_operands.jump.raw_comment and ins_operands.jump.raw_func_start. Since in loongarch_jump__parse(), these two fields are populated by strchr()-ing the same buffer, trying to free them will lead to undefined behavior. This invalid free usually leads to crashes: Process 1712902 (perf) of user 1000 dumped core. Stack trace of thread 1712902: #0 0x00007fffef155c58 n/a (libc.so.6 + 0x95c58) qualcomm-linux#1 0x00007fffef0f7a94 raise (libc.so.6 + 0x37a94) qualcomm-linux#2 0x00007fffef0dd6a8 abort (libc.so.6 + 0x1d6a8) qualcomm-linux#3 0x00007fffef145490 n/a (libc.so.6 + 0x85490) qualcomm-linux#4 0x00007fffef1646f4 n/a (libc.so.6 + 0xa46f4) qualcomm-linux#5 0x00007fffef164718 n/a (libc.so.6 + 0xa4718) qualcomm-linux#6 0x00005555583a6764 __zfree (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x106764) qualcomm-linux#7 0x000055555854fb70 disasm_line__free (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x2afb70) qualcomm-linux#8 0x000055555853d618 annotated_source__purge (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x29d618) qualcomm-linux#9 0x000055555852300c __hist_entry__tui_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28300c) qualcomm-linux#10 0x0000555558526718 do_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x286718) qualcomm-linux#11 0x000055555852ed94 evsel__hists_browse (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28ed94) qualcomm-linux#12 0x000055555831fdd0 cmd_report (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x7fdd0) qualcomm-linux#13 0x000055555839b644 handle_internal_command (/home/csmantle/dist/linux-arch/tools/perf/perf + 0xfb644) qualcomm-linux#14 0x00005555582fe6ac main (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5e6ac) qualcomm-linux#15 0x00007fffef0ddd90 n/a (libc.so.6 + 0x1dd90) qualcomm-linux#16 0x00007fffef0ddf0c __libc_start_main (libc.so.6 + 0x1df0c) qualcomm-linux#17 0x00005555582fed10 _start (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5ed10) ELF object binary architecture: LoongArch ... and it can be confirmed with Valgrind: ==1721834== Invalid free() / delete / delete[] / realloc() ==1721834== at 0x4EA9014: free (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x4106287: __zfree (zalloc.c:13) ==1721834== by 0x42ADC8F: disasm_line__free (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B737: annotated_source__purge (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42811EB: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== Address 0x7d34303 is 35 bytes inside a block of size 62 alloc'd ==1721834== at 0x4EA59B8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x6B80B6F: strdup (strdup.c:42) ==1721834== by 0x42AD917: disasm_line__new (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AE5A3: symbol__disassemble_objdump (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AF0A7: symbol__disassemble (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B3CF: symbol__annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429C233: symbol__annotate2 (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42804D3: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) This patch adds the missing free() specialization in loongarch_jump_ops, which prevents disasm_line__free() from invoking the default cleanup function. Fixes: fb7fd2a ("perf annotate: Move raw_comment and raw_func_start fields out of 'struct ins_operands'") Cc: stable@vger.kernel.org Cc: WANG Rui <wangrui@loongson.cn> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: loongarch@lists.linux.dev Signed-off-by: Rong Bao <rong.bao@csmantle.top> Tested-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Salendarsingh Gaud (sgaud-quic) pushed a commit
that referenced
this pull request
May 25, 2026
[ Upstream commit a355eef ] Currently, the initialization of loongarch_jump_ops does not contain an assignment to its .free field. This causes disasm_line__free() to fall through to ins_ops__delete() for LoongArch jump instructions. ins_ops__delete() will free ins_operands.source.raw and ins_operands.source.name, and these fields overlaps with ins_operands.jump.raw_comment and ins_operands.jump.raw_func_start. Since in loongarch_jump__parse(), these two fields are populated by strchr()-ing the same buffer, trying to free them will lead to undefined behavior. This invalid free usually leads to crashes: Process 1712902 (perf) of user 1000 dumped core. Stack trace of thread 1712902: #0 0x00007fffef155c58 n/a (libc.so.6 + 0x95c58) #1 0x00007fffef0f7a94 raise (libc.so.6 + 0x37a94) #2 0x00007fffef0dd6a8 abort (libc.so.6 + 0x1d6a8) #3 0x00007fffef145490 n/a (libc.so.6 + 0x85490) #4 0x00007fffef1646f4 n/a (libc.so.6 + 0xa46f4) #5 0x00007fffef164718 n/a (libc.so.6 + 0xa4718) #6 0x00005555583a6764 __zfree (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x106764) #7 0x000055555854fb70 disasm_line__free (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x2afb70) #8 0x000055555853d618 annotated_source__purge (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x29d618) #9 0x000055555852300c __hist_entry__tui_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28300c) #10 0x0000555558526718 do_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x286718) #11 0x000055555852ed94 evsel__hists_browse (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28ed94) #12 0x000055555831fdd0 cmd_report (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x7fdd0) #13 0x000055555839b644 handle_internal_command (/home/csmantle/dist/linux-arch/tools/perf/perf + 0xfb644) #14 0x00005555582fe6ac main (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5e6ac) #15 0x00007fffef0ddd90 n/a (libc.so.6 + 0x1dd90) #16 0x00007fffef0ddf0c __libc_start_main (libc.so.6 + 0x1df0c) #17 0x00005555582fed10 _start (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5ed10) ELF object binary architecture: LoongArch ... and it can be confirmed with Valgrind: ==1721834== Invalid free() / delete / delete[] / realloc() ==1721834== at 0x4EA9014: free (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x4106287: __zfree (zalloc.c:13) ==1721834== by 0x42ADC8F: disasm_line__free (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B737: annotated_source__purge (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42811EB: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== Address 0x7d34303 is 35 bytes inside a block of size 62 alloc'd ==1721834== at 0x4EA59B8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x6B80B6F: strdup (strdup.c:42) ==1721834== by 0x42AD917: disasm_line__new (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AE5A3: symbol__disassemble_objdump (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AF0A7: symbol__disassemble (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B3CF: symbol__annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429C233: symbol__annotate2 (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42804D3: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) This patch adds the missing free() specialization in loongarch_jump_ops, which prevents disasm_line__free() from invoking the default cleanup function. Fixes: fb7fd2a ("perf annotate: Move raw_comment and raw_func_start fields out of 'struct ins_operands'") Cc: stable@vger.kernel.org Cc: WANG Rui <wangrui@loongson.cn> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: loongarch@lists.linux.dev Signed-off-by: Rong Bao <rong.bao@csmantle.top> Tested-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Aditya Choudhury (inferno0230) pushed a commit
to inferno0230/qualcomm-mainline
that referenced
this pull request
Jul 15, 2026
commit 4e67f50 upstream. nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...) but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *. Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx call. This fixes the following oops: BUG: Unable to handle kernel data access at 0xc0403effffffffc8 Faulting instruction address: 0xc000000000396cb4 Oops: Kernel access of bad area, sig: 11 [qualcomm-linux#15] Call Trace: nx_crypto_ctx_shash_exit+0x24/0x60 crypto_shash_exit_tfm+0x28/0x40 crypto_destroy_tfm+0x98/0x140 crypto_exit_ahash_using_shash+0x20/0x40 crypto_destroy_tfm+0x98/0x140 hash_release+0x1c/0x30 alg_sock_destruct+0x38/0x60 __sk_destruct+0x48/0x2b0 af_alg_release+0x58/0xb0 __sock_release+0x68/0x150 sock_close+0x20/0x40 __fput+0x110/0x3a0 sys_close+0x48/0xa0 system_call_exception+0x140/0x2d0 system_call_common+0xf4/0x258 .. which came from hardlink(1) opportunistically using AF_ALG. The same problem exists with nx_crypto_ctx_skcipher_exit getting a context it wasn't expecting, but apparently nobody hit that for years. Cc: Eric Biggers <ebiggers@kernel.org> Cc: stable@vger.kernel.org Fixes: bfd9efd ("crypto: nx - convert AES-ECB to skcipher API") Fixes: 9420e62 ("crypto: nx - Use API partial block handling") Acked-by: Breno Leitao <leitao@debian.org> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Reported-by: Calvin Buckley <calvin@cmpct.info> Tested-by: Calvin Buckley <calvin@cmpct.info> Suggested-by: Brad Spengler <brad.spengler@opensrcsec.com> Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ximiali pushed a commit
to ximiali/kernel
that referenced
this pull request
Jul 23, 2026
nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...) but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *. Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx call. This fixes the following oops: BUG: Unable to handle kernel data access at 0xc0403effffffffc8 Faulting instruction address: 0xc000000000396cb4 Oops: Kernel access of bad area, sig: 11 [qualcomm-linux#15] Call Trace: nx_crypto_ctx_shash_exit+0x24/0x60 crypto_shash_exit_tfm+0x28/0x40 crypto_destroy_tfm+0x98/0x140 crypto_exit_ahash_using_shash+0x20/0x40 crypto_destroy_tfm+0x98/0x140 hash_release+0x1c/0x30 alg_sock_destruct+0x38/0x60 __sk_destruct+0x48/0x2b0 af_alg_release+0x58/0xb0 __sock_release+0x68/0x150 sock_close+0x20/0x40 __fput+0x110/0x3a0 sys_close+0x48/0xa0 system_call_exception+0x140/0x2d0 system_call_common+0xf4/0x258 .. which came from hardlink(1) opportunistically using AF_ALG. The same problem exists with nx_crypto_ctx_skcipher_exit getting a context it wasn't expecting, but apparently nobody hit that for years. Cc: Eric Biggers <ebiggers@kernel.org> Cc: stable@vger.kernel.org Fixes: bfd9efd ("crypto: nx - convert AES-ECB to skcipher API") Fixes: 9420e62 ("crypto: nx - Use API partial block handling") Acked-by: Breno Leitao <leitao@debian.org> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Reported-by: Calvin Buckley <calvin@cmpct.info> Tested-by: Calvin Buckley <calvin@cmpct.info> Suggested-by: Brad Spengler <brad.spengler@opensrcsec.com> Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reusable workflow for syncing kernel & kernel-topics workspace
Kernel - It will be having only the checkout code with PR data
Kernel topics - It needs to clone the kernel repo and automerge tool,
Creates a merge.conf which will be containing git remotes
of qcom-next and topic branch then it fetches the PR data and merge
on top of integration branch.