MCE与mcelog之前的交互

August 21st, 2015 by JasonLe's Tech 1,460 views

mcelog是在用户空间实现记录解码MCA报告的硬件错误信息的工具,而MCA则是一个内核机制,用来收集硬件错误信息。但是这个时候仅仅是一系列的错误代码,需要依靠用户空间的mcelog进行解码。二者是如何协调的呢?

通过查看相关代码,二者交互的接口是/dev/mcelog ,而mcelog在这个字符设备上休眠,直到mcelog被唤醒,读取这个字符设备中的信息,谁来唤醒这个daemo呢?

我们看到在mce代码初始化的时候,初始化了一个工作队列和一个irq队列,二者本质上调用的内容是一样的

void mcheck_cpu_init(struct cpuinfo_x86 *c)
{
...
    if (__mcheck_cpu_ancient_init(c))
        return;
...
    machine_check_vector = do_machine_check;

...
    INIT_WORK(this_cpu_ptr(&mce_work), mce_process_work);
    init_irq_work(this_cpu_ptr(&mce_irq_work), &mce_irq_work_cb);
}

在do_machine_check()最后的代码调用了mce_report_event(),而这个函数包括两个部分,一个是通知mcelog读取字符设备,一个是记录通知等待队列mce_work,调用mce_process_work()记录这个MCE错误,通常这个错误是SRAO等级。

static void mce_report_event(struct pt_regs *regs)
{
         if (regs->flags & (X86_VM_MASK|X86_EFLAGS_IF)) {
                 mce_notify_irq();

                 mce_schedule_work();
                 return;
         }
         irq_work_queue(this_cpu_ptr(&mce_irq_work));
}

irq_work_queue()也是通过irq队列唤醒mce_irq_work_cb()函数,这个函数实质上还是mce_notify_irq()与mce_schedule_work()。

static void mce_irq_work_cb(struct irq_work *entry)
{
         mce_notify_irq();
         mce_schedule_work();
}

所以mce与mcelog最最核心的两个函数就是mce_notify_irq()与mce_schedule_work(),我们看到mce_notify_irq()首先唤醒了mce_chrdev_wait,这个正是mce_chrdev_poll()所等待的事件,/dev/mcelog字符驱动poll函数。

int mce_notify_irq(void)
{
...
         if (test_and_clear_bit(0, &mce_need_notify)) {
                 /* wake processes polling /dev/mcelog */
                 wake_up_interruptible(&mce_chrdev_wait);

                 if (mce_helper[0])
                         schedule_work(&mce_trigger_work);
...
}
static unsigned int mce_chrdev_poll(struct file *file, poll_table *wait)
{
         poll_wait(file, &mce_chrdev_wait, wait);
...
}

然后又唤醒mce_trigger_work工作队列,这个工作队列唤醒了mce_do_trigger工作函数call_usermodehelper(),这个函数非常神奇的地方在于可以从内核空间直接调用用户空间进程!

static void mce_do_trigger(struct work_struct *work)
{
         call_usermodehelper(mce_helper, mce_helper_argv, NULL, UMH_NO_WAIT);
}

第二个核心函数就是mce_schedule_work(),通过工作队列mce_work最终还是mce_process_work()->memory_failure()。

static void mce_schedule_work(void)
{
         if (!mce_ring_empty())
                 schedule_work(this_cpu_ptr(&mce_work));
}

这里代码逻辑其实很简单,但是使用了两种内核机制,最终还是记录到ring_buffer,memory_failure()修复,唤醒mcelog解码硬件错误信息,并将其记录到/var/log/mcelog。

 

具体查看 中断下半部的两种实现方式 中工作队列使用方式:

1. 通过下述宏动态创建一个工作:INIT_WORK(struct work_struct *work,void(*func)(void*),void *data);

2.每个工作都有具体的工作队列处理函数,原型如下:void work_handler(void *data)

3.将工作队列机制对应到具体的中断程序中,即那些被推后的工作将会在func所指向的那个工作队列处理函数中被执行。实现了工作队列处理函数后,就需要schedule_work函数对这个工作进行调度,就像这样:schedule_work(&work);

Linux 跨模块函数调用

August 20th, 2015 by JasonLe's Tech 1,103 views

在编写模块的时候,我们经常会同时编写多个模块,模块中的函数,难免会有相互调用的需求,这个时候我们需要修改调用这个函数的Makefile文件,使其可以找到要调用的函数。

我们可以举例Module A 与 Module B,Module A中含有Module B要调用的函数,模块A中使用EXPORT_SYMBOL或EXPORT_SYMBOL_GPL将要提供给B模块的函数导出,具体Module A的代码形式如下:

void A_function(void)
{
        printk("A function");
        return;
}
EXPORT_SYMBOL(A_function);

这个时候我们通过make 可以生成一系列的中间文件,这里面包括Module.symvers,如果我们打开看这个符号表,可以发现这个文件包含函数虚拟地址,函数名,模块路径,导出形式EXPORT_SYMBOL。

然后我们在Module B中使用这个A_function,需要首先声明extern void A_function(void);然后才可以使用。

extern void A_function(void);

static int __init B_init(void)
{
        printk("B_func module init!\n");
        A_function();
        return 0;
}

我们已经把函数主体编写完毕,但是当我们使用insmod插入这个模块时,我们会发现系统提示Unknwon symbol,所以这个时候我们要向Module A的Makefile中加入Module B的Module.symvers,这样kernel在插入Module A时才知道Module B的位置。

obj-m:= module-B.o
CURRENT_PATH:=$(shell pwd)
LINUX_KERNEL:=$(shell uname -r)
LINUX_KERNEL_PATH:=/lib/modules/$(LINUX_KERNEL)/build

KBUILD_EXTRA_SYMBOLS +=/home/dslab/kmod/huawei_hook/Module.symvers
export KBUILD_EXTRA_SYMBOLS

all:
 make -C $(LINUX_KERNEL_PATH) M=$(CURRENT_PATH) modules
clean:
 make -C $(LINUX_KERNEL_PATH) M=$(CURRENT_PATH) clean

还有一种方式,就是在kernel源码 编译的时候加入到源码树中的Module.symers,然后编译内核,不过显然这种方式过于笨重,推荐使用修改Module A的Module.symvers这种方式。

MCA子系统分析

August 10th, 2015 by JasonLe's Tech 1,901 views

Update 2015-6-15

machine check exception在Intel manual中是18号异常,主要用来处理硬件产生的异常,包括各种总线错误,内存错误,数据错误等。MCA子系统正是为了处理这个异常而设计的,由于这个子系统与寄存器紧密相关,所以我们需要阅读Intel manual chapter15后,才能理解本文章的一些函数与代码。

本文主要讨论SRAO,SRAR,UCNA类型的错误,其中SRAR错误错误等级最高,如果这个错误发生在kernel中,kernel默认panic。SRAO、UCNA等级不至于panic,但是当系统发生多次,仍有可能触发SRAR错误。

SRAO错误主要发生在Memory scrubbing 时,而Memory scrubbing主要通过定时ECC校验发现内存的单bit错误,但是对于多bit错误,导致内存错误失败,就会发生SRAO错误,发生这个错误意味着,系统检测到了内存错误,但是这个错误并没有被cpu使用,cpu的执行数据流仍然可以继续运行下去而不至于宕机。这就是RAS的目标。

下面函数就是MCA的初始化函数,__mcheck_cpu_ancient_init()初始化早期主板的MCA架构,类似于P4处理器。之后将do_machine_check()设定为MCE的异常处理函数,这里我不会展开。

__mcheck_cpu_init_generic()主要是用来初始化machine_check_poll(),这个函数主要用来处理UCNA/CE类型的错误,这个稍后进行介绍。__mcheck_cpu_init_vendor(c)主要是用来识别是Intel架构还是AMD架构,之后函数初始化了一个timer,用来定时调用machine_check_poll()轮询UCNA/CE错误。

最后又定义了一个工作队列mce_work,用来调用mce_process_work()函数,这个函数主要实现对SRAO类型错误的处理,最后并调用memory_failure()对错误进行恢复。(工作队列是处于进程上下文的的,这个也是memory_failure()要求的) mce_irq_work是一个信号队列,主要用来唤醒/dev/mcelog对于错误进行一个记录。

void mcheck_cpu_init(struct cpuinfo_x86 *c)
{
...
    if (__mcheck_cpu_ancient_init(c))
        return;
...
    machine_check_vector = do_machine_check;

    __mcheck_cpu_init_generic();
    __mcheck_cpu_init_vendor(c);
    __mcheck_cpu_init_timer();
    INIT_WORK(this_cpu_ptr(&mce_work), mce_process_work);
    init_irq_work(this_cpu_ptr(&mce_irq_work), &mce_irq_work_cb);
}

UCNA处理

下面我们来仔细说一下__mcheck_cpu_init_vendor(c);这个函数中完成了对于UCNA与Correctted Error的错误处理的初始化,通过下面初始化代码的函数调用关系,我们可以发现对于这两种类型的错误,handler就是intel_threshold_interrupt(),这个handler包括machine_check_poll()与mce_notify_irq()。这个函数本质上就是触发对于错误的记录,没有任何额外的操作,这就是叫UCNA(Uncorrected Error No Action)。machine_check_poll() 不对kernel产生任何影响,主要就是记录错误。

static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
{
    switch (c->x86_vendor) {
    case X86_VENDOR_INTEL:
        mce_intel_feature_init(c);
....
}
void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
    intel_init_thermal(c);
    intel_init_cmci();
}
static void intel_init_cmci(void)
{
...
    mce_threshold_vector = intel_threshold_interrupt;
...
}
static void intel_threshold_interrupt(void)
{
    if (cmci_storm_detect())
        return;
    machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(&mce_banks_owned));
    mce_notify_irq();
}

在最新的4.0.4代码里,machine_check_poll()包括下面的代码,所以对于UCNA类型的错误也只是将他记录在mce_ring中,之后使用memory_failure()进行处理,比如标记为HWPoison页框。

if (severity == MCE_DEFERRED_SEVERITY && memory_error(&m))
{
      if (m.status & MCI_STATUS_ADDRV) {
          mce_ring_add(m.addr >> PAGE_SHIFT);
          mce_schedule_work();
      }
}

SRAR/SRAO错误处理

综上所述do_machine_check()主要处理Fetal与SRAR/SRAO类型的错误,他会通过查表mce_severity()判断错误等级。找到这个SRAR类型错误发生位置,内核空间直接panic,用户空间杀死当前进程(进入machine check exception是一种NMI类型的异常,处于进程上下文),(对于发生在用户空间SRAR错误处理的时机就是把错误记录在mce_info结构体中,给当前进程设置TIF_MCE_NOTIFY标示,在返回用户空间时,调用mce_notify_process()-找出之前记录在struct mce_info的错误信息,进一步调用memory_failure()进行错误恢复处理)在最新的主线内核提交中,Luck, Tony <tony.luck@intel.com>提交了一个commit。在最新代码中,他删除了mce_info,mce_save_info(),mce_find_info(),mce_clear_info(),mce_notify_process()和位于do_notify_resume()中的mce_notify_process(),也就是说SRAR不在返回用户态前处理。

x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks

We now switch to the kernel stack when a machine check interrupts
during user mode. This means that we can perform recovery actions
in the tail of do_machine_check()

他改变了SRAR发生在用户空间时,通过设置fiag并调度的方式,直接在do_machine_check()最后加入对于这种错误的处理,并在末位加入memory_failure()的错误恢复,这里指出如果恢复失败,那么直接使用force_sig(SIGBUS, current)。

对于SRAO类型的错误主要通过记录在mce_ring中,然后通过工作队列的方式调用mce_process_work()方式调用memory_failure()进行错误处理。下面代码来自于do_machine_check()。

      if (severity == MCE_AO_SEVERITY &amp;&amp; mce_usable_address(&amp;m))
            mce_ring_add(m.addr >> PAGE_SHIFT);

do_machine_check() 在最后会通过调用mce_report_event()->mce_irq_work->wake up /dev/mcelog 记录SRAR/SRAO错误。 所有内存问题,最后都会调用memory_failure()函数,这个函数就是对于问题页框进行标记,然后解除与进程的关系映射等。

 

参考:

Memory scrubbing

中断下半部的两种实现方式

http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

machine_check_poll() 函数分析

July 28th, 2015 by JasonLe's Tech 1,230 views

machine_check_poll() 函数在kernel-3.18前,这个函数基本只是起一个记录的作用(调用mce_log()),在kernel-3.18后,加入的patch,可以使得该函数处理UCNA类型的错误。其他部差异不大,仅仅是扫描记录而已。而且在mce-severity.c中特定写入了UCNA类型的错误表。这个错误正是Intel manual中所规定的。

enum severity_level {
         MCE_NO_SEVERITY,
         MCE_DEFERRED_SEVERITY,
         MCE_UCNA_SEVERITY = MCE_DEFERRED_SEVERITY,
         MCE_KEEP_SEVERITY,
         MCE_SOME_SEVERITY,
         MCE_AO_SEVERITY,
         MCE_UC_SEVERITY,
         MCE_AR_SEVERITY,
         MCE_PANIC_SEVERITY,
};

这里为了兼容之前的MCE_KEEP_SEVERITY,加入了MCE_DEFERRED_SEVERITY 和 MCE_UCNA_SEVERITY 两个标志,并在machine_check_poll()中使用。

这里我们要注意的一点是:machine_check_poll工作在中断上下文,在调用mce_schedule_work()后,实际是通过调用工作队列中的mce_process_work() ,而这个函数会读取ring buffer中的错误数据。

@@ -630,6 +662,20 @@ void machine_check_poll(enum mcp_flags flags, mce_banks_t *b)

                if (!(flags & MCP_TIMESTAMP))
                        m.tsc = 0;
+
+               severity = mce_severity(&m, mca_cfg.tolerant, NULL, false);
+
+               /*
+                * In the cases where we don't have a valid address after all,
+                * do not add it into the ring buffer.
+                */
+               if (severity == MCE_DEFERRED_SEVERITY && memory_error(&m)) {
+                       if (m.status & MCI_STATUS_ADDRV) {
+                               mce_ring_add(m.addr >> PAGE_SHIFT);
+                               mce_schedule_work();
+                       }
+               }
+

这个时候我们看到memory_failure()已经工作在进程上下文,如果我们要对错误进行过滤的话,可以考虑在memory_failure()函数开头设置hook函数。

static void mce_process_work(struct work_struct *dummy)
{
               unsigned long pfn;
               while (mce_ring_get(&pfn))
                      memory_failure(pfn , MCE_VECTOR , 0);
}

 

参考:

[1] Intel Manual

MCA 中的 Monarch’s region

July 27th, 2015 by JasonLe's Tech 1,463 views

在do_machine_check()中,扫描banks的前后存在mce_start() 与 mce_end() 。这两个函数可以使得原有kernel中cpus 从并行执行转变为串行执行,先进入这个mce_start()函数的cpu便开始同步,这个函数主要等待所有的cpu都进入mce_start()后,才开始逐个扫描banks。

首先我们必须知道do_machine_check()中声明的order,no_way_out含义,order主要用来标示所有CPU进入handler的顺序。

no_way_out 大于0时,意味着kernel无法找到安全的方式恢复MCE(初始当前cpu no_way_out=0),而且会在进入mce_start()前首先通过mce_no_way_out()赋值一次no_way_out,判断出一次panic,当前cpu的no_way_out会被赋值为1。global_nwo标示一个全局的值,每个cpu都会有一个no_way_out,而global_nwo只有一个。

void do_machine_check(struct pt_regs *regs, long error_code)
{
... 
        int order;
        int no_way_out = 0; 
....
        no_way_out = mce_no_way_out(&m, &msg, valid_banks, regs);

        order = mce_start(&no_way_out);
        for (i = 0; i < cfg->banks; i++) {
             .... 
         }
 
        if (!no_way_out)
             mce_clear_state(toclear);
 
        if (mce_end(order) < 0)
             no_way_out = worst >= MCE_PANIC_SEVERITY;
....

根据代码,我们看到每个cpu都有超时限制,并会将当前的no_way_out加到全局global_nwo上(最后退出君主区域,正常系统应该为0,如果不为0,意味着有panic事件,总的来说global_nwo就是为了维持no_way_out的全局一致性),而mce_callin初始为0,首先到达此处的cpu将order+1。然后等待其他cpu自增,直到等于当前系统cpu的总数。如果等待超时,意味着出现不确定的问题,然后会在

if (mce_end(order) < 0)
        no_way_out = worst >= MCE_PANIC_SEVERITY;

直接赋值将no_way_out = 1,然后panic。

所有cpu都进入到mce_start()后,判断order(order=1的是Monarch ,order其他的是仆人,听命于Monarch),order=1时,这个君主将mce_executing置1,其他的cpu等待。

static int mce_start(int *no_way_out)
{
        int order;
        int cpus = num_online_cpus();
        u64 timeout = (u64)mca_cfg.monarch_timeout * NSEC_PER_USEC;

        if (!timeout)
                return -1;

        atomic_add(*no_way_out, &global_nwo);

        smp_wmb();
        order = atomic_inc_return(&mce_callin);

        while (atomic_read(&mce_callin) != cpus) {
                if (mce_timed_out(&timeout)) {
                        atomic_set(&global_nwo, 0);
                        return -1;
                }
                ndelay(SPINUNIT);
        }

        smp_rmb();

        if (order == 1) {
                /*
                 * Monarch: Starts executing now, the others wait.
                 */
                atomic_set(&mce_executing, 1);
        } else {
                while (atomic_read(&mce_executing) < order) {
                        if (mce_timed_out(&timeout)) {
                                atomic_set(&global_nwo, 0);
                                return -1;
                        }
                        ndelay(SPINUNIT);
                }
        }

        *no_way_out = atomic_read(&global_nwo);
        return order;
}

扫描完君主的banks后,君主cpu进入mce_end(),mce_executing增加,君主cpu等待其他仆人cpu扫描banks,直到所有的mce_executing都执行完毕(典型的cpu同步操作),此刻mce_executing==order==cpu的个数,最后由君主cpu再次确认no_way_out的值,我们可以认为no_way_out就是panic事件的个数。(此处我们要将理解为每个cpu都有一份独立的order,但是所有cpu靠原子mce_executing来做到cpu的同步。)

在int mce_end(int order)中,仆人cpu直接等待君主cpu的裁决(也就是return),然后君主cpu进入mce_reign(),这个函数就是根据所有cpu扫描的结果,做一次全面的统计,统计出global_worst,然后返回0,如果order出错,直接返回-1。

static int mce_end(int order)
{
        int ret = -1;
        u64 timeout = (u64)mca_cfg.monarch_timeout * NSEC_PER_USEC;

        if (!timeout)
                goto reset;
        if (order < 0)
                goto reset;

        atomic_inc(&mce_executing);

        if (order == 1) {

                int cpus = num_online_cpus();

                while (atomic_read(&mce_executing) <= cpus) {
                        if (mce_timed_out(&timeout))
                                goto reset;
                        ndelay(SPINUNIT);
                }

                mce_reign();
                barrier();
                ret = 0;
        } else {

                while (atomic_read(&mce_executing) != 0) {
                        if (mce_timed_out(&timeout))
                                goto reset;
                        ndelay(SPINUNIT);
                }
                return 0;
        }
reset:
        atomic_set(&global_nwo, 0);
        atomic_set(&mce_callin, 0);
        barrier();

        atomic_set(&mce_executing, 0);
        return ret;
}

退出君主区域,也就是MCA裁决当前系统应该采取哪种策略,是kill当前进程还是panic系统等,详细请看

do_machine_check() 函数分析