3.10内核,在项目中遇到一种情况,我们根据sk指针hash到一个cpu上,然后访问该cpu对应分配的一个数据区。
然后系统会偶尔crash掉,crash掉有两种情况,一种是cred的rcu回收时出现计数bugon,一种是hung,
hung的这种一般是由于由一个持有mutex的进程在rttable的resize过程中synchronize_rcu() 出现等待gp,而另外一个进程也需要这把mutex的锁。
继续排查发现等待gp是因为synchronize_rcu() 自身的这个rcu没有及时处理,导致没有调用wakeup,
这种rcu还在对应的链中,也就是rcu出现累积,有的是几十万个rcu没有执行,有的甚至上千万个。在开启rcuo内核线程的代码中(RCU_NOCB),可以看到对应的线程
处于一种不干活的状态,
tatic int rcu_nocb_kthread(void *arg) { 。。。 while (list) { next = list->next; /* Wait for enqueuing to complete, if needed. */ while (next == NULL && &list->next != tail) {----------什么情况下会在这里循环 schedule_timeout_interruptible(1); next = list->next; } debug_rcu_head_unqueue(list); local_bh_disable(); if (__rcu_reclaim(rdp->rsp->name, list)) cl++; c++; local_bh_enable(); list = next; } 。。。。 }
很显然,原本的第二个while,应该只是一个无锁设计,也就是临时状态,但是从crash文件看,这里形成死循环了。
这种死循环,导致了后面的 __rcu_reclaim 并没有执行,从而导致rcu积压。
回过头来看,while循环的原因是因为,rcu_head的next指向NULL,同时它又不是最后一个rcu。
也就是rcu的串被破坏了,破坏的原因不是因为踩内存,而是因为,我们由一个流程有问题,导致同一个rcu_head被call_rcu了两次。
后面的问题我想大家也容易分析了,不过我们还遇到了两种情况,一种是,在同一个cpu上,同一个rcu_head被call_rcu了两次,
另外一种,是在两个cpu上分别执行,形成了环。