fsl_dpa驱动网卡sk_buff内存泄漏导致系统崩溃，求诊断方案

泄漏场景与fsl_dpa（飞思卡尔DPAA架构）网卡驱动的组播/广播报文处理逻辑强相关，网卡DOWN/UP操作可强制回收泄漏对象的特征，明确指向驱动接收路径的引用计数泄漏问题，具体根因及验证方案如下：

1. 核心根因定位 #

fsl_dpa驱动老版本存在组播/广播报文的skb引用计数泄漏bug：

• 当网卡加入组播组、或开启混杂模式时，广播/组播帧进入驱动接收队列后，若协议栈处理时对skb做了克隆操作，驱动遗漏对原始skb的引用计数递减逻辑，会导致skb->users计数永远大于0，无法被系统自动回收，最终堆积在skbuff_head_cache slab池耗尽内存。
• 执行ifconfig eth4 down时，驱动会强制销毁所有接收队列，批量释放所有持有引用的skb对象，和你观测到的skbuff_head_cache活动对象从24万骤降到3千的表现完全匹配。

2. 验证步骤 #

可通过以下操作确认根因：

• 检查eth4混杂模式状态：ip link show eth4，若存在PROMISC标记，执行ip link set eth4 promisc off关闭混杂模式，观测/proc/slabinfo中skbuff_head_cache的活动对象数是否下降。
• 检查eth4加入的组播组：ip maddr show dev eth4，逐一删除非业务必要的组播组，观测内存占用变化。
• 核对驱动源码：查看内核源码中drivers/net/ethernet/freescale/dpaa/dpaa_eth_rx.c的dpaa_eth_rx()函数，是否存在组播报文上送后未调用dev_kfree_skb()的分支逻辑，飞思卡尔官方已发布过对应问题的补丁，可直接对照补丁修复。

3. 临时规避方案 #

在完成驱动补丁升级前，可定期检测skbuff_head_cache的活动对象数，超过预设阈值时执行ip link set eth4 down && ip link set eth4 up操作回收泄漏内存，避免系统崩溃。

内容的提问来源于stack exchange，提问作者邢庆杰