From: Thomas Gleixner <tglx@kernel.org>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Michael Jeanson <mjeanson@efficios.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
kasan-dev@googlegroups.com
Subject: Re: [patch V2 3/4] sched/mmcid: Drop per CPU CID immediately when switching to per task mode
Date: Tue, 10 Feb 2026 11:44:07 +0100 [thread overview]
Message-ID: <873438c1zc.ffs@tglx> (raw)
In-Reply-To: <aYrewLd7QNiPUJT1@shinmob>
On Tue, Feb 10 2026 at 07:33, Shinichiro Kawasaki wrote:
> On Feb 02, 2026 / 10:39, Thomas Gleixner wrote:
>> When a exiting task initiates the switch from per CPU back to per task
>> mode, it has already dropped its CID and marked itself inactive. But a
>> leftover from an earlier iteration of the rework then reassigns the per
>> CPU CID to the exiting task with the transition bit set.
>>
>> That's wrong as the task is already marked CID inactive, which means it is
>> inconsistent state. It's harmless because the CID is marked in transit and
>> therefore dropped back into the pool when the exiting task schedules out
>> either through preemption or the final schedule().
>>
>> Simply drop the per CPU CID when the exiting task triggered the transition.
>>
>> Fixes: fbd0e71dc370 ("sched/mmcid: Provide CID ownership mode fixup functions")
>> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
>> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>
> Hello all,
>
> While I evaluated v6.19 kernel, I observed a BUG KASAN. The KASAN is recreated
> in stable manner by running the test case zbd/013 of blktests [1] on some of my
> test systems. I bisected and found that this patch as the commit 007d84287c74
> triggered the KASAN. When I reverted this patch from v6.19 kernel, the KASAN
> disappeared. Of note is that the KASAN symptom slightly varies for each run. I
> observed KASAN slab-use-after-free [2], use-after-free [3] and slab-out-of-
> bounds [4]. All those KASANs happened "in sched_mm_cid_exit".
And none of them make any sense. The patch does:
- mm_cid_transit_to_task(current, this_cpu_ptr(mm->mm_cid.pcpu));
+ mm_drop_cid_on_cpu(mm, this_cpu_ptr(mm->mm_cid.pcpu));
Both access mm->mm_cid and mm->mm_cid.pcpu. mm is valid at that point as
this is way before the task disconnects from the mm.
The new code also accesses the CID bitmap which is at the end of
mm_struct. But the subsequent mm_cid_fixup_cpus_to_tasks(mm) touches all
of those too. So none of this makes any sense at all.
> [ 65.768341] [ T1296] BUG: KASAN: slab-use-after-free in sched_mm_cid_exit+0x298/0x500
Can you please decode these symbols (file/line) so that we actually see
which access is flagged by KASAN?
Also .config and compiler version would be helpful.
Keeping the splats below for the KASAN folks to digest.
Thanks,
tglx
> Actions for fix will be appreciated. If I can help by trying trial some patches
> on my test systems, please let me know.
>
> [1] https://github.com/linux-blktests/blktests
>
> [2] KASAN slab-use-after-free
>
> [ 64.540760] [ T1234] run blktests zbd/013 at 2026-02-10 11:06:48
> [ 64.638773] [ T1252] null_blk: disk nullb1 created
> [ 64.749061] [ T1252] null_blk: nullb2: using native zone append
> [ 64.764569] [ T1252] null_blk: disk nullb2 created
> [ 65.767294] [ T1296] ==================================================================
> [ 65.768341] [ T1296] BUG: KASAN: slab-use-after-free in sched_mm_cid_exit+0x298/0x500
> [ 65.769378] [ T1296] Write of size 8 at addr ffff888149792410 by task cryptsetup/1296
>
> [ 65.770700] [ T1296] CPU: 1 UID: 0 PID: 1296 Comm: cryptsetup Not tainted 6.19.0 #571 PREEMPT(voluntary)
> [ 65.770705] [ T1296] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> [ 65.770709] [ T1296] Call Trace:
> [ 65.770711] [ T1296] <TASK>
> [ 65.770713] [ T1296] dump_stack_lvl+0x6a/0x90
> [ 65.770718] [ T1296] ? sched_mm_cid_exit+0x298/0x500
> [ 65.770721] [ T1296] print_report+0x170/0x4f3
> [ 65.770725] [ T1296] ? __virt_addr_valid+0x22e/0x4e0
> [ 65.770729] [ T1296] ? sched_mm_cid_exit+0x298/0x500
> [ 65.770732] [ T1296] kasan_report+0xad/0x150
> [ 65.770737] [ T1296] ? sched_mm_cid_exit+0x298/0x500
> [ 65.770742] [ T1296] kasan_check_range+0x115/0x1f0
> [ 65.770745] [ T1296] sched_mm_cid_exit+0x298/0x500
> [ 65.770750] [ T1296] do_exit+0x25e/0x24c0
> [ 65.770755] [ T1296] ? __pfx_do_exit+0x10/0x10
> [ 65.770758] [ T1296] ? lockdep_hardirqs_on+0x88/0x130
> [ 65.770761] [ T1296] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 65.770764] [ T1296] ? do_syscall_64+0x1d7/0x540
> [ 65.770766] [ T1296] ? do_raw_spin_lock+0x124/0x260
> [ 65.770769] [ T1296] ? lock_acquire+0x180/0x300
> [ 65.770771] [ T1296] ? find_held_lock+0x2b/0x80
> [ 65.770775] [ T1296] __x64_sys_exit+0x3e/0x50
> [ 65.770780] [ T1296] x64_sys_call+0x14fe/0x1500
> [ 65.770784] [ T1296] do_syscall_64+0x95/0x540
> [ 65.770787] [ T1296] ? lockdep_hardirqs_on+0x88/0x130
> [ 65.770790] [ T1296] ? _raw_spin_unlock_irq+0x24/0x50
> [ 65.770792] [ T1296] ? _raw_spin_unlock_irq+0x34/0x50
> [ 65.770795] [ T1296] ? __x64_sys_rt_sigprocmask+0x23d/0x400
> [ 65.770798] [ T1296] ? __pfx___x64_sys_rt_sigprocmask+0x10/0x10
> [ 65.770800] [ T1296] ? rcu_nocb_unlock_irqrestore+0x87/0xb0
> [ 65.770804] [ T1296] ? rcu_do_batch+0x867/0xd90
> [ 65.770809] [ T1296] ? lockdep_hardirqs_on+0x88/0x130
> [ 65.770811] [ T1296] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 65.770813] [ T1296] ? do_syscall_64+0x1d7/0x540
> [ 65.770816] [ T1296] ? __pfx_sched_clock_cpu+0x10/0x10
> [ 65.770819] [ T1296] ? lock_is_held_type+0xd5/0x140
> [ 65.770824] [ T1296] ? irqtime_account_irq+0xe4/0x330
> [ 65.770827] [ T1296] ? lockdep_softirqs_on+0xc3/0x140
> [ 65.770829] [ T1296] ? __irq_exit_rcu+0x126/0x240
> [ 65.770832] [ T1296] ? handle_softirqs+0x6c5/0x790
> [ 65.770836] [ T1296] ? __pfx_handle_softirqs+0x10/0x10
> [ 65.770839] [ T1296] ? irqtime_account_irq+0x1a2/0x330
> [ 65.770842] [ T1296] ? lockdep_hardirqs_on_prepare+0xce/0x1b0
> [ 65.770844] [ T1296] ? irqentry_exit+0xe2/0x6a0
> [ 65.770848] [ T1296] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 65.770850] [ T1296] RIP: 0033:0x7f96978fef89
> [ 65.770854] [ T1296] Code: ff 31 c9 48 89 88 20 06 00 00 31 c0 87 07 83 e8 01 7f 19 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 31 ff b8 3c 00 00 00 0f 05 <eb> f5 89 95 74 ff ff ff e8 9a d0 ff ff 83 bd 74 ff ff ff 01 0f 85
> [ 65.770856] [ T1296] RSP: 002b:00007f9691de0d30 EFLAGS: 00000246 ORIG_RAX: 000000000000003c
> [ 65.770861] [ T1296] RAX: ffffffffffffffda RBX: 00007f9691de16c0 RCX: 00007f96978fef89
> [ 65.770863] [ T1296] RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000000000000000
> [ 65.770865] [ T1296] RBP: 00007f9691de0df0 R08: 0000000015fc5864 R09: 0000000000000000
> [ 65.770866] [ T1296] R10: 0000000000000008 R11: 0000000000000246 R12: 00007f9691de16c0
> [ 65.770867] [ T1296] R13: 00007fff8d18af10 R14: 00007f9691de1cdc R15: 00007fff8d18b017
> [ 65.770875] [ T1296] </TASK>
>
> [ 65.805902] [ T1296] Allocated by task 668:
> [ 65.806662] [ T1296] kasan_save_stack+0x2c/0x50
> [ 65.807400] [ T1296] kasan_save_track+0x10/0x30
> [ 65.808130] [ T1296] __kasan_slab_alloc+0x7a/0x90
> [ 65.808842] [ T1296] kmem_cache_alloc_noprof+0x238/0x7a0
> [ 65.809569] [ T1296] getname_flags.part.0+0x48/0x4d0
> [ 65.810280] [ T1296] do_sys_openat2+0xa8/0x180
> [ 65.810972] [ T1296] __x64_sys_openat+0x10a/0x200
> [ 65.811637] [ T1296] do_syscall_64+0x95/0x540
> [ 65.812267] [ T1296] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> [ 65.813538] [ T1296] Freed by task 668:
> [ 65.814189] [ T1296] kasan_save_stack+0x2c/0x50
> [ 65.814884] [ T1296] kasan_save_track+0x10/0x30
> [ 65.815545] [ T1296] kasan_save_free_info+0x37/0x70
> [ 65.816318] [ T1296] __kasan_slab_free+0x67/0x80
> [ 65.817002] [ T1296] kmem_cache_free+0x1ae/0x6d0
> [ 65.817700] [ T1296] audit_reset_context+0x3c7/0xeb0
> [ 65.818401] [ T1296] syscall_exit_work+0x17f/0x1b0
> [ 65.819124] [ T1296] do_syscall_64+0x2fe/0x540
> [ 65.819812] [ T1296] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> [ 65.821100] [ T1296] The buggy address belongs to the object at ffff888149792200
> which belongs to the cache names_cache of size 4096
> [ 65.822824] [ T1296] The buggy address is located 528 bytes inside of
> freed 4096-byte region [ffff888149792200, ffff888149793200)
>
> [ 65.825027] [ T1296] The buggy address belongs to the physical page:
> [ 65.825856] [ T1296] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x149790
> [ 65.826846] [ T1296] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> [ 65.827840] [ T1296] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
> [ 65.828768] [ T1296] page_type: f5(slab)
> [ 65.829405] [ T1296] raw: 0017ffffc0000040 ffff888100902b40 ffffea0005314600 dead000000000002
> [ 65.830402] [ T1296] raw: 0000000000000000 0000000000070007 00000000f5000000 0000000000000000
> [ 65.831493] [ T1296] head: 0017ffffc0000040 ffff888100902b40 ffffea0005314600 dead000000000002
> [ 65.832644] [ T1296] head: 0000000000000000 0000000000070007 00000000f5000000 0000000000000000
> [ 65.833723] [ T1296] head: 0017ffffc0000003 ffffea000525e401 00000000ffffffff 00000000ffffffff
> [ 65.834798] [ T1296] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> [ 65.835827] [ T1296] page dumped because: kasan: bad access detected
>
> [ 65.837253] [ T1296] Memory state around the buggy address:
> [ 65.838039] [ T1296] ffff888149792300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 65.838991] [ T1296] ffff888149792380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 65.839939] [ T1296] >ffff888149792400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 65.840894] [ T1296] ^
> [ 65.841569] [ T1296] ffff888149792480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 65.842554] [ T1296] ffff888149792500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 65.843504] [ T1296] ==================================================================
> [ 65.844500] [ T1296] Disabling lock debugging due to kernel taint
> [ 71.925834] [ T1650] device-mapper: zone: dm-0 using emulated zone append
> [ 72.474170] [ C1] hrtimer: interrupt took 1119829 ns
>
> [3] KASAN use-after-free
>
> [ 145.885127] [ T1246] run blktests zbd/013 at 2026-02-10 10:57:04
> [ 145.985394] [ T1264] null_blk: disk nullb1 created
> [ 146.091908] [ T1264] null_blk: nullb2: using native zone append
> [ 146.106425] [ T1264] null_blk: disk nullb2 created
> [ 147.822863] [ T1479] ==================================================================
> [ 147.823592] [ T1479] BUG: KASAN: use-after-free in sched_mm_cid_exit+0x298/0x500
> [ 147.824479] [ T1479] Write of size 8 at addr ffff8881185cb050 by task cryptsetup/1479
>
> [ 147.825468] [ T1479] CPU: 2 UID: 0 PID: 1479 Comm: cryptsetup Not tainted 6.19.0 #571 PREEMPT(voluntary)
> [ 147.825472] [ T1479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> [ 147.825476] [ T1479] Call Trace:
> [ 147.825478] [ T1479] <TASK>
> [ 147.825480] [ T1479] dump_stack_lvl+0x6a/0x90
> [ 147.825484] [ T1479] ? sched_mm_cid_exit+0x298/0x500
> [ 147.825487] [ T1479] print_report+0x170/0x4f3
> [ 147.825490] [ T1479] ? __virt_addr_valid+0x22e/0x4e0
> [ 147.825494] [ T1479] ? sched_mm_cid_exit+0x298/0x500
> [ 147.825496] [ T1479] kasan_report+0xad/0x150
> [ 147.825500] [ T1479] ? sched_mm_cid_exit+0x298/0x500
> [ 147.825504] [ T1479] kasan_check_range+0x115/0x1f0
> [ 147.825507] [ T1479] sched_mm_cid_exit+0x298/0x500
> [ 147.825510] [ T1479] do_exit+0x25e/0x24c0
> [ 147.825514] [ T1479] ? lockdep_hardirqs_on+0x88/0x130
> [ 147.825517] [ T1479] ? __pfx_do_exit+0x10/0x10
> [ 147.825520] [ T1479] ? irqtime_account_irq+0xe4/0x330
> [ 147.825524] [ T1479] __x64_sys_exit+0x3e/0x50
> [ 147.825526] [ T1479] x64_sys_call+0x14fe/0x1500
> [ 147.825529] [ T1479] do_syscall_64+0x95/0x540
> [ 147.825531] [ T1479] ? __pfx_handle_softirqs+0x10/0x10
> [ 147.825534] [ T1479] ? irqtime_account_irq+0x1a2/0x330
> [ 147.825536] [ T1479] ? lockdep_hardirqs_on_prepare+0xce/0x1b0
> [ 147.825539] [ T1479] ? irqentry_exit+0xe2/0x6a0
> [ 147.825542] [ T1479] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 147.825544] [ T1479] RIP: 0033:0x7f505e211f89
> [ 147.825547] [ T1479] Code: ff 31 c9 48 89 88 20 06 00 00 31 c0 87 07 83 e8 01 7f 19 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 31 ff b8 3c 00 00 00 0f 05 <eb> f5 89 95 74 ff ff ff e8 9a d0 ff ff 83 bd 74 ff ff ff 01 0f 85
> [ 147.825549] [ T1479] RSP: 002b:00007f50585fbd30 EFLAGS: 00000246 ORIG_RAX: 000000000000003c
> [ 147.825553] [ T1479] RAX: ffffffffffffffda RBX: 00007f50585fc6c0 RCX: 00007f505e211f89
> [ 147.825555] [ T1479] RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000000000000000
> [ 147.825556] [ T1479] RBP: 00007f50585fbdf0 R08: 00005566eb14ea20 R09: 00005566eb14ea38
> [ 147.825558] [ T1479] R10: 0000000000000008 R11: 0000000000000246 R12: 00007f50585fc6c0
> [ 147.825559] [ T1479] R13: 00007fff4289e220 R14: 00007f50585fccdc R15: 00007fff4289e327
> [ 147.825564] [ T1479] </TASK>
>
> [ 147.844213] [ T1479] The buggy address belongs to the physical page:
> [ 147.845137] [ T1479] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x10 pfn:0x1185cb
> [ 147.846323] [ T1479] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
> [ 147.847389] [ T1479] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
> [ 147.848662] [ T1479] raw: 0000000000000010 0000000000000000 00000000ffffffff 0000000000000000
> [ 147.849887] [ T1479] page dumped because: kasan: bad access detected
>
> [ 147.851495] [ T1479] Memory state around the buggy address:
> [ 147.852479] [ T1479] ffff8881185caf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 147.853600] [ T1479] ffff8881185caf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 147.854690] [ T1479] >ffff8881185cb000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 147.855852] [ T1479] ^
> [ 147.856798] [ T1479] ffff8881185cb080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 147.857855] [ T1479] ffff8881185cb100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 147.858857] [ T1479] ==================================================================
> [ 147.859888] [ T1479] Disabling lock debugging due to kernel taint
> [ 153.349607] [ T1982] device-mapper: zone: dm-0 using emulated zone append
> [ 153.715923] [ C3] hrtimer: interrupt took 475570 ns
> [ 282.408372] [ T3034] null_blk: disk nullb0 created
> [ 282.409360] [ T3034] null_blk: module loaded
>
> [4] KASAN slab-out-of-bounds
>
> Feb 09 15:14:28 testnode2 unknown: run blktests zbd/013 at 2026-02-09 15:14:28
> Feb 09 15:14:28 testnode2 kernel: null_blk: disk nullb1 created
> Feb 09 15:14:28 testnode2 kernel: null_blk: nullb2: using native zone append
> Feb 09 15:14:28 testnode2 kernel: null_blk: disk nullb2 created
> Feb 09 15:14:29 testnode2 kernel: ==================================================================
> Feb 09 15:14:29 testnode2 kernel: BUG: KASAN: slab-out-of-bounds in sched_mm_cid_exit+0x298/0x500
> Feb 09 15:14:29 testnode2 kernel: Write of size 8 at addr ffff8881580db050 by task cryptsetup/136938
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: CPU: 3 UID: 0 PID: 136938 Comm: cryptsetup Not tainted 6.19.0 #571 PREEMPT(voluntary)
> Feb 09 15:14:29 testnode2 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> Feb 09 15:14:29 testnode2 kernel: Call Trace:
> Feb 09 15:14:29 testnode2 kernel: <TASK>
> Feb 09 15:14:29 testnode2 kernel: dump_stack_lvl+0x6a/0x90
> Feb 09 15:14:29 testnode2 kernel: ? sched_mm_cid_exit+0x298/0x500
> Feb 09 15:14:29 testnode2 kernel: print_report+0x170/0x4f3
> Feb 09 15:14:29 testnode2 kernel: ? __virt_addr_valid+0x22e/0x4e0
> Feb 09 15:14:29 testnode2 kernel: ? sched_mm_cid_exit+0x298/0x500
> Feb 09 15:14:29 testnode2 kernel: kasan_report+0xad/0x150
> Feb 09 15:14:29 testnode2 kernel: ? sched_mm_cid_exit+0x298/0x500
> Feb 09 15:14:29 testnode2 kernel: kasan_check_range+0x115/0x1f0
> Feb 09 15:14:29 testnode2 kernel: sched_mm_cid_exit+0x298/0x500
> Feb 09 15:14:29 testnode2 kernel: do_exit+0x25e/0x24c0
> Feb 09 15:14:29 testnode2 kernel: ? __pfx_do_exit+0x10/0x10
> Feb 09 15:14:29 testnode2 kernel: ? rcu_is_watching+0x11/0xb0
> Feb 09 15:14:29 testnode2 kernel: __x64_sys_exit+0x3e/0x50
> Feb 09 15:14:29 testnode2 kernel: x64_sys_call+0x14fe/0x1500
> Feb 09 15:14:29 testnode2 kernel: do_syscall_64+0x95/0x540
> Feb 09 15:14:29 testnode2 kernel: ? sched_tick+0x330/0x960
> Feb 09 15:14:29 testnode2 kernel: ? rcu_is_watching+0x11/0xb0
> Feb 09 15:14:29 testnode2 kernel: ? trace_hardirqs_on_prepare+0xfd/0x130
> Feb 09 15:14:29 testnode2 kernel: ? do_syscall_64+0x1d7/0x540
> Feb 09 15:14:29 testnode2 kernel: ? do_futex+0x1bf/0x210
> Feb 09 15:14:29 testnode2 kernel: ? __pfx_do_futex+0x10/0x10
> Feb 09 15:14:29 testnode2 kernel: ? rcu_is_watching+0x11/0xb0
> Feb 09 15:14:29 testnode2 kernel: ? profile_tick+0x18/0x90
> Feb 09 15:14:29 testnode2 kernel: ? __x64_sys_futex+0x22f/0x4a0
> Feb 09 15:14:29 testnode2 kernel: ? __pfx_do_raw_spin_lock+0x10/0x10
> Feb 09 15:14:29 testnode2 kernel: ? lock_release+0x242/0x2f0
> Feb 09 15:14:29 testnode2 kernel: ? __pfx___x64_sys_futex+0x10/0x10
> Feb 09 15:14:29 testnode2 kernel: ? timerqueue_add+0x207/0x3c0
> Feb 09 15:14:29 testnode2 kernel: ? enqueue_hrtimer+0x1f0/0x290
> Feb 09 15:14:29 testnode2 kernel: ? sched_clock_cpu+0x65/0x5c0
> Feb 09 15:14:29 testnode2 kernel: ? rcu_is_watching+0x11/0xb0
> Feb 09 15:14:29 testnode2 kernel: ? trace_hardirqs_on_prepare+0xfd/0x130
> Feb 09 15:14:29 testnode2 kernel: ? do_syscall_64+0x1d7/0x540
> Feb 09 15:14:29 testnode2 kernel: ? lock_release+0x242/0x2f0
> Feb 09 15:14:29 testnode2 kernel: ? rcu_is_watching+0x11/0xb0
> Feb 09 15:14:29 testnode2 kernel: ? trace_hardirqs_on+0x14/0x140
> Feb 09 15:14:29 testnode2 kernel: ? kvm_sched_clock_read+0xd/0x20
> Feb 09 15:14:29 testnode2 kernel: ? sched_clock+0xc/0x30
> Feb 09 15:14:29 testnode2 kernel: ? sched_clock_cpu+0x65/0x5c0
> Feb 09 15:14:29 testnode2 kernel: ? irqtime_account_irq+0xe4/0x330
> Feb 09 15:14:29 testnode2 kernel: ? kvm_sched_clock_read+0xd/0x20
> Feb 09 15:14:29 testnode2 kernel: ? sched_clock+0xc/0x30
> Feb 09 15:14:29 testnode2 kernel: ? sched_clock_cpu+0x65/0x5c0
> Feb 09 15:14:29 testnode2 kernel: ? __pfx_sched_clock_cpu+0x10/0x10
> Feb 09 15:14:29 testnode2 kernel: ? flush_tlb_func+0xb5/0x760
> Feb 09 15:14:29 testnode2 kernel: ? irqtime_account_irq+0x1a2/0x330
> Feb 09 15:14:29 testnode2 kernel: ? rcu_is_watching+0x11/0xb0
> Feb 09 15:14:29 testnode2 kernel: ? trace_hardirqs_on_prepare+0xfd/0x130
> Feb 09 15:14:29 testnode2 kernel: ? irqentry_exit+0xe2/0x6a0
> Feb 09 15:14:29 testnode2 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
> Feb 09 15:14:29 testnode2 kernel: RIP: 0033:0x7fca4fbf5f89
> Feb 09 15:14:29 testnode2 kernel: Code: ff 31 c9 48 89 88 20 06 00 00 31 c0 87 07 83 e8 01 7f 19 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 31 ff b8 3c 00 00 00 0f 05 <eb> f5 89 95 74 ff ff ff e8 9a d0 ff ff 83 bd 74 ff ff ff 01 0f 85
> Feb 09 15:14:29 testnode2 kernel: RSP: 002b:00007fca497fad30 EFLAGS: 00000246 ORIG_RAX: 000000000000003c
> Feb 09 15:14:29 testnode2 kernel: RAX: ffffffffffffffda RBX: 00007fca497fb6c0 RCX: 00007fca4fbf5f89
> Feb 09 15:14:29 testnode2 kernel: RDX: 0000000000000000 RSI: 0000000000800000 RDI: 0000000000000000
> Feb 09 15:14:29 testnode2 kernel: RBP: 00007fca497fadf0 R08: 0000557abe711cb0 R09: 0000557abe711cc8
> Feb 09 15:14:29 testnode2 kernel: R10: 0000000000000008 R11: 0000000000000246 R12: 00007fca497fb6c0
> Feb 09 15:14:29 testnode2 kernel: R13: 00007ffc5119c9c0 R14: 00007fca497fbcdc R15: 00007ffc5119cac7
> Feb 09 15:14:29 testnode2 kernel: </TASK>
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: Allocated by task 136663:
> Feb 09 15:14:29 testnode2 kernel: kasan_save_stack+0x2c/0x50
> Feb 09 15:14:29 testnode2 kernel: kasan_save_track+0x10/0x30
> Feb 09 15:14:29 testnode2 kernel: __kasan_slab_alloc+0x7a/0x90
> Feb 09 15:14:29 testnode2 kernel: kmem_cache_alloc_noprof+0x238/0x7a0
> Feb 09 15:14:29 testnode2 kernel: mempool_alloc_noprof+0x150/0x250
> Feb 09 15:14:29 testnode2 kernel: bio_alloc_bioset+0x1d7/0x720
> Feb 09 15:14:29 testnode2 kernel: blkdev_direct_IO+0x3a7/0x1f40
> Feb 09 15:14:29 testnode2 kernel: blkdev_write_iter+0x52b/0xba0
> Feb 09 15:14:29 testnode2 kernel: aio_write+0x33a/0x7c0
> Feb 09 15:14:29 testnode2 kernel: io_submit_one+0xd97/0x1a00
> Feb 09 15:14:29 testnode2 kernel: __x64_sys_io_submit+0x15d/0x2b0
> Feb 09 15:14:29 testnode2 kernel: do_syscall_64+0x95/0x540
> Feb 09 15:14:29 testnode2 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: Freed by task 37:
> Feb 09 15:14:29 testnode2 kernel: kasan_save_stack+0x2c/0x50
> Feb 09 15:14:29 testnode2 kernel: kasan_save_track+0x10/0x30
> Feb 09 15:14:29 testnode2 kernel: kasan_save_free_info+0x37/0x70
> Feb 09 15:14:29 testnode2 kernel: __kasan_slab_free+0x67/0x80
> Feb 09 15:14:29 testnode2 kernel: slab_free_after_rcu_debug+0xf5/0x200
> Feb 09 15:14:29 testnode2 kernel: rcu_do_batch+0x37a/0xd90
> Feb 09 15:14:29 testnode2 kernel: rcu_core+0x6f1/0xad0
> Feb 09 15:14:29 testnode2 kernel: handle_softirqs+0x1ee/0x790
> Feb 09 15:14:29 testnode2 kernel: run_ksoftirqd+0x3b/0x60
> Feb 09 15:14:29 testnode2 kernel: smpboot_thread_fn+0x2fd/0x9a0
> Feb 09 15:14:29 testnode2 kernel: kthread+0x3af/0x770
> Feb 09 15:14:29 testnode2 kernel: ret_from_fork+0x55c/0x810
> Feb 09 15:14:29 testnode2 kernel: ret_from_fork_asm+0x1a/0x30
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: Last potentially related work creation:
> Feb 09 15:14:29 testnode2 kernel: kasan_save_stack+0x2c/0x50
> Feb 09 15:14:29 testnode2 kernel: kasan_record_aux_stack+0xac/0xc0
> Feb 09 15:14:29 testnode2 kernel: kmem_cache_free+0x4af/0x6d0
> Feb 09 15:14:29 testnode2 kernel: mempool_free+0xbe/0x110
> Feb 09 15:14:29 testnode2 kernel: blk_update_request+0x443/0x1190
> Feb 09 15:14:29 testnode2 kernel: scsi_end_request+0x70/0x7b0
> Feb 09 15:14:29 testnode2 kernel: scsi_io_completion+0xea/0x1440
> Feb 09 15:14:29 testnode2 kernel: blk_complete_reqs+0xa8/0x120
> Feb 09 15:14:29 testnode2 kernel: handle_softirqs+0x1ee/0x790
> Feb 09 15:14:29 testnode2 kernel: run_ksoftirqd+0x3b/0x60
> Feb 09 15:14:29 testnode2 kernel: smpboot_thread_fn+0x2fd/0x9a0
> Feb 09 15:14:29 testnode2 kernel: kthread+0x3af/0x770
> Feb 09 15:14:29 testnode2 kernel: ret_from_fork+0x55c/0x810
> Feb 09 15:14:29 testnode2 kernel: ret_from_fork_asm+0x1a/0x30
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: The buggy address belongs to the object at ffff8881580daf00
> which belongs to the cache bio-264 of size 264
> Feb 09 15:14:29 testnode2 kernel: The buggy address is located 72 bytes to the right of
> allocated 264-byte region [ffff8881580daf00, ffff8881580db008)
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: The buggy address belongs to the physical page:
> Feb 09 15:14:29 testnode2 kernel: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1580da
> Feb 09 15:14:29 testnode2 kernel: head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> Feb 09 15:14:29 testnode2 kernel: flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
> Feb 09 15:14:29 testnode2 kernel: page_type: f5(slab)
> Feb 09 15:14:29 testnode2 kernel: raw: 0017ffffc0000040 ffff88810536c500 dead000000000122 0000000000000000
> Feb 09 15:14:29 testnode2 kernel: raw: 0000000000000000 0000000000150015 00000000f5000000 0000000000000000
> Feb 09 15:14:29 testnode2 kernel: head: 0017ffffc0000040 ffff88810536c500 dead000000000122 0000000000000000
> Feb 09 15:14:29 testnode2 kernel: head: 0000000000000000 0000000000150015 00000000f5000000 0000000000000000
> Feb 09 15:14:29 testnode2 kernel: head: 0017ffffc0000001 ffffea0005603681 00000000ffffffff 00000000ffffffff
> Feb 09 15:14:29 testnode2 kernel: head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
> Feb 09 15:14:29 testnode2 kernel: page dumped because: kasan: bad access detected
> Feb 09 15:14:29 testnode2 kernel:
> Feb 09 15:14:29 testnode2 kernel: Memory state around the buggy address:
> Feb 09 15:14:29 testnode2 kernel: ffff8881580daf00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> Feb 09 15:14:29 testnode2 kernel: ffff8881580daf80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> Feb 09 15:14:29 testnode2 kernel: >ffff8881580db000: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> Feb 09 15:14:29 testnode2 kernel: ^
> Feb 09 15:14:29 testnode2 kernel: ffff8881580db080: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> Feb 09 15:14:29 testnode2 kernel: ffff8881580db100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> Feb 09 15:14:29 testnode2 kernel: ==================================================================
> Feb 09 15:14:34 testnode2 kernel: device-mapper: zone: dm-0 using emulated zone append
> Feb 09 15:16:09 testnode2 kernel: null_blk: disk nullb0 created
> Feb 09 15:16:09 testnode2 kernel: null_blk: module loaded
next prev parent reply other threads:[~2026-02-10 10:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 9:39 [patch V2 0/4] sched/mmcid: Cure mode transition woes Thomas Gleixner
2026-02-02 9:39 ` [patch V2 1/4] sched/mmcid: Prevent live lock on task to CPU mode transition Thomas Gleixner
2026-02-02 14:50 ` Mathieu Desnoyers
2026-02-04 13:27 ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02 9:39 ` [patch V2 2/4] sched/mmcid: Protect transition on weakly ordered systems Thomas Gleixner
2026-02-02 14:53 ` Mathieu Desnoyers
2026-02-04 13:27 ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02 9:39 ` [patch V2 3/4] sched/mmcid: Drop per CPU CID immediately when switching to per task mode Thomas Gleixner
2026-02-04 13:27 ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-10 7:33 ` [patch V2 3/4] " Shinichiro Kawasaki
2026-02-10 10:44 ` Thomas Gleixner [this message]
2026-02-10 11:51 ` Shinichiro Kawasaki
2026-02-10 13:03 ` Peter Zijlstra
2026-02-10 14:15 ` Shinichiro Kawasaki
2026-02-10 13:33 ` Thomas Gleixner
2026-02-10 14:55 ` Shinichiro Kawasaki
2026-02-10 16:20 ` [PATCH] sched/mmcid: Don't assume CID is CPU owned on mode switch Thomas Gleixner
2026-02-10 16:28 ` Mathieu Desnoyers
2026-02-11 10:33 ` Takashi Iwai
2026-02-11 21:00 ` Linus Torvalds
2026-02-02 9:39 ` [patch V2 4/4] sched/mmcid: Optimize transitional CIDs when scheduling out Thomas Gleixner
2026-02-02 14:56 ` Mathieu Desnoyers
2026-02-04 13:27 ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02 10:14 ` [patch V2 0/4] sched/mmcid: Cure mode transition woes Peter Zijlstra
2026-02-02 11:46 ` Mathieu Desnoyers
2026-02-02 12:54 ` Peter Zijlstra
2026-02-02 21:22 ` Mathieu Desnoyers
2026-02-04 10:53 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873438c1zc.ffs@tglx \
--to=tglx@kernel.org \
--cc=glider@google.com \
--cc=ihor.solodrai@linux.dev \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mjeanson@efficios.com \
--cc=peterz@infradead.org \
--cc=ryabinin.a.a@gmail.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=sshegde@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.