linux 内存踩踏导致的空指针问题分析纪要

news2025/4/13 11:46:52

1，查看日志信息打印

我们看到日志发现发包的skb模块有NULL pointer情况，我们看代码分析skb指针不可能出现是空指针，这个时候我们怀疑可能是出现了踩内存导致的空指针情况，所以我们首先需要找到系统PANIC的条件，也就是触发空指针（踩内存的条件）。

2，分析问题出现场景

最开始测试说这个问题是必现或者高概率复现的，我们查看日志看着空指针又没看出什么，后面我们自己想复现问题找到问题的触发条件，后面我们发现wifi测速时这个问题出现的概率比较高，但是后面我们加了一些打开符号表和其他的调试信息后发现问题问题出现的概率也不是很高，驱动专家们怀疑这个时候改了逻辑打开了符号表，可能踩到了其他的内存，这个时候我们只能通过测试场景去看问题了。

3，猜测内存踩踏点

最开始出现的场景是wifi测速时出现的，虽然PANIC收集的信息不是很完整，但是我们可以看到是wifi模块的tx_buf发包函数出现了空指针，所以我们先和协议的同事确认了一些测速时一些发包情况和发包函数，我们首先看到了协议栈的发包函数使用的是ndo_start_xmit。

netdev_tx_t ndo_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
// 停止队列以避免更多数据包进入
netif_stop_queue(dev);

// 调用硬件发送接口发送数据包
if (0 == hardware_send_frame(skb->data, skb->len)) {
// 更新设备统计信息
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
dev_kfree_skb(skb); // 释放数据包
return NETDEV_TX_OK;
} else {
// 发送失败，重启队列
netif_wake_queue(dev);
return NETDEV_TX_BUSY;
}
}

和协议栈的专家确认以及查看协议栈的发包函数的实现以及发包的流程，发现该线程是可重入的，但是没有加锁，所以可能会有问题，所以我们试着把ndo_start_xmit换成有RCU锁保护的dev_queue_xmit 函数，我们来看看函数dev_queue_xmit 的具体实现。

int dev_queue_xmit(struct sk_buff *skb)
{
struct net_device *dev = skb->dev;
struct Qdisc *q;
int rc = -ENOMEM;

// 使用RCU读取设备的队列规则
rcu_read_lock(); // 开启RCU读端临界区
q = rcu_dereference(dev->qdisc); // 安全地读取qdisc
rcu_read_unlock(); // 关闭RCU读端临界区

// 入队操作和发送流程
if (q->enqueue) {
rc = q->enqueue(skb, q);
if (likely(rc == NET_XMIT_SUCCESS)) {
__netif_schedule(q);
rc = NET_XMIT_SUCCESS;
}
}

// 无队列设备直接发送
if (dev->flags & IFF_LOOPBACK) {
rc = dev_hard_start_xmit(skb, dev, NULL, NULL);
}

return rc;
}

struct sk_buff *dev_hard_start_xmit(struct sk_buff *first, struct net_device *dev,
struct netdev_queue *txq, int *ret)
{
struct sk_buff *skb = first;
int rc = NETDEV_TX_OK;

while (skb) {
struct sk_buff *next = skb->next;

skb->next = NULL;
rc = xmit_one(skb, dev, txq, next != NULL); // 调用 xmit_one 发送数据包

if (unlikely(!dev_xmit_complete(rc))) {
skb->next = next;
goto out;
}

skb = next;
if (netif_xmit_stopped(txq) && skb) {
rc = NETDEV_TX_BUSY;
break;
}
}

out:
*ret = rc;
return skb;
}