如何使用ftrace实时获取系统中的spinlock快照
接上文：
https://blog.csdn.net/dog250/article/details/108349046
在这篇文章中，我给出了一个拯救panic的方法，其目的更多的是恶作剧性质。但仍然有不足，请看下面代码段中的注释：
void stub_panic(const char *fmt, ...)
{
...
local_irq_enable();
// 这个时候如果current持有自旋锁，那可怎么办？？？
printk("rq:%d %d\n", preempt_count(), irqs_disabled());
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule();
如果持有自旋锁的task被schedule出去了，由于该task不会再回来了，那么只要另一个task抢锁，系统立马就会死锁。
需求自然就出来了，我能不能在调用schedule之前遍历系统当前所有自旋锁的持锁情况，将自己持有的自旋锁给unlock了呢？
有需求就有方案。当然可以。
大秀hook手艺的时候来了。虽然作为手艺人用手工的方式拼接指令可以实现任何功能，但现在的目标已经不仅仅是秀手艺了，而是实现上述的需求，所以我尽量先使用stap/kprobe，ftrace这些场面还不是太宏大的工具。
需求图示如下：
很显然，直接的思路就是使用kretprobe了，于是我写出了如下的代码：
#include 请忽略具体的spinlock统计逻辑，现在仅仅关注框架，我敢说，这个玩法对于一般的wrap函数，简直就是模版：
- 这个框架可以实现几乎一切wrap函数。
所谓的wrap函数其实很简单：
my_function(void *param)
{
pre_process(param);
orig_function(param);
post_process(param);
}
kretprobe的跳转逻辑如下：
然而，它偏偏不能用于_raw_spin_lock/_raw_spin_unlock的wrap！因为会死锁！
- kprobe/kretprobe框架内部使用spinlock来进行同步，在ret_handler执行的时候，它已经持有了该spinlock，而属于kretprobe的ret_handler本身同样也需要该spinlock，因此会死锁。
啦啦啦，这就是为什么我喜欢纯手工活儿的原因了，因为它可控啊！
来来来，试试ftrace，相比于kretprobe而言，它更简单，我觉得它应该没问题，如果再不行，就只能上纯手工艺了。
先来试试框架，下面是一个什么都不做的框架代码：
#include 当我加载这个模块的时候，系统像什么都没有发生一样平静，而我用crash看_raw_spin_lock/_raw_spin_unlock的时候，显然它们已经被hook了，这意味着，wrap起作用了。
下图展示了ftrace实现wrap的原理：
这个已经和手工做法几乎无异了。可以拿这个ftrace和上面的kretprobe对比一下，感受一下雷同和差异：
- kretprobe一般也是用来probe函数而不是指令，这一点和ftrace一致。
- ftrace机制上更加直接，而kretprobe则更加trick一点。
- 如果要完成一个业务需求，我选择用ftrace，如果要表演，我会照抄一套kretprobe的机制，如果纯自己玩，我选择纯手工艺。
好了，现在把spinlock统计逻辑放进去，代码简单，自己感受：
#include 值得注意的是，wrap函数中不能再调用任何会使用spinlock的函数(避免循环嵌套)，因此一开始我决定自己用原子原语实现一个自己的自旋锁：
void lock(unsigned long *lock)
{
while (test_and_set_bit(0, lock));
}
void unlock(unsigned long *lock)
{
*lock = 0; // 比clear_bit更帅
}
然而系统很快就卡死了：
- 把系统所有的spinlock操作全部在此处唯一的自旋锁上串行化，不卡死才怪！
于是，只能退而求其次，采用宽松的约束了：
- 实在没有slot了，就不统计该次记录了。
所以，我这个spinlock快照记录机制， 它是不准的。
以上就是一个简单的spinlock快照机制的代码和说明，它可以展示：
- 当前系统中都有哪些task在争抢哪一把spinlock。
- 当前系统中某个spinlock被哪一个task所持有。
这个机制有什么用呢？
回到本文的开头，如果想让panic被schedule出去而不是宕机，我在担心current持有锁怎么办，我希望有一个办法让我知道current是否持有spinlock以及持有了哪些spinlock，然后将它们unlock。
现在有办法了：
// 通过lock_detect模块init函数中printk出来的bitmap地址来设置。
unsigned long pbitmap;
module_param(pbitmap, ulong, 0644);
// 通过lock_detect模块init函数中printk出来的plane地址来设置。
unsigned long pplane;
module_param(pplane, ulong, 0644);
void stub_panic(const char *fmt, ...)
{
int i;
unsigned long *bitmap = (unsigned long *)pbitmap;
struct lock_owner *plane = (struct lock_owner *)pplane;
// 循环遍历所有当前系统当事的spinlock，解锁current所持有的spinlock。
for (i = 0; i < 32768; i++) {
if (test_bit(i, bitmap) &&
plane[i].owner == current &&
plane[i].lock_owner == current &&
plane[i].lock &&
plane[i].idx == i) {
printk("lock hold:%p %s %d\n",
plane[i].lock,
plane[i].lock_owner?plane[i].lock_owner->comm:"aabb",
plane[i].lock_owner?plane[i].lock_owner->pid:-1);
spin_unlock(plane[i].lock);
}
}
if (preempt_count())
return;
local_irq_enable();
// 安全地退场！！
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule();
}
...
强调一点，本文介绍的把戏无法揪出所有的spinlock状态，因为Linux内核spinlock的lock/unlock操作并非_raw_spin_lock/_raw_spin_unlock入口的，比如spin_lock_irqsave/spin_unlock_irqrestore就不使用_raw_spin_lock/_raw_spin_unlock入口，它们有自己的入口。因此你需要把所有这些入口都给ftrace hook了，才能全咯。
不过，这仅仅是一个把戏，何必去留这么多TODO，权当玩吧。
浙江温州皮鞋湿，下雨进水不会胖。