Linux内核为什么会发生soft lockup?【转】

转自:https://blog.csdn.net/21cnbao/article/details/108250786

提到soft lockup,大家都不会陌生:

BUG: soft lockup - CPU#3 stuck for 23s! [kworker/3:0:32]

这个几乎和panic,oops并列,也是非常难以排查甚至比panic更麻烦。至少panic之后你可以去分析一个静态的尸体,然而soft lockup,那是一个动态的过程,甚至转瞬即逝,自带自愈功能。

那么soft lockup是由于什么原因导致的呢?

几乎没有这方面的文章,能找到的也只有个别的案例分析,所以我想趁着周末降至来写一篇关于soft lockup的通用解释。

首先澄清两个关于soft lockup的误区:

  • soft lockup并不仅仅是由死循环引起的。

  • soft lockup并不是说在一段代码里执行了23秒,22秒。

这里简单解释一下上面的两点。

事实上,死循环并不一定会导致soft lockup,比如Linux内核生命周期内的0号进程就是一个死循环,此外很多的内核线程都是死循环。

此外,更难指望一段代码可以执行20多秒,要对现代计算机的速度有所概念。

soft lockup发生的真实场景是:

  1. soft lockup是针对单独CPU而不是整个系统的。

  2. soft lockup指的是发生的CPU上在20秒(默认)中没有发生调度切换。

第一点无须解释,下面重点看第二点。

很显然, 只要让一个CPU在20秒左右的时间内都不发生进程切换,就会触发soft lockup ,这个 “20秒内不切换” 就是soft lockup发生的根因!

好了,现在我们来看20秒不切换的场景。

  • 死循环的情况
    这是最简单的场景,但细节往往不像看起来那么简单。比如你写了一个死循环在内核中执行,它一定会导致soft lockup吗?

我们来看一个内核死循环:

  1.  
    #include <linux/module.h>
  2.  
    #include <linux/kthread.h>
  3.  
     
  4.  
     
  5.  
    static int loop_func(void *arg)
  6.  
    {
  7.  
    int i = 0;
  8.  
    while(!kthread_should_stop()) {
  9.  
    i++;
  10.  
    }
  11.  
    return 0;
  12.  
    }
  13.  
     
  14.  
     
  15.  
    struct task_struct *kt;
  16.  
    static int __init init_loop(void)
  17.  
    {
  18.  
    kt = kthread_run(loop_func, NULL, "loop_thread");
  19.  
    if (IS_ERR(kt)) {
  20.  
    return -1;
  21.  
    }
  22.  
     
  23.  
     
  24.  
    return 0;
  25.  
    }
  26.  
     
  27.  
     
  28.  
    static void __exit exit_test(void)
  29.  
    {
  30.  
    kthread_stop(kt);
  31.  
    }
  32.  
     
  33.  
     
  34.  
    module_init(init_loop);
  35.  
    module_exit(exit_loop);
  36.  
    MODULE_LICENSE("GPL");
  37.  
     
  38.  
     

加载这个模块,会soft lockup吗?

我们知道,虽然loop thread是一个死循环,但是它看起来正如一个普通用户态进程一样,在执行i++循环的时候,其实是可以被其它task抢占掉的,这是最基本的进程调度的常识。

但是如果你真的去加载这个模块,你会发现在有些机器上,它确实会soft lockup,但有的机器上不会,这又是为什么?

这里的关键在于 内核抢占 。你看下自己系统内核的配置文件,如果下面的配置打开,意味着上述模块的死循环不会造成soft lockup:

CONFIG_PREEMPT=y

如果这个配置没有开,那么便 刑不上内核 了,因为它在内核态执行,所以没有谁可以抢占它,进而发生soft lockup。

我们对上述的死循环代码是否会触发soft lockup已经很明确了,下面我们看另一种情况。

如果死循环不在内核线程上下文,而是在软中断上下文,会怎样?

很显然,软中断不能被进程抢占,所以一定会soft lockup。

当然,如果真的发生了死循环导致的soft lockup,那肯定是在一个循环代码中执行超过20秒了,不说20秒,如果无人干涉,200000秒都是有的…

现在我们来看另一种复杂的情况,即timer的情况。在讨论timer时,我假设系统的内核抢占是开启的,这样更容易分类讨论,否则,如果关闭了内核抢占,那么事情会变得更加严重。

  • timer的情况

我们先看下面的timer回调函数:

  1.  
    static void timer_func(unsigned long data)
  2.  
    {
  3.  
    mdelay(1);
  4.  
    mod_timer(&timer, jiffies + 200);
  5.  
    }

仅仅执行1ms的函数,它会导致超过20秒不调度切换的soft lockup吗?

初看,应该不会,但是如果我们详细看了Linux内核timer的执行原理,就会明白:

  • pending在一个CPU上的所有过期timer是顺序遍历执行的。

  • 一轮timer的顺序遍历执行是持有自旋锁的。

这意味着在执行一轮过期timer的过程中,watchdog实时线程将无法被调度从而喂狗,这意味着:

  • 同一CPU上的过期timer积累到一定量,其回调函数的延时之和大于20秒,将会soft lockup。

我们需要进一步了解一下Linux timer的工作机制。

可以把timer的执行过程抽象成下面的逻辑:

  1.  
    run_timers()
  2.  
    {
  3.  
    while (now > base.early_jiffies) {
  4.  
    for_each_timer(timer, base.list) {
  5.  
    detach_timer(timer)
  6.  
    forward_early_jiffies(base)
  7.  
    call_timer_fn(timer)
  8.  
    }
  9.  
    }
  10.  
    }

很简单的流程,内核把当前过期的timer执行到结束。run_timers可以在软中断上下文中执行,也可以在softirqd内核线程上下文中执行,为了营造soft lockup,我们假设它是在时钟中断退出时的软中断上下文中执行的(记住之前还有个假设,即系统是开启内核抢占的!),此时,run_timers不能被watchdog抢占。

如果一个timer中耗时1ms,那么一个循环需要20000个timer遍历执行,才能凑齐20秒的不能被抢占的时间,进而引发soft lockup。我的天,20000个timer,不可思议!

其实根本就不需要20000个timer,200个足矣!

问题就出现在call_timer_fn,它实际上是调用该timer回调函数的封装!我们知道,timer回调函数中执行了mod_timer的操作,它的逻辑如下:

  1.  
    mod_timer(timer, expires)
  2.  
    {
  3.  
    list_add_timer(timer, expires, base.list)
  4.  
    }

它事实上是把timer又插回了list,如果我们把这个list看作是一条时间线的话,它事实上只是往后移了expires这么远的距离:

假设所有timer的expire都是固定的常量,如果:

  • 我们的timer的足够多,多到按照其expires重新requeue时恰好能填补中间的那段空隙。

  • 我们的timer回调函数耗时恰好和timer的expires流逝速率相一致。

那么,两个甚至多个batch就合并成了一个batch,这意味着一轮timer的执行将不会结束!

我们来试一下:

#include <linux/module.h>
#include <linux/slab.h>
#include <asm-generic/delay.h>
#include <linux/kernel.h>
#include <linux/kallsyms.h>
#include <linux/delay.h>

 
static int stop = 1;
 
 
// timer的数量
static int size = 1;
module_param(size, int, 0644);
MODULE_PARM_DESC(size, "size");
 
 
// timer的expires
static int interval = 200;
module_param(interval, int, 0644);
MODULE_PARM_DESC(interval, "");
 
 
// 回调函数耗时
static int dt = 100;
module_param(dt, int, 0644);
MODULE_PARM_DESC(dt, "");

struct wrapper {
  struct timer_list timer;
  spinlock_t lock;
};

struct wrapper *wr;

static void timer_func(unsigned long data)
{
  int i = data;
  struct wrapper *w = &wr[i];
 
 
  spin_lock_bh(&(w->lock));
  if (stop == 0) {
    udelay(dt); // 以忙等模拟耗时
  }
  spin_unlock_bh(&(w->lock));

 
  w->timer.data = i;
  if (stop == 0) {
    mod_timer(&(w->timer), jiffies + interval);
  }
}
 
 
static int __init maint_init(void)
{
  int i;
 
 
  wr = (struct wrapper *)kzalloc(size*sizeof(struct wrapper), GFP_KERNEL);
 
 
  for (i = 0; i < size; i++) {
    struct wrapper *w = &wr[i];
    spin_lock_init(&(w->lock));
    init_timer(&(w->timer));
    w->timer.expires = jiffies + 20;
    w->timer.function = timer_func;
    w->timer.data = i;
    add_timer(&(w->timer));
  }
  stop = 0;
 
 
  return 0;
}
 
 
static void __exit maint_exit(void)
{
  int i;
 
 
  stop = 1;
  udelay(100);
  for (i = 0; i < size; i++) {
    struct wrapper *w = &wr[i];
    del_timer_sync(&(w->timer));
  }
  kfree(wr);
 
 
}
 
 
module_init(maint_init);
module_exit(maint_exit);
MODULE_LICENSE("GPL");

 

 

我的测试虚拟机HZ为1000,这意味1ms将会产生一次时钟中断,我们以每个timer函数持锁执行1ms,一共400个timer来加载模块,看下结果:

单核跑满,这意味着timer已经拼接成龙,20秒后,我们将看到soft lockup:

事实上,每个timer回调函数delay 800us,一共200个timer即可触发soft lockup!使用这个代码,你基本可以确定你要测试的机器的timer执行时间的安全阈值。

这就是timer导致的soft lockup的动力学。

关于HZ1000
1ms间隔的时钟中断对于服务器而言是悲哀的,1ms的时间无法容纳太多的timer,也不允许每个timer中有哪怕稍微的合理耗时,1ms一次中断很容易触发run_timers在软中断上下文中被执行,但很遗憾,这就是事实。

抛开timer不谈,HZ1000更多的意义在于快速响应事件而不是增加系统吞吐,这对服务器的单机性能是有伤害的!


说了这么多,现在让我们考虑一下现实。

除了不要在内核中写死循环之外,我们也不应该让timer回调函数执行过久,特别是系统中timer特别多,且expires特别短的情况下。

回到现实中,我们来看一个实例。

假设你使用的内核版本还不支持TCP的lockless listener,那么我们特别要注意一个函数,即 inet_csk_reqsk_queue_prune :

  • 这是一个在TCP的per listener的timer中执行的函数。

  • 这个函数的实现采用两层循环,循环耗时取决于:

  1. 外层循环:该listener的backlog大小,受程序配置控制。

  2. 内层循环:该listener的半连接队列的大小,受系统快照控制。

如果系统中的listener特别多,在收到SYN扫描攻击时,特别容易陷入soft lockup的深渊!幸运的是,这个问题已经在TCP lockless listener的版本中修了,它的效果如下:

  • 将per listener的半连接队列timer换成了per request timer,减少了回调函数处理耗时。

  • per request timer增加了timer的数量,会不会抵消缩短回调耗时带来的收益,需要攻击来验证。

我们看一个相关issue和patch:
https://patchwork.ozlabs.org/patch/452426/


好了,再次回到核心主题。

触发soft lockup的当然不止死循环和timer,我只是用这两个来说明soft lockup的动力学,即 超过2倍的kernel.watchdog_thresh时间不能进行进程调度,就会触发soft lockup告警。 至于说 stuck for 23s! 那只是表象,并不是如其字面表达的那样,23秒的时间在执行一段代码。

此外,频繁的spinlock,rwlock也会导致soft lockup,我这有一个关于IPv6路由查询机制的实例,详情参见:
https://blog.csdn.net/dog250/article/details/91046131

总之,所有的情况将不胜枚举,也不可能通过一篇文章来展示,所以说,遇到此类问题,还是要有一个明确的排查思路或者说范式,才能快速定位问题的根因并且解决之。

当然了,经理并不关注这些烂八七糟的东西。


浙江温州皮鞋湿,下雨进水不会胖。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。本文链接:https://blog.csdn.net/dog250/article/details/104997385

(END)

Linux阅码场原创精华文章汇总

更多精彩,尽在"Linux阅码场",扫描下方二维码关注

分享、在看与点赞,至少我要拥有一个吧

posted @ 2023-01-12 17:45  Sky&Zhang  阅读(417)  评论(0编辑  收藏  举报