Linux内核手动修改PTE标志位后为何偶尔自动复原？

算力阿峰

2026-5-7

老兄，你遇到的这个PTE修改后莫名还原的问题确实挺棘手的，结合你的日志、代码片段和疑问，我来逐一拆解分析：

1. pte_modify 和 pte_set_flags：功能差异与严谨性对比

pte_modify绝对是更严谨的选择，和你现在用的pte_set_flags+两次set_pte的组合相比，它的优势在于：

架构兼容性：这是内核提供的跨架构标准接口，内部会通过pte_flags_modify处理不同CPU架构对PTE格式的约束，确保你修改的是合法的、允许软件调整的位，不会误碰硬件强制要求的保留位或关键位。
原子性与安全性：你现在连续调用两次set_pte，中间如果被中断或者其他CPU操作插入，可能会让PTE处于临时的非法状态（比如先设了present位但还没清掉自定义位）。而pte_modify可以把两次位操作合并成一次合法的PTE更新，避免中间状态的暴露，比如：
```
pte_t updated_pte = *pte;
updated_pte = pte_set_flags(updated_pte, _PAGE_PRESENT);
updated_pte = pte_clear_flags(updated_pte, _PAGE_MY_BIT);
pte_modify(pte, updated_pte);
```
这样一次pte_modify就完成了所有标志位的调整，更安全。

从你的日志来看，PTE在reset_the_pte执行后、do_user_addr_fault调用前被还原，这大概率和缺乏同步锁或抢占导致的并发修改有关：

你代码里的prefetchw(&current->mm->mmap_sem)只是预取信号量缓存，并没有实际获取锁。在reset_the_pte到do_user_addr_fault这段时间里，内核可能发生抢占（比如被高优先级进程打断），如果有其他线程/进程共享同一个mm_struct（比如同进程的线程），并且也在操作这个PTE，就会直接覆盖你的修改。
正确的做法是，修改PTE时必须持有mmap_sem的写锁，或者至少通过preempt_disable()禁止抢占，避免多CPU环境下的异步修改。比如在调用reset_the_pte前后加上锁：
```
down_write(&current->mm->mmap_sem);
reset_the_pte(current, address, __func__);
up_write(&current->mm->mmap_sem);
```
你还可以在reset_the_pte里加个printk，打印当前的CPU号和进程PID，看看是不是有其他进程/线程在修改这个PTE。

如果这个页面属于共享内存（比如POSIX shm、匿名共享映射），确实可能导致你的重置操作失效，原因主要有两个：

内核页面管理机制的干扰：共享内存的页面会被内核的页面回收、换入换出机制管理，当你把PTE的present位关掉后，内核可能会认为这个页面需要被换入，从而自动重新设置present位，同时可能会重置你自定义的_PAGE_MY_BIT——毕竟内核不知道你加了这个自定义位，相关的页表操作逻辑不会保留它。
多进程页表的独立修改：每个映射共享内存的进程都有自己的PTE项，指向同一个物理页。如果其他进程也在修改自身的PTE，内核的某些页表同步机制（比如COW、页表共享逻辑）可能会间接影响你当前进程的PTE状态。

除了上面的分析，还有几个点可以帮你快速定位问题：

在reset_the_pte修改完PTE后，立即调用flush_tlb_page(vma, address)刷新TLB（虽然你的问题是内存中的PTE被改，但保险起见，避免TLB缓存的旧值干扰后续操作）。
检查是否有其他内核模块或者你自己的其他代码也在hook页表操作（比如其他地方用了walk_page_range或者页表修改钩子），会不会和你的逻辑冲突。
可以用pte_val(*pte)直接打印修改前后的PTE原始值，确认你的位操作是否真的生效了——有时候可能是pte_flags的解析逻辑有问题，导致日志显示的flags不对，但实际PTE是对的（不过从你的日志看，PTE的原始值也变回去了，所以这个可能性不大）。

内容的提问来源于stack exchange，提问作者wxz