多台环境 kernel panic ，内核有etmemd 操作的内存页触发lru异常告警

<h3>优先级:</h3>次要<h3>详细描述:</h3>openEuler-22.03-LTS-SP1环境都有etmemd进程访问内存page页触发内核lru链表损坏告警分析vmcore，etmemd触发告警的page页是最后panic流程对应page的头page，触发panic的页其内部mapping变量值异常<h3>原因分析:</h3>【是否新引入rpm包，是否进行了安全编译选项扫描】否【定位分析】 经代码逻辑分析，在etmem 换出流程中会先调用如下两个接口：get_page_from_vaddr 与 add_page_for_swap；其中 get_page_from_vaddr 通过 vaddr 获取到待换出的page页面，并对该page页面引用计数进行加1操作；add_page_for_swap 接口将该页面从LRU中隔离出来，并用于后续回收。 在该代码中经分析具有如下两个问题： page ref count 引用计数泄漏问题在get_page_from_vaddr 获取引用计数后，如果页面的 page_mapcount &gt; 1或者pageHuge 是个静态大页，会放弃回收该页面，但是在此处返回，没有释放对应的引用计数，导致泄漏。该泄漏会导致page引用计数不断上升，但是因为etmem为周期性运行，且最小周期为3秒钟，因此，远远达不到翻转程度，不是此问题的根因。 2。 如果待换出页面是一个透明大页，而且该大页被置位了 pageMlock标记，但是对应的 vma 地址段没有VM_LOCK标记，且page是一个compound page的中间页面，会导致PageUnevictabel 标记判断成功，putback_lru_page会操作compound page的中间页面，从而导致页面状态信息不对。最终引发call trace问题。 该问题触发的根因需要开启透明大页，待换出进程的业务使用了透明大页，并且业务环境上配置了内存复用，使能了etmem，同时发挥作用会有概率触发etmem 此 问题。修复方案是将在获取到head页面后，均使用head头页来进行判断处理即可。【对外部是否有影响】否【是否修改引入】

GVP openEuler/kernel

内容风险标识

评论 (2)

GVPopenEuler/kernel

内容风险标识