标签：head 遇到 rcu list next while 使用 cpu

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上分别执行，形成了环。

标签：head,遇到,rcu,list,next,while,使用,cpu
来源： https://www.cnblogs.com/10087622blog/p/11568794.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。