staticint kdamond_pid __read_mostly = -1;
module_param(kdamond_pid, int, 0400);

// 修复前：goto alloc_new 在 ks/orig_size 初始化之前
if (unlikely(flags & __GFP_THISNODE) && nid != NUMA_NO_NODE &&
             nid != page_to_nid(virt_to_page(p)))
goto alloc_new;

// 修复后：移到 ks/orig_size 初始化之后
if (is_kfence_address(p)) {
    ks = orig_size = kfence_ksize(p);
} else {
// ... ks, orig_size 初始化
}
// 然后才检查 NUMA 节点
if (unlikely(flags & __GFP_THISNODE) && ...)
goto alloc_new;

while (1) {
void *p = kmalloc(128, GFP_KERNEL);
    p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);
    kfree(p);
}

KFENCE 报告显示越界写入位于 kfence 分配对象右侧 120 字节处（"Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47)"），对象大小为 64 字节的 kmalloc-64 slab。补丁标记了 Cc: <stable@vger.kernel.org> 和 Fixes: 2cd8231796b5，需要回合到稳定分支。修改量仅 12 行增加、12 行删除，定向精确。

4. 锁竞争释放 tracepoint 通用插桩

系列：[PATCH v5 0/7] locking: contended_release tracepoint instrumentation作者： Dmitry Ilvokhin版本： v5（7个patch）

背景

Linux 内核的锁竞争（lock contention）分析一直依赖 contention_begin 和 contention_end 两个 tracepoint，它们在等待者（waiter）一侧触发。虽然通过 perf lock contention --lock-owner 可以在 contention_begin 时捕获持有者（holder）的身份和调用栈，但这反映的是"等待者到达时持有者的状态"，而非锁真正被释放时的状态。如果持有者在等待者到达后还做了大量工作，那么实际的释放路径和持有时间都无法被准确追踪。此外，由于缺少持有者侧的释放事件，也无法直接测量锁在竞争状态下的持有时间（hold time under contention）。Matthew Wilcox 曾建议应当"try to come up with generic instrumentation, instead of instrumenting each special lock manually"，推动了该系列向通用化方向演进。

解决的问题

1. 缺乏持有者视角的释放追踪：现有 tracepoint 只在 waiter 侧触发，无法获取 holder 在释放锁时的调用栈（release stack），而该调用栈可能与 waiter 到达时截然不同。
2. 无法测量竞争态持有时间：缺少 holder 侧的释放事件，导致无法计算从获取到释放之间的精确持有时长。
3. 覆盖范围不全：锁类型繁多（mutex、rtmutex、semaphore、rwsem、percpu-rwsem、qspinlock、qrwlock 及 RT 特化锁），需要在各类锁的释放路径中统一插桩。

如何做

整个方案以一个新的 trace event contended_release 为核心，在 include/trace/events/lock.h 中定义。该事件仅记录锁地址（lock_addr），精简高效：

TRACE_EVENT(contended_release,
    TP_PROTO(void *lock),
    TP_ARGS(lock),
    TP_STRUCT__entry(__field(void *, lock_addr)),
    TP_fast_assign(__entry->lock_addr = lock;),
    TP_printk("%p", __entry->lock_addr)
);

方案的实现分为三个层次：

第一层：准备与清理（Patch 1-2）。Patch 1 移除 lock.h 中不必要的 #include <linux/sched.h>。Patch 2 将 percpu_up_read() 的慢路径从内联函数中提取为独立的 __percpu_up_read()，避免在内联函数中添加 tracepoint 导致二进制膨胀。

第二层：可睡眠锁的插桩（Patch 3）。在 mutex（__mutex_unlock_slowpath()）、rtmutex（rt_mutex_slowunlock()）、semaphore（up()）、rwsem（__up_read()/__up_write()/__downgrade_write()）、percpu-rwsem 等的释放路径中添加 trace_contended_release() 调用。关键设计原则：tracepoint 尽可能在锁释放之前、唤醒等待者之前触发，以保证调用栈的准确性。每个插入点都有对应的等待者检查条件。

第三层：自旋锁的插桩（Patch 4-7）。自旋锁的解锁路径（queued_spin_unlock）通常是内联的、性能极其敏感的热路径。方案采用分层重构：Patch 4 引入 queued_spin_release() 作为架构可覆盖（arch-overridable）的解锁原语。Patch 5 在 queued_spin_unlock() 中利用 tracepoint_enabled(contended_release) 静态分支判断是否启用追踪。当禁用时，热路径仅多一条 NOP 指令；当启用时，调用 out-of-line 的 queued_spin_release_traced() 函数。Patch 6-7 对 qrwlock 采用完全相同的策略。

收益

1. 填补观测性空白：首次为锁的持有者释放路径提供通用 tracepoint，使得 perf、BPF 等工具可以追踪任意锁的释放行为和调用栈。
2. 竞争态持有时间测量：通过将 contention_end（获取）与 contended_release（释放）进行关联，实现精确的持有时间估算。
3. 极低的运行时开销：x86_64 defconfig（uninlined unlock）下，二进制增加仅 +680 bytes（+0.00%）；即使在最坏的 inlined unlock 场景下也仅为 +83659 bytes（+0.21%）。
4. 全面覆盖：涵盖 mutex、rtmutex、semaphore、rwsem、percpu-rwsem、qspinlock、qrwlock 以及 RT 特化锁共 8 类锁原语。

5. KHO 支持 deferred struct page init

系列：[PATCH v8 0/2] kho: add support for deferred struct page init作者： Michal Clapinski（Google）、Evangelos Petrongonas（Amazon）；Co-developed-by Mike Rapoport（Microsoft）版本： v8（2个patch）

背景

KHO（Kexec HandOver）是 Linux 内核的实时更新机制，允许在 kexec 重启过程中将内存区域从旧内核传递给新内核，从而保留关键状态。KHO 使用 scratch memory 来存放传递所需的元数据，并在新内核启动后将 preserved pages 的元数据写入对应的 struct page 中。然而，当 CONFIG_DEFERRED_STRUCT_PAGE_INIT 开启时，高地址区域的 struct page 初始化会被推迟到启动后期的并行 kthread 中完成。这导致 KHO 在早期尝试访问尚未初始化的 struct page 会触发 page fault（"BUG: unable to handle page fault for address: ..."），而后期的 deferred init 又会覆盖 KHO 已写入的元数据（如 migratetype 设置）。因此，KHO 的 Kconfig 中此前直接声明了 depends on !DEFERRED_STRUCT_PAGE_INIT，两者完全不兼容。

解决的问题

1. KHO 无法与 deferred struct page init 共存：这两个重要特性之间存在硬性的 Kconfig 互斥依赖，严重限制了大内存系统上 KHO 的使用。大内存系统恰恰最需要 deferred init 来加速启动，也最可能需要 KHO 来实现零停机更新。
2. KHO preserved pages 的 struct page 可能未初始化：在 KHO 反序列化阶段，kho_preserved_memory_reserve() 需要写入 struct page 元数据，但目标页的 struct page 可能尚未初始化。
3. KHO scratch memory 的 migratetype 被覆盖：kho_release_scratch() 将 scratch 区域设为 MIGRATE_CMA，但后续 deferred_init_pages() 会将其覆盖为 MIGRATE_MOVABLE。

如何做

Patch 1：使 preserved pages 与 deferred init 兼容。 引入 kho_get_preserved_page() 函数，在 kho_preserved_memory_reserve() 调用 phys_to_page() 之前，确保目标范围内所有 struct page 已被初始化。当 CONFIG_DEFERRED_STRUCT_PAGE_INIT 开启时，通过 early_pfn_to_nid() 获取 NUMA 节点 ID，然后逐页调用 init_deferred_page(pfn, nid)——该函数对已初始化的页是 no-op。同时调用 memblock_reserve() 标记该区域为 noinit，确保 deferred init kthread 不会再重新初始化这些页。移除了 Kconfig 中的 depends on !DEFERRED_STRUCT_PAGE_INIT 限制。

Patch 2：修复 scratch area 的 deferred init。 删除旧的 kho_release_scratch() 函数，转而在 deferred init 的各个初始化路径中直接识别 KHO scratch 区域。引入 memblock_is_kho_scratch_memory() 查询函数，在三个关键初始化函数中嵌入处理逻辑：

• memmap_init_range()：在 pageblock 对齐判断中，KHO scratch region 的 migratetype 设为 MIGRATE_CMA
• deferred_init_memmap_chunk()：对 KHO scratch range 将 migratetype 改为 MIGRATE_CMA 并传递给 deferred_free_pages()
• memmap_init_reserved_range()：在 reserved 的 scratch 页上设置 MIGRATE_CMA

收益

1. 解除功能互斥：大内存服务器可以同时使用 deferred struct page init（加速启动）和 KHO（实时内核更新），这对 TB 级内存的高可用生产环境至关重要。
2. 正确性保证：通过在初始化路径中原地处理 KHO scratch 的 migratetype，从根本上避免了竞争条件。作者进行了全面测试：涵盖 core_initcall（early）和 module_init（late）的分配、kexec 传递和恢复，在 DEFERRED 开启/关闭两种配置下均通过。
3. 代码简化：删除了 kho_release_scratch() 和 memmap_init_kho_scratch_pages() 两个专用函数共约 35 行代码，将逻辑分散到已有的通用初始化路径中。

6. kvfree_rcu() 改进：struct rcu_ptr 与 nolock 变体

系列：[RFC PATCH v2 0/8] kvfree_rcu() improvements作者： Harry Yoo（Oracle）版本： RFC v2（8个patch）

背景

k[v]free_rcu() 是 Linux RCU 子系统的核心 API，用于在 grace period 之后批量释放对象，广泛应用于 slab 分配器、文件系统、网络等子系统。现有实现存在两个显著局限：其一，双参数形式 kfree_rcu(ptr, rhf) 要求对象中嵌入 struct rcu_head（16 字节，含 next 指针和 func 回调指针），但 k[v]free_rcu() 的回调永远是 kvfree()，因此 func 字段本质上是浪费的；其二，kfree_rcu() 在调用时需要获取 per-CPU 的 krcp->lock 自旋锁，这意味着在未知上下文（unknown context）中不能安全调用——例如 BPF 程序可能运行时 CPU 已经持有了 krcp->lock，导致死锁。

解决的问题

1. struct rcu_head 浪费 8 字节：在 64 位系统上，struct rcu_head 占 16 字节，但 k[v]free_rcu() 只需要一个 next 指针来链接对象，多出的 func 指针（8 字节）被浪费。
2. 缺少 unknown context 下的 kfree_rcu 变体：BPF 程序可能附着在任意内核函数上运行，此时无法确定是否可以安全地 spin on a lock。"even calling call_rcu() is not legal, forcing users to implement some sort of deferred freeing"。

如何做

方案分为两大部分共 8 个 patch。

Part 1：引入 struct rcu_ptr（Patch 1-2）。 在 include/linux/types.h 中定义新类型 struct rcu_ptr，在 CONFIG_KVFREE_RCU_BATCHED=y 时仅包含一个 next 指针（8 字节），在 =n 时退化为与 struct rcu_head 相同大小。kvfree_rcu_arg_2 宏通过 C11 的 _Generic 泛型选择机制同时接受 struct rcu_head * 和 struct rcu_ptr *，保持向后兼容。在内部实现上，kvfree_rcu_list() 不再从 head->func 读取对象起始地址，而是通过新的 object_start_addr() 辅助函数动态推算。Patch 2 将 fs/dcache.c 中的 struct external_name 从 struct rcu_head head 改为 struct rcu_ptr rcu，作为首个用户示例。

Part 2：引入 kfree_rcu_nolock()（Patch 3-8）。 Patch 4 引入 kfree_rcu_nolock(ptr, rf) 宏，通过 allow_spin = false 标识调用方无法安全自旋。内部实现采用多层降级策略：

1. 首先尝试 trylock：krc_this_cpu_lock() 在 allow_spin = false 时使用 raw_spin_trylock()。作者认为"in practice, it's not held most of the time"。
2. trylock 成功时：使用已缓存的 bnode 存储指针，工作调度通过 irq_work 延迟执行，避免直接调用可能会 spin 的 workqueue API。
3. trylock 失败时：将对象插入 per-CPU 的无锁链表 defer_head（struct llist_head），并触发非懒惰 irq_work（defer_free），在 IRQ work 上下文中重新调用 kvfree_call_rcu() 完成释放。

Patch 5 教会 rcu sheaf 层处理 !allow_spin 场景。Patch 7 实现 rcu sheaf 的延迟提交（deferred submission）：引入新的 per-CPU defer_call_rcu_head（struct llist_head），当 !allow_spin && irqs_disabled() 时，通过无锁链表和 IRQ work 在安全上下文中再调用 call_rcu()。

作者选择了方案 (b)——将 deferred call_rcu 逻辑限制在 slab 子系统内，而非实现通用的 call_rcu_nolock()，原因是通用方案"would need to flush deferred callbacks before rcu_barrier() to preserve its guarantee, increasing the cost of rcu_barrier() for all RCU users"。Patch 8 添加 kunit 测试，在 perf overflow handler（NMI/硬中断上下文）中验证 kfree_rcu_nolock() 的正确性。

收益

1. 每对象节省 8 字节：使用 struct rcu_ptr 后，每个仅通过 k[v]free_rcu() 释放的对象节省一个指针大小。以 dcache 的 external_name 为例，作者系统有 230k 个长文件名对象，潜在节省约 1.8 MB。对于 BPF map 等分配量极大的场景，节省更为可观。
2. 解锁 BPF 在 NMI/硬中断上下文的 RCU 释放能力：kfree_rcu_nolock() 使 BPF 程序可以在任意上下文中安全释放 RCU 保护的对象。
3. 局部化开销：deferred call_rcu 逻辑封装在 slab 内部，"only kvfree_rcu_barrier() pays the extra cost"，不影响其他 RCU 用户的 rcu_barrier() 性能。

总结

新机制 / 新接口

性能优化

Bug Fix