linux mce的一些相关内容和用户态监控的设计方法
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了linux mce的一些相关内容和用户态监控的设计方法，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5625字，纯文字阅读大概需要9分钟。
内容图文
之所以想起写一点关于mce的东西，倒不是因为遇到mce的异常了，之前遇到过很多mce的异常，内存居多，但没有好好记录下来，写这个是因为参加2018 clk南京会议的一点想法。
void __init trap_init(void)
{
。。。
#ifdef CONFIG_X86_MCE
set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK);
#endif
。。。
}
其中mce的初始化流程为：
Start_kernel-->check_bugs-->identify_boot_cpu-->identify_cpu-->mcheck_cpu_init ?/*
* Called for each booted CPU to set up machine checks.
* Must be called with preempt off:
*/
void mcheck_cpu_init(struct cpuinfo_x86 *c)
{
...
machine_check_vector = do_machine_check;----------这个函数，主要工作函数
__mcheck_cpu_init_generic();
__mcheck_cpu_init_vendor(c);
__mcheck_cpu_init_clear_banks();
__mcheck_cpu_init_timer();
....
}
?
如果为了调试mce功能，模拟硬件真的出问题，那么可以使用 mce-inject 用户态工具来实现，对应内核的函数为：
void mce_inject_log(struct mce *m)
{
mutex_lock(&mce_chrdev_read_mutex);
mce_log(m);
mutex_unlock(&mce_chrdev_read_mutex);
}
当然调试的时候，一般需要修改tolerant 值，不然有可能引起复位：
cat /sys/devices/system/machinecheck/machinecheck15/tolerant
1
[root@centos7 ~]#
[root@centos7 ~]# ls -alrt /sys/devices/system/machinecheck/machinecheck15/tolerant
-rw-r--r--. 1 root root 4096 10月 15 10:05 /sys/devices/system/machinecheck/machinecheck15/tolerant
[root@centos7 ~]# echo 2 > /sys/devices/system/machinecheck/machinecheck15/tolerant
[root@centos7 ~]# cat /sys/devices/system/machinecheck/machinecheck15/tolerant
2
/*
* Tolerant levels:
* 0: always panic on uncorrected errors, log corrected errors
* 1: panic or SIGBUS on uncorrected errors, log corrected errors
* 2: SIGBUS or log uncorrected errors (if possible), log corr. errors
* 3: never panic or SIGBUS, log all errors (for testing only)
*/
下面描述的是引发思考的过程，即mce的通知机制，为什么突然想写mce的机制，是因为其实它应用的模式可以解签，
我们把内核维护mce数据的方式视为mce数据的生产者，而用户态取该数据视为消费者的话，生产消费模型非常明显，针对这种模型，一般由两种方式来处理：
1.轮询，
2.中断通知
其中中断通知又可以细分为有守护进程，即daemon 方式，还有一种是无守护进程，直接回调一个trigger的方式。
[root@centos7 ~]# ps -ef |grep -i mce root 920 1 0 10月13 ? 00:00:00 /usr/sbin/mcelog --ignorenodev --daemon --syslog root 22125 7650 0 10:18 pts/0 00:00:00 grep --color=auto -i mce [root@centos7 ~]# cat /proc/920/stack [<ffffffff81212b95>] poll_schedule_timeout+0x55/0xb0 [<ffffffff8121411d>] do_sys_poll+0x4cd/0x580 [<ffffffff8121443e>] SyS_ppoll+0xce/0x1d0 [<ffffffff816965c9>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff
上面这个例子就是daemon方式，等待在poll中，等内核事件通知。
等待的文件名是/dev/mcelog：
[root@centos7 ~]# lsof -p 920 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mcelog 920 root cwd DIR 8,2 4096 2 / mcelog 920 root rtd DIR 8,2 4096 2 / mcelog 920 root txt REG 8,2 155952 11550884 /usr/sbin/mcelog mcelog 920 root mem REG 8,2 61752 11535695 /usr/lib64/libnss_files-2.17.so mcelog 920 root mem REG 8,2 2116736 11535677 /usr/lib64/libc-2.17.so mcelog 920 root mem REG 8,2 155064 11535670 /usr/lib64/ld-2.17.so mcelog 920 root 0u CHR 1,3 0t0 2052 /dev/null mcelog 920 root 1u CHR 1,3 0t0 2052 /dev/null mcelog 920 root 2u CHR 1,3 0t0 2052 /dev/null mcelog 920 root 3r CHR 10,227 0t0 2205 /dev/mcelog------------------这个设备 mcelog 920 root 4u unix 0xffff880035de8000 0t0 25331 /var/run/mcelog-client
那么，既然是sys文件系统，肯定有对应的read和write来提供给用户使用，read显而易见，是读取mce日志，write是干啥的？其实这里的write主要就是为了给别人注册用的，mce本身不是
调用write来写数据，它直接维护一个数据区，等别人来读，另外daemon是使用poll方法来等待的，所以自然还得实现poll方法：
static const struct file_operations mce_chrdev_ops = {
.open = mce_chrdev_open,
.release = mce_chrdev_release,
.read = mce_chrdev_read,
.write = mce_chrdev_write,
.poll = mce_chrdev_poll,
.unlocked_ioctl = mce_chrdev_ioctl,
.llseek = no_llseek,
};
poll方法的最终实现：
static unsigned int mce_chrdev_poll(struct file *file, poll_table *wait)
{
poll_wait(file, &mce_chrdev_wait, wait);----------一般阻塞在这，mce_chrdev_wait是一个等待队列
if (READ_ONCE(mcelog.next))
return POLLIN | POLLRDNORM;
if (!mce_apei_read_done && apei_check_mce())
return POLLIN | POLLRDNORM;
return 0;
}
既然有等待队列，自然而然就会想，我什么时候唤醒：
int mce_notify_irq(void)
{
/* Not more than two messages every minute */
static DEFINE_RATELIMIT_STATE(ratelimit, 60*HZ, 2);
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);
if (__ratelimit(&ratelimit))
pr_info(HW_ERR "Machine check events logged\n");
return 1;
}
return 0;
}
既然mce的来源有用户调试，以及真实检测，所以很自然唤醒也有多个来源。比如inject来唤醒和mce真实中断唤醒。
用户进程被poll唤醒之后，一般是poll_in，自然需要去读取数据，直接调用read方法就行。也就是一个简单的read和poll，就解决了监控用户态侧的大部分功能。
其他信息就不一一列了，昨天参加clk南京的会议，其中富士通一个兄弟说他们实现了NVDIMM 的一个监控，原因在于他们认为NVDIMM 是很难replace，所有有必要监控它。
它列出了一个模型，就是用户态daemon，然后设置filter到内核，内核将其监控到的event发给等待的用户进程，使用的方法正是triggers a poll event ，和目前的mce有异曲同工之妙。
假设让你设计这种监控类的东西，你会怎么设计呢？
内容总结
以上是互联网集市为您收集整理的linux mce的一些相关内容和用户态监控的设计方法全部内容，希望文章能够帮你解决linux mce的一些相关内容和用户态监控的设计方法所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。