Linux内核中的klist分析
分析的内核版本照样是2.6.38.5。
Linux内核中的klist是在神级的双向链表上扩展而形成的。先给出一个图。
很清晰也很简单。
先说表头:
K_lock:是一把锁,用来锁表的。这个就不多啰嗦了。
k_list:双向链表,用来联系各节点及链表头。
get、put:两个函数指针,是用来操作链表中的节点接口。
再说节点:
n_klist是一个空指针,随便用来指啥,但在我们的klist原语中是用来指向链表头的。另外其最低位用来做标志位。
n_node:双向链表,用来联系各节点及链表头。
n_ref:引用计数。
接下来我们来分析一下我们感兴趣的几个东西。
首先是
WARN_ON(condition)
BUG_ON(condition)
这两个宏。
经过分析后其在默认配置中被定义为:
#ifndef HAVE_ARCH_BUG_ON
#define BUG_ON(condition) do { if (condition) ; } while(0)
#endif
#ifndef HAVE_ARCH_WARN_ON
#define WARN_ON(condition) ({ /
int __ret_warn_on = !!(condition); /
unlikely(__ret_warn_on); /
})
#endif
可以认为这个宏是没用的。因为在klist中并没有对这个返回值作判断。
另外有的朋友可能会说linux内核中怎么会有这样的垃圾代码,会造成不必要的运行开销。其实我想说,你太低估linux内核开发者的水平了,这是一份国际顶尖级的高手写出来的代码,他们对编译器,操作系统,CPU体系结构的认识程度远不是你我所能达到的。说了这么多,让我们来一起仔细领会这些大牛的深厚功力。
我先写了个小例子程序:
#include "asm-generic/bug.h"
int main()
{
int aa = 0x0;
int condition = 0x77;
WARN_ON(condition);
aa = 0x88;
return 0;
}
然后利用命令:
gcc test.c -E -I/opt/kernel/linux-2.6.38/linux-2.6.38.5/include/ > test.txt
再vi test.txt
我们可以看到有如下内容:
# 1 "test.c"
# 1 "
# 1 "
# 1 "test.c"
# 1 "/opt/kernel/linux-2.6.38/linux-2.6.38.5/include/asm-generic/bug.h" 1
# 1 "/opt/kernel/linux-2.6.38/linux-2.6.38.5/include/linux/compiler.h" 1
# 5 "/opt/kernel/linux-2.6.38/linux-2.6.38.5/include/asm-generic/bug.h" 2
# 2 "test.c" 2
int main()
{
int aa = 0x0;
int condition = 0x77;
({ int __ret_warn_on = !!(condition); unlikely(__ret_warn_on); });
aa = 0x88;
return 0;
}
通过编译预处理,我们可以看到宏确实被展开了。
接下来我们反汇编这段代码:
我们输入命令:
gcc test.c -c -I/opt/kernel/linux-2.6.38/linux-2.6.38.5/include/ -o test.o –g
然后再gdb test.o
再:disassemble main 得到:
0x00000000
0x00000004
0x00000007
0x0000000a
0x0000000b
0x0000000d
0x0000000e
0x00000011
0x00000018
0x0000001f
0x00000023
0x00000026
0x00000029
0x0000002c
0x0000002f
0x00000032
0x00000037
0x0000003e
0x00000043
0x00000046
0x00000047
0x00000048
多了很多代码。这linux内核的作者这么蠢?
我们再看看inux内核根makefile下面的几行:
HOSTCC = gcc
HOSTCXX = g++
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-p
ointer
HOSTCXXFLAGS = -O2
加了个O2!
Ok,我们也加个O2。
wwhs_klist]# gcc test.c -c -I/opt/kernel/linux-2.6.38/linux-2.6.38.5/include/ -o test.o -g –O2(后面分别用优化选项-O、-O1、-Os在我们关注的这个地方表现出来的效果是相同的)。
gdb test.o
disassemble main
得到:
0x00000000
0x00000004
0x00000007
0x0000000a
0x0000000b
0x0000000d
0x0000000e
0x00000011
0x00000018
0x0000001d
0x00000020
0x00000022
0x00000023
0x00000024
0x00000027
哈哈。看到了吧,全都被优化掉了,所以加的这些东西对我们的性能不会造成任何影响!
我晕。好像偏题了,不好意思。
不过发现klist除了这个以外没有别的值得讲的。
值得一提的是:
个人觉得klist中有些函数的命名不是非常的好,容易让人误解,经过思考后发现klist的命名虽然是有规律的,但是说实话,确实可以做得更好。
另外有一个值得一讲的是:
void klist_remove(struct klist_node *n)
{
struct klist_waiter waiter;
waiter.node = n;
waiter.process = current;
waiter.woken = 0;
spin_lock(&klist_remove_lock);
list_add(&waiter.list, &klist_remove_waiters);
spin_unlock(&klist_remove_lock);
klist_del(n);
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
if (waiter.woken)
break;
schedule();
}
__set_current_state(TASK_RUNNING);
}
我们分析一下:
struct klist_waiter waiter;
waiter.node = n;
waiter.process = current; //这是个任务结构体,把当前任务结构体保存起来
waiter.woken = 0; //这是用于唤醒任务的标记
spin_lock(&klist_remove_lock);
list_add(&waiter.list, &klist_remove_waiters); //将waiter.list链入klist_remove_waiters
spin_unlock(&klist_remove_lock);
接下来:
void klist_del(struct klist_node *n)
{
klist_put(n, true);
}
static void klist_put(struct klist_node *n, bool kill)
{
struct klist *k = knode_klist(n);
void (*put)(struct klist_node *) = k->put;
spin_lock(&k->k_lock);
if (kill)
knode_kill(n);
if (!klist_dec_and_del(n))
put = NULL;
spin_unlock(&k->k_lock);
if (put)
put(n);
}
重点在:
static int klist_dec_and_del(struct klist_node *n)
{
return kref_put(&n->n_ref, klist_release);
}
int kref_put(struct kref *kref, void (*release)(struct kref *kref))
{
WARN_ON(release == NULL);
WARN_ON(release == (void (*)(struct kref *))kfree);
if (atomic_dec_and_test(&kref->refcount)) { //一定要把引用计数消耗完才能调用release()
release(kref);
return 1;
}
return 0;
}
重点在:
static void klist_release(struct kref *kref)
{
struct klist_waiter *waiter, *tmp;
struct klist_node *n = container_of(kref, struct klist_node, n_ref);
WARN_ON(!knode_dead(n));
list_del(&n->n_node);
spin_lock(&klist_remove_lock);
list_for_each_entry_safe(waiter, tmp, &klist_remove_waiters, list) {
if (waiter->node != n)
continue;
waiter->woken = 1;
mb();
wake_up_process(waiter->process);
list_del(&waiter->list);
}
spin_unlock(&klist_remove_lock);
knode_set_klist(n, NULL);
}
到这里我们可以看到:
waiter->woken = 1;
mb();
标记也打了,内存屏障也设了(多任务的时候用这个玩意可以把寄存器的值回写到内存,防止编译器优化产生BUG,其最主要的函数是编译器内置的,有兴趣的同志可以自行学习一下)。接下就是用wake_up_process(waiter->process)要换醒我们之前设置好的进程了。
回到我们之前的地方:
void klist_remove(struct klist_node *n)
{
struct klist_waiter waiter;
waiter.node = n;
waiter.process = current;
waiter.woken = 0;
spin_lock(&klist_remove_lock);
list_add(&waiter.list, &klist_remove_waiters);
spin_unlock(&klist_remove_lock);
klist_del(n);
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
if (waiter.woken)
break;
schedule();
}
__set_current_state(TASK_RUNNING);
}
跳进循环:
用set_current_state(TASK_UNINTERRUPTIBLE) 设置当前任务为不可中断状态,
接下来就是判断我们之前打的标记了,所以前面的标记如果没打的话,就会继续调用schedule()来切换任务,只有当标记被置了1(也就是说只有引用计数被消耗完了),才会跳出循环。这是设计的好的地方,可以确保在多任务环境下,所有调用者都有机会释放,但也是容易出问题的地方,如果不小心控制引用计数,一个死循环就这么产生了。
接下来再用__set_current_state(TASK_RUNNING)将任务状态切成正在行运状态。