【OLK-5.10】ARM/mm/fault: Call do_bad_area() when addr >= TASK_SIZE

问题描述：在arm32架构下，打开一个路径长度在4093-4095的文件，概率性触发内核打印栈和错误信息。

技术根因：
1. 对文件打开流程会走 link_path_walk->hash_name 解析文件名，其内部会根据传入的文件名转换成一个地址，调用 load_unaligned_zeropad 函数

2. load_unaligned_zeropad 函数每次会根据传入的地址读取一个字，如果当前地址加上一个字的偏移，正好跨越了 PAGE，可能触发内核缺页异常，进入 do_page_fault 流程。

3. do_page_fault->mmap_read_trylock 会判断这部分内存地址，如果拿到锁，在 5.10 内核代码中就会调用 might_sleep；而当前访问文件路径是在 RCU 流程中的，因此就触发了内核告警。

4. 主线代码对 do_page_fault 进行了有关重构，在 lock_mm_and_find_vma->get_mmap_lock_carefully 函数中还是会调用 mmap_read_trylock，如果能拿到锁就不会调用 might_sleep，但依然存在拿不到锁的情况。如果拿不到，就走 mmap_read_lock_killable->down_read_killable->might_sleep，一样会有这个告警。

5. do_page_fault 代码流程中，首先判断的 mmap_read_trylock。如果 trylock 成功，虽然走了 might_sleep 但并不会实际sleep，因为当前是一个内核的 pagefault，会走”no_context”分支，进入 __do_kernel_fault，内部调用 fixup_exception 就返回了。如果 trylock 失败，会调用 mmap_read_lock 等锁，引起 RCU 路径下等锁的问题。

6. x86 架构下 handle_page_fault 会判断，如果是内核地址就会走 fixup 流程，不会有might_sleep，arm 还是需要先拿锁再判断 vma，找不到才会放锁并走 fixup 流程。

修复方案：对于超过 TASK_SIZE 的地址，找 vma 是没有意义的，因此在其之前调用 do_bad_area 进行处理，避免 RCU 语义失效问题。
**二、缺陷分析结构反馈**
影响性分析说明：

缺陷严重等级:(Critical/High/Moderate/Low)

缺陷根因说明:

受影响版本排查(受影响/不受影响):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1
openEuler-24.03-LTS-SP2

修复是否涉及abi变化(是/否):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1
openEuler-24.03-LTS-SP2

GVP openEuler/kernel
关闭

内容风险标识

评论 (2)

GVPopenEuler/kernel关闭

内容风险标识