为什么mmap之后访问地址仍然发生了缺页异常？

问题简述

在笔者的开发平台上，应用程序使用ION申请cma内存，并用mmap映射到用户地址空间去做写操作。

重点代码摘要如下：

客户希望提高

node->var = some_value;

这里的访问效率（实际代码要复杂些，是申请了一个大数组并往里循环读写数据）。

第一轮分析

首先用perf分析应用程序行为，发现程序在运行时产生了不少page fault，感觉是mmap之后内核并没有建立映射，而是在第一次访问此地址时，产生fault in所致。

第一个想法

首先想到优化点是：用MAP_POPULATE强制在mmap系统调用里面把所有的页面都fault in，这样后面访问就不会产生page fault而耽误时间了。因为page fault不管是在前还是在后总会发生，这个优化思路其实只是让这段时间集中挪到了访问数据之前。但看了一下mmap的手册，说到MAP_POPULATE只能针对于MAP_PRIVATE映射（见mmap手册），比如用匿名页建立的映射，而此处因为是MAP_SHARED，无法用MAP_POPULATE,故此方案作罢。

第二个想法

用ftrace跟踪了一下ion代码，发现mmap已经调用了remap_pfn_range来建立页面映射，代码路径如下：

mmap => el0_sync => el0_sync_handler => el0_svc => do_el0_svc => el0_svc_common.constprop.4 => __arm64_sys_mmap => ksys_mmap_pgoff => vm_mmap_pgoff => do_mmap => mmap_region => dma_buf_mmap_internal => ion_dma_buf_mmap => ion_heap_map_user => remap_pfn_range

也就是说，从代码路径看，在mmap系统调用中，用户页已经全都建立好了，所谓的fault in其实并不存在。那么问题来了，既然不存在fault in,为什么还是会产生page fault呢？

转机

因为此问题是在换了内核到5.10之后暴露出来的，尝试在旧内核4.19上尝试同样的代码。

同样代码运行在4.19内核上，该写操作的效率明显高于5.10内核。对比由perf stat观测得出：

也就是说，4.19上面代码如预期运行，mmap时后就不再有page fault，但5.10上却发生了page fault。

问题就转变成了：为什么remap_pfn_range之后仍发生了page fault？

分析remap_pfn_range行为发现应该不是这里的问题，那么，或许这个page fault不是缺页异常，而是别的page fault？想到这一层后，继续对比4.19与5.10内核行为。

问题原因的要素分析

跳过冗长的debug过程，直接说5.10内核在笔者平台上造成此问题的根本原因，原因由这几个要素构成：

1 . mmap在使用ION的时候，需要用参数MAP_SHARED

• 此参数最终会传导至ARM64 arch层在设置相应页表时，采用PAGE_SHARED联合属性
• PAGE_SHARED联合属性，包含这样两个页表基本属性：PTE_RDONLY | PTE_DBM

2 . 根据ARMv8手册，PTE_RDONLY | PTE_DBM 两个属性叠加，根据另一个系统寄存器的不同配置，会有两种不同硬件处理的情况：二选一

• 系统寄存器TCR_EL1.HD=1产生的效果是：在第一次写操作访问该页面时，CPU会自动更新页面的RO属性为RW，并不产生permission fault
• 系统寄存器TCR_EL1.HD=0产生的效果是：在第一次写操作访问该页面时，CPU不会自动更新页面的RO属性为RW，而会产生一次permission fault，这个fault需要由操作系统去软件更新为RW，它的主要目的，是为了让操作系统跟踪页表第一次写访问。

3 . 在笔者的内核编译中，系统寄存器TCR_EL1.HD=0，也就是走的B路线。

• 之所以编译会让该位配置为0，是因为需要实施一个CPU erratum的软件规避 ：Cortex-A55: 1024718: Update of DBM/AP bits without break before make might result in incorrect update，表现为内核配置项CONFIG_ARM64_ERRATUM_1024718
• CPU erratum是那些ARM core IP在设计时的缺陷所致的CPU硬件bug，因为IP已经集成在市面上的SoC里流片，不可能重新设计，只能通过软件做一些规避，这些规避方法，均记录在ARM的官方Errata文档（CPU勘误手册）里。
• 以A55来说，此Erratum编号为1024718，影响范围是所有版本号<=r2p0的Cortex-A55 core IP，规避办法是设置TCR_EL1.HD=0
• 笔者平台的CPU版本号，正好是r2p0，恰好在此Erratum的范围内，必须实施CONFIG_ARM64_ERRATUM_1024718

综上，5.10内核，因为上述的全部要素联合，就产生了这个permission page fault。

相关疑问与解答

问：为什么4.19没有此问题

答：

4.19具备其余所有要素，只缺要素1.b PAGE_SHARED联合属性，包含这样两个页表基本属性：PTE_RDONLY | PTE_DBM

4.19内核里，PAGE_SHARED联合属性，缺少PTE_RDONLY。

以下为4.19与5.10的 PAGE_SHARED宏对比：

4.19内核 #define PAGE_SHARED __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_WRITE)

5.10内核 #define PAGE_SHARED __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN | PTE_WRITE)

5.10内核多出来的PTE_RDONLY，再加上使得上述permission page fault触发了。

问：为什么5.10要引入PTE_RDONLY属性？

答：

5.10对PTE_RDONLY引入，是ARM官方maintainer的刻意行为，源于commit:

https://github.com/torvalds/linux/commit/aa57157be69fb599bd4c38a4b75c5aad74a60ec0 arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default

从该commit描述看，对此的引入是合理的，因为引入者预期配置了TCR_EL1.HD=1，即问题要素2.A）的路径，由CPU硬件自动处理页表项RO转RW。只有当诸如CONFIG_ARM64_ERRATUM_1024718这样的CPU erratum软件规避开启时，因为系统寄存器TCR_EL1.HD=0，才会落入到permission page fault的情景中。而这个是commit原作者可能未注意到的情况。实测发现，去掉此erratum，page fault也确实消失了。

问题解决方案

目前采用的办法是一个workaround（而非fix）：单把PAGE_SHARED属性回退为与4.19内核一致（参考前文提到的那个commit）。实测性能与4.19几乎无差别了：

因为那个ARM官方的commit是社区深思熟虑的刻意行为，回退并不现实，根本解决办法，应该是给出一个综合的patch，使得方方面面的情况都照顾到。

问题回顾

这个bug卡笔者最长的时间，其实是在这一条：为什么remap_pfn_range之后仍发生了page fault？因为笔者先入为主的观念，把所有page fault都当成了缺页异常，而没有第一时间想到permission fault的可能，导致浪费了大量时间来分析remap_pfn_range的行为，虽然代码逻辑整理了不少，但一直没能进入核心要点。这一点突破以后，后面的分析和解决就是水到渠成的事情了。