免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

本文是羽千葉同學在實際工作過程中遇到的復雜的服務器宕機問題的真實案例。羽同學說奔跑吧死機黑屏專題對解決死機問題很有啟發(fā)和幫助很大。

一、環(huán)境

OS：centos7.7
kernel：3.10.0-1062.7.1

二、宕機信息

出錯位置在第二行報出，位于check_preempt_wakeup偏移0xe9處；
Code這行代碼中<49>是出錯機器碼起始字節(jié).

crash> dis check_preempt_wakeup+233
0xffffffffba2e5b49 <check_preempt_wakeup+233>:  mov    0x70(%r12),%rdi
crash> rd -8 0xffffffffba2e5b49 5
ffffffffba2e5b49:  49 8b 7c 24 70

三、調試

下載kernel-debuginfo-3.10.0-1062.7.1.el7.x86_64.rpm、kernel-debuginfo-common-x86_64-3.10.0-1062.7.1.el7.x86_64.rpm調試包
解壓kenel-debuginfo包

1、查看調用棧信息

crash> bt
PID: 29670  TASK: ffff96808d678000  CPU: 1   COMMAND: 'runc:[2:INIT]'
 #0 [ffff96809173ba90] machine_kexec at ffffffffba265b24
 #1 [ffff96809173baf0] __crash_kexec at ffffffffba322422
 #2 [ffff96809173bbc0] crash_kexec at ffffffffba322510
 #3 [ffff96809173bbd8] oops_end at ffffffffba985798
 #4 [ffff96809173bc00] no_context at ffffffffba275bb4
 #5 [ffff96809173bc50] __bad_area_nosemaphore at ffffffffba275e82
 #6 [ffff96809173bca0] bad_area_nosemaphore at ffffffffba275fa4
 #7 [ffff96809173bcb0] __do_page_fault at ffffffffba988750
 #8 [ffff96809173bd20] trace_do_page_fault at ffffffffba988a26
 #9 [ffff96809173bd60] do_async_page_fault at ffffffffba987fa2
#10 [ffff96809173bd80] async_page_fault at ffffffffba9847a8
    [exception RIP: check_preempt_wakeup+233]
    RIP: ffffffffba2e5b49  RSP: ffff96809173be30  RFLAGS: 00010006
    RAX: 0000000000000002  RBX: ffff96809025af00  RCX: 0000000000000000
    RDX: 0000000000000002  RSI: ffff9680406f9070  RDI: ffff96809fc9ad00
    RBP: ffff96809173be68   R8: ffffffffbaa1e3c0   R9: 0000000000000000
    R10: 000000000000b8ff  R11: f448000000000000  R12: 0000000000000000
    R13: ffff96808d678000  R14: ffff96809fc9ac80  R15: 0000000000000001
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
#11 [ffff96809173be70] check_preempt_curr at ffffffffba2d7782
#12 [ffff96809173be88] wake_up_new_task at ffffffffba2dad24
#13 [ffff96809173bec0] do_fork at ffffffffba29a9f1
#14 [ffff96809173bf38] sys_clone at ffffffffba29acb6
#15 [ffff96809173bf48] stub_clone at ffffffffba98e2b4
#16 [ffff96809173bf50] system_call_fastpath at ffffffffba98dede
    RIP: 00007f9ca630e851  RSP: 00007ffe97b8c2e8  RFLAGS: 00000202
    RAX: 0000000000000038  RBX: 00007f9ca2ffc700  RCX: ffffffffffffffff
    RDX: 00007f9ca2ffc9d0  RSI: 00007f9ca2ffbfb0  RDI: 00000000003d0f00
    RBP: 00007ffe97b8c410   R8: 00007f9ca2ffc700   R9: 00007f9ca2ffc700
    R10: 00007f9ca2ffc9d0  R11: 0000000000000202  R12: 0000000000000000
    R13: 0000000000801000  R14: 0000000000000000  R15: 00007f9ca2ffc700
    ORIG_RAX: 0000000000000038  CS: 0033  SS: 002b

2、反匯編出錯位置

將r12+0x70地址處內容取出來，賦值給rdi，而出錯時候r12寄存器值為0，即訪問了地址0x70，該地址是一個非法地址，所以導致內核宕機。

3、找出出錯位置對應的源代碼

crash> dis check_preempt_wakeup+233 -l
/usr/src/debug/kernel-3.10.0-1062.7.1.el7/linux-3.10.0-1062.7.1.el7.x86_64/kernel/sched/fair.c: 343
0xffffffffba2e5b49 <check_preempt_wakeup+233>:  mov    0x70(%r12),%rdi

報錯說是源碼中343行，其實不是這一行。通過此種方式得出的出錯位置不準確。下面通過兩種方式來獲取準確的出錯位置。

四、找到準確出錯位置

1、分析源代碼來查找

棧調用關系是：do_fork---->wake_up_new_task---->check_preempt_curr---->check_preempt_wakeup
wake_up_new_task函數(shù)中調用check_preempt_curr為：

check_preempt_curr就是check_preempt_wakeup函數(shù)
可以看到check_preempt_wakeup有三個參數(shù)，是通過check_preempt_curr函數(shù)調用 rq->curr->sched_class->check_preempt_curr進行傳遞。
x86下參數(shù)傳遞通過寄存器傳遞：%rdi、%rsi、%rdx、%rcx、%r8、%r9依次對應第1個參數(shù)、第2個參數(shù)……，如果有超過的參數(shù)則通過棧傳遞。
通過上面函數(shù)調用關系，可以得知第三個參數(shù)wake_flags=WF_FORK；
下面我們通過匯編來推導第1個以及第2個參數(shù)；第一個參數(shù)rq通過%rdi寄存器傳入；第二個參數(shù)通過%rsi寄存器傳入；
如果在函數(shù)入口處就知道這兩個寄存器的值，那么就可以確定函數(shù)參數(shù)值。

static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
{
    ……
}

1.1通過匯編推導函數(shù)參數(shù)

check_preempt_wakeup函數(shù)對應的匯編代碼如下：

1.2 推導第1個參數(shù)

第一個參數(shù)是通過寄存器%rdi傳入，在匯編代碼中偏移13位置處，看到將%rdi寄存器賦值給了%r14寄存器，
而%r14寄存器，從此時被賦值開始到發(fā)生宕機時刻，值都沒有發(fā)生改變，
說明%r14寄存器里面保存了函數(shù)入口的第一個參數(shù)值；

crash> dis check_preempt_wakeup | grep r14                                                  //過濾出包含r14的指令
0xffffffffba2e5a6b <check_preempt_wakeup+11>:   push   %r14
0xffffffffba2e5a6d <check_preempt_wakeup+13>:   mov    %rdi,%r14
0xffffffffba2e5b9e <check_preempt_wakeup+318>:  mov    %r14,%rdi    
0xffffffffba2e5bb0 <check_preempt_wakeup+336>:  cmp    0x8b0(%r14),%r13
0xffffffffba2e5c09 <check_preempt_wakeup+425>:  pop    %r14
0xffffffffba2e5c27 <check_preempt_wakeup+455>:  pop    %r14

通過宕機時候打印出的寄存器信息，可以得到%r14=ffff96809fc9ac80，所以函數(shù)入口第一個參數(shù)值為rq=ffff96809fc9ac80；

1.3 推導第2個參數(shù)

第二個參數(shù)是通過寄存器%rsi傳入，過濾出函數(shù)中%rsi的指令，發(fā)現(xiàn)從進入check_preempt_wakeup函數(shù)開始到宕機時刻,
%rsi指令的值都沒有變化，所以宕機時刻寄存器%rsi中就保存著第2個參數(shù)值。%rsi=ffff9680406f9070，所以函數(shù)入口第二個參數(shù)值為
p=ffff9680406f9070;

通過上面推導函數(shù)check_preempt_wakeup的三個參數(shù)為：
struct rq *rq=ffff96809fc9ac80；
struct task_struct *p=ffff9680406f9070；
int wake_flags=WF_FORK；
如果直接在check_preempt_wakeup中無法推出函數(shù)參數(shù)值，則可以向上在調用者代碼中進行推斷。

1.4 分析check_preempt_wakeup函數(shù)

struct rq *rq=ffff96809fc9ac80，struct task_struct *p=ffff9680406f9070，int wake_flags=WF_FORK;

static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
{
        struct task_struct *curr = rq->curr;                    //crash> struct rq.curr ffff96809fc9ac80
                                                                //------>curr = 0xffff96808d678000          

        struct sched_entity *se = &curr->se, *pse = &p->se;     //crash> struct task_struct -x -o | grep sched_entity
                                                                //[0x68] struct sched_entity se;
                                                                //------>se=0xffff96808d678068，pse=0xffff9680406f90d8

        struct cfs_rq *cfs_rq = task_cfs_rq(curr);              // curr->se.cfs_rq
                                                                //crash> struct task_struct.se.cfs_rq 0xffff96808d678000
                                                                //se.cfs_rq = 0xffff967f41400400
                                                                //------>cfs_rq=0xffff967f41400400                                                               

        int scale = cfs_rq->nr_running >= sched_nr_latency;     //crash> p sched_nr_latency         crash> struct cfs_rq.nr_running 0xffff967f41400400                
                                                                //sched_nr_latency = $1 = 2         nr_running = 2
                                                                //------>scale=(2>=2)=1;
        int next_buddy_marked = 0;

        if (unlikely(se == pse))                                //此處se=0xffff96808d678068,pse=0xffff9680406f90d8，兩者不相等，所以不返回；
                return;

        if (unlikely(throttled_hierarchy(cfs_rq_of(pse))))      //cfs_rq_of(pse)：pse->cfs_rq
                return;                                         //crash> struct sched_entity.cfs_rq 0xffff9680406f90d8          crash> struct cfs_rq.throttle_count 0xffff967f41400400
                                                                //cfs_rq = 0xffff967f41400400                                   throttle_count = 0
                                                                //所以此處條件也不成立，不返回；


        if (sched_feat(NEXT_BUDDY) && scale && !(wake_flags & WF_FORK)) {     //此處wake_flags=WF_FORK，所以!(wake_flags & WF_FORK)條件不成立，不執(zhí)行條件體語句。
                set_next_buddy(pse);
                next_buddy_marked = 1;
        }

        if (test_tsk_need_resched(curr))                        //crash> struct task_struct.stack 0xffff96808d678000            crash> struct thread_info.flags 0xffff968091738000
                return;                                         //stack = 0xffff968091738000                                    flags = 128
                                                                //由于thread_info->flags中沒有設置TIF_NEED_RESCHED，所以此處條件不成立，不返回；

        if (unlikely(curr->policy == SCHED_IDLE) &&             //crash> struct task_struct.policy 0xffff96808d678000
            likely(p->policy != SCHED_IDLE))                    //policy = 0                                
                goto preempt;                                   //SCHED_IDLE=5與curr->policy=0不相等，條件不成立，所以不跳轉；

        if (unlikely(p->policy != SCHED_NORMAL) || !sched_feat(WAKEUP_PREEMPTION))  //該處條件也不成立，不跳轉；
                return;

        find_matching_se(&se, &pse);                            //------------>進入find_matching_se函數(shù)中執(zhí)行
        update_curr(cfs_rq_of(se));
        BUG_ON(!pse);
        if (wakeup_preempt_entity(se, pse) == 1) {
                if (!next_buddy_marked)
                        set_next_buddy(pse);
                goto preempt;
        }

        return;

preempt:
        resched_curr(rq);
        if (unlikely(!se->on_rq || curr == rq->idle))
                return;

        if (sched_feat(LAST_BUDDY) && scale && entity_is_task(se))
                set_last_buddy(se);
}

cfs_rq在sched_entity中偏移0x70，出錯位置處匯編指令是從以%r12為基地址，偏移0x70處取值，即獲取sched_entity->cfs_rq的值，所以經(jīng)過上述對源碼分析可以找到出錯位置。

crash> dis check_preempt_wakeup+233
0xffffffffba2e5b49 <check_preempt_wakeup+233>:  mov    0x70(%r12),%rdi
crash> struct sched_entity -x -o | grep cfs_rq
[0x70] struct cfs_rq *cfs_rq;

1.5 出錯原因

出錯原因是由于父子進程的depth不匹配；主線中有相關patch，升級patch解決。
[upstream eeb61e53ea19be0c4015b00b2e8b3b2185436f2b]

父進程:depth = 0;parent = 0;
            depth = 1;parent = 0xffff96809025af00;
      depth = 2;parent = 0xffff967f2e069300;
      depth = 3;parent = 0xffff968095227900;
子進程:depth = 0;parent = 0;
            depth = 1;parent = 0xffff96809025af00;
      depth = 2;parent = 0xffff967f2e069300;
      depth = 2;parent = 0xffff968095227900;

2、分析匯編代碼來查找