【内核】深入分析内核panic(三)--内核错误处理流程

1 内核错误处理方式

当内核出现致命错误时,只要cpu还能正常运行,那么最重要的就是向用户输出详细的错误信息,以及保存问题出现时的错误现场。以上致命错误可包含以下两种类型:

(1)硬件能检测到的错误,如非法内存访问,非法指令等,此时cpu会触发异常,并进入异常处理流程。在异常处理流程中会触发oops或panic

(2)内核代码进入某些代码无法处理的异常分支,此时程序若继续执行可能会导致无法预知的后果,此时相关的代码会主动进入oops或panic

其中panic的含义为惊恐、恐慌,即内核将无法继续进行,它会根据配置确定是否crash dump 内存,向关心panic事件的模块发送notifier通知,以及打印panic相关的系统信息,最后将系统挂起或重启。

oops的严重程度低于panic,因此在一般情况下其只是输出相关的错误信息,并退出进程,而并不会挂起内核。但是若oops发生在中断上下文,或内核配置了panic_on_oops选项,则它也会进入panic。

2 arm64异常信息寄存器

对于arm64架构,若cpu由于内存访问错误等原因进入异常,则可通过esr寄存器获取异常原因,并通过far寄存器获取异常内存的地址信息。其中esr寄存器定义如下:

img

上图中EC表示异常类型,如以下为其中的一些典型取值:

(1)b100000:来自低异常等级的指令错误,如用户态的非法指令。

(2)b100001:当前异常等级的指令错误。

(3)b100010:pc对齐错误。

(4)b100100:来自低异常等级的data abort异常,如用户态的内存异常。

(5)b100101:当前异常等级的data abort异常。

(6)b100110:栈指针sp对齐错误。

(7)b101111:serror中断,它属于异步异常,一般来自外部abort,如内存访问总线时产生的abort异常等。

IL表示异常发生时的指令长度,其取值如下:

(1)0:表示16位的thumb指令长度

(2)1:表示32位的arm指令长度

ISS表示每种类型的具体原因,它的取值会根据EC的不同而不同,如以EC为data abort为例,其相应的ISS定义如下(具体含义可参考armv8 trm):

img

 其中DFSC(data fault status code)用于给出data abort相关的信息,以下为其部分定义:

img

另外对于data abort类型异常,abort地址对于分析异常原因至关重要,因此armv8架构通过far寄存器提供了该地址的值(虚拟地址),其相应的寄存器定义如下:

img

3 异常处理流程

内核发生同步异常后,会根据异常发生时所处的异常等级(在当前异常等级,还是在低于当前异常等级中触发),和其所使用的栈指针类型(sp_el0还是sp_el1),跳转到相应的异常处理入口。

异常处理函数在执行一些上下文保存,栈指针切换等基础工作后,将跳转到特定类型的handler。如cpu在异常发生时处于arm64模式下,且使用的栈指针为sp_el1时,则其将会跳转到el1h_64_sync_handler中。

该函数会根据esr_el1寄存器中EC中的值,获取其对应的异常类型,然后调用特定异常类型相关的处理函数。在该函数中一般会通过esr_el1寄存器中ISS的值获取其具体的异常原因,并执行相应的处理。

在处理流程中,若异常确实为非法操作引起(异常并不一定是错误,如缺页异常,断点、单步调试等debug异常都是正常的代码处理逻辑),则会调用oops或panic向用户报告错误,并退出当前进程或挂起系统。

由于内核的异常种类繁多,而其处理流程又大同小异,因此下面将以arm64模式下,内核非法地址访问为例。其相应的处理流程如下:

img

3.1 data abort处理流程

el1h_64_sync_handler首先读取esr_el1寄存器的值,然后解析其中EC的内容,并根据EC值调用其对应的处理函数,如对于data abort将会调用el1_abort,以下为其代码实现:

asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs)
{
	unsigned long esr = read_sysreg(esr_el1);                  

	switch (ESR_ELx_EC(esr)) {                           
	case ESR_ELx_EC_DABT_CUR:
	case ESR_ELx_EC_IABT_CUR:
		el1_abort(regs, esr);
		break;
	case ESR_ELx_EC_PC_ALIGN:
		el1_pc(regs, esr);
		break;
	…
	default:
		__panic_unhandled(regs, "64-bit el1h sync", esr);
	}
}

el1_abort会调用do_mem_abort,该函数会根据esr_el1寄存器中DFSC的值,调用其相应的处理函数,这些函数通过以下所示的fault_info变量定义:

static const struct fault_info fault_info[] = {
	…
	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 0 translation fault"		},
	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 1 translation fault"		},
	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 2 translation fault"		},
	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 3 translation fault"		},
	{ do_bad,		SIGKILL, SI_KERNEL,	"unknown 8"			},
	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 access flag fault"	},
	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 access flag fault"	},
	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 3 access flag fault"	},
	…
}

以下为do_mem_abort的代码流程:

void do_mem_abort(unsigned long far, unsigned int esr, struct pt_regs *regs)
{
	const struct fault_info *inf = esr_to_fault_info(esr);          (1)
	unsigned long addr = untagged_addr(far);                        (2)

	if (!inf->fn(far, esr, regs))                                   (3)
		return;

	if (!user_mode(regs)) {                                         (4)
		pr_alert("Unhandled fault at 0x%016lx\n", addr);
		mem_abort_decode(esr);
		show_pte(addr);
	}

	arm64_notify_die(inf->name, regs, inf->sig, inf->code, addr, esr);
}

(1)根据DFSC的值在fault_info数组中选择其相应的处理函数指针

(2)由于arm64架构可利用虚拟地址空闲的高位bit存储tag信息,以支持MTE特性。因此在获取其实际虚拟地址时需要将相应的tag信息先移除

(3)调用fault_info中获取到的回调函数,对于非法地址访问错误,其相应的回调函数为do_translation_fault

(4)若异常为未知异常,则通过以下流程直接执行错误处理

do_translation_fault根据异常是由用户态触发还是内核态触发,分别调用其对应等的处理函数,其代码如下:

static int __kprobes do_translation_fault(unsigned long far,
					  unsigned int esr,
					  struct pt_regs *regs)
{
	…
	if (is_ttbr0_addr(addr))
		return do_page_fault(far, esr, regs);               (1)

	do_bad_area(far, esr, regs);                                (2)
	return 0;
}

(1)用户态处理函数

(2)内核态处理函数

对于内核态情形,其最终会调用die_kernel_fault执行实际的错误处理,其代码如下:

static void die_kernel_fault(const char *msg, unsigned long addr,
			     unsigned int esr, struct pt_regs *regs)
{
	…
	mem_abort_decode(esr);                             (1)

	show_pte(addr);                                    (2)
	die("Oops", regs, esr);                            (3)
	bust_spinlocks(0);
	do_exit(SIGKILL);                                  (4)
}

(1)它会解析esr_el1寄存器的值,并分别打印其相关的内容,如EC、IL、DFSC等

(2)该函数会打印异常地址对应的页表信息,包括pgd、p4d、pud、pmd和pte等

(3)执行实际的die操作,该流程将在下一节重点介绍

(4)杀死当前进程

3.2 die处理流程

die函数主要执行oops相关流程,且若异常为中断流程中触发或设置了panic_on_oops选项,则进一步通过panic将系统挂起。其主要流程如下:

void die(const char *str, struct pt_regs *regs, int err)
{
	…
	ret = __die(str, err, regs);                                  (1)

	if (regs && kexec_should_crash(current))
		crash_kexec(regs);                                    (2)
	…
	if (in_interrupt())
		panic("%s: Fatal exception in interrupt", str);
	if (panic_on_oops)                                            (3)
		panic("%s: Fatal exception", str);
	…
}

(1)调用die相关通知链对应的通知,使其执行die相关的操作,并打印oops相关的信息

(2)若需要crash系统,则通过该函数启动一个新的crash内核,并通过新内核将系统内存信息dump出来,以供事后分析。如可通过kdump或ramdump方式配置相应的crash内核

(3)若异常发生在中断中,或设置了panic_on_oops,则调用panic挂起系统

3.3 panic处理流程

当内核走到panic时表明其已无法继续运行下去,因此需要执行一些系统挂死前的准备工作,其主要包含以下部分:

(1)在smp系统中,一个cpu正在处理panic时,可能另一个cpu也会触发panic。而该流程主要用于一些错误信息收集、内存转储等工作,并不需要也不支持并发操作。因此对于后续触发的cpu不需要执行该流程

(2)若正在使用kgdb对内核进行调试,则显然希望调试器能继续执行调试工作。故此时不会真正将系统挂死,而是将控制权转交给调试器

(3)若内核配置了kdump等内存转储功能,则在panic时将启动转储相关的流程

(4)在smp系统挂死之前,需要停止所有其它cpu的运行,以使系统真正地停下来

(5)最后,打印相关的系统信息后,使系统重启或进入死循环

 其相应的代码实现如下:

void panic(const char *fmt, ...)
{
	…
	this_cpu = raw_smp_processor_id();
	old_cpu  = atomic_cmpxchg(&panic_cpu, PANIC_CPU_INVALID, this_cpu);

	if (old_cpu != PANIC_CPU_INVALID && old_cpu != this_cpu)                       (1)
		panic_smp_self_stop();
	…
	pr_emerg("Kernel panic - not syncing: %s\n", buf);
	…
	kgdb_panic(buf);                                                               (2)

	if (!_crash_kexec_post_notifiers) {
		printk_safe_flush_on_panic();
		__crash_kexec(NULL);                                                   (3)

		smp_send_stop();                                                       (4)
	} else {
		crash_smp_send_stop();                                                 (5)
	}

	atomic_notifier_call_chain(&panic_notifier_list, 0, buf);                      (6)

	printk_safe_flush_on_panic();
	kmsg_dump(KMSG_DUMP_PANIC);                                                    (7)

	if (_crash_kexec_post_notifiers)
		__crash_kexec(NULL);                                                   (8)

	…
	panic_print_sys_info();                                                        (9)

	if (!panic_blink)
		panic_blink = no_blink;

	if (panic_timeout > 0) {
		pr_emerg("Rebooting in %d seconds..\n", panic_timeout);

		for (i = 0; i < panic_timeout * 1000; i += PANIC_TIMER_STEP) {
			touch_nmi_watchdog();
			if (i >= i_next) {
				i += panic_blink(state ^= 1);
				i_next = i + 3600 / PANIC_BLINK_SPD;
			}
			mdelay(PANIC_TIMER_STEP);                                      (10)
		}
	}
	if (panic_timeout != 0) {
		if (panic_reboot_mode != REBOOT_UNDEFINED)
			reboot_mode = panic_reboot_mode;
		emergency_restart();                                                   (11)
	}
	…
	pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);

	suppress_printk = 1;
	local_irq_enable();
	for (i = 0; ; i += PANIC_TIMER_STEP) {
		touch_softlockup_watchdog();
		if (i >= i_next) {
			i += panic_blink(state ^= 1);
			i_next = i + 3600 / PANIC_BLINK_SPD;
		}
		mdelay(PANIC_TIMER_STEP);                                              (12)
	}
}

(1)若先前已经有cpu正在处理panic流程,则本cpu不再重复处理,只需将当前cpu停止

(2)打印panic原因信息

(3)若panic流程会执行内存转储,则所有系统相关信息都会被保存到转储文件中,因此就不需要调用后面的通知链,因此可直接调用转储操作。但是转储操作也不是100%保险,因此若不是对其绝对信任,则会设置_crash_kexec_post_notifiers,它会先执行通知链调用和log dump相关流程,再调用内核转储操作。

__crash_kexec函数会根据当前是否设置了转储内核确定是否实际执行转储操作,若执行转储则会通过kexec将系统切换到新的kdump内核,并且不再会返回。若不执行转储则继续执行后续流程

(4 - 5)停止当前cpu之外的其它cpu运行

(6)调用关心panic事件相关模块向其注册的通知

(7)dump内核log buffer中的log信息

(8)若设置了_crash_kexec_post_notifiers,则根据是否设置了kexec内核,确定是否执行内存转储操作

(9)若不执行内存转储,则打印系统相关信息

(10)若设置了panic_timeout超时值,则执行超时等待操作

(11)若设置了panic_timeout超时值,在超时等待完成后重启系统

(12)若未设置panic_timeout超时值,则将系统设置为死循环状态,使其挂死

4 如何手动触发oops和panic

在编码流程中,可能有一些非期望的代码分支,当系统进入这些分支表明出现了一些问题或严重错误。根据问题严重等级的不同,我们可能希望程序能打印一些警告信息,或者将系统设置为oops,甚至panic状态。

为此,内核提供了一些相关的宏和函数用于支持上述需求,以下为其中一些常用的定义:

(1)WARN_ON():打印警告信息和调用栈,但不会进入oops或panic

(2)BUG_ON():打印bug相关信息,并进入oops流程

(3)panic():该函数将直接出发panic流程,将系统设置为挂死状态

 除了通过编码方式以外,用户还可以通过sysrq魔术键触发panic流程,下面为通过proc方式触发sysrq相关panic流程的命令:

 echo c > /proc/sysrq-trigger

原文链接:https://www.zhihu.com/column/c_1533871448917118976 版权归原作者所有,如有侵权,请联系作者删除

posted @ 2023-04-30 11:12  学习,积累,成长  阅读(758)  评论(0编辑  收藏  举报