如何linux内核报告问题

Linux Kernel BUG:soft lockup CPU#1 stuck分析

1.线上内核bug日志

kernel: Deltaway too big! 18428729675200069867 ts=18446743954022816244 write stamp =18014278822746377

kernel:------------[ cut here ]------------

kernel:WARNING: at kernel/trace/ring_buffer.c:1988 rb_reserve_next_event+0x2ce/0x370()(Not tainted)

kernel:Hardware name: ProLiant DL360 G7

kernel:Modules linked in: fuse ipv6 power_meter bnx2 sg microcode serio_raw iTCO_wdtiTCO_vendor_support hpilo hpwdt i7core_edac edac_core shpchp ext4 mbcache jbd2sd_mod crc_t10dif hpsa radeon ttm drm_kms_helper drm i2c_algo_bit i2c_coredm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]

kernel: Pid:5483, comm: master Not tainted 2.6.32-220.el6.x86_64 #1

kernel: CallTrace:

kernel:[<ffffffff81069b77>] ? warn_slowpath_common+0x87/0xc0

kernel:[<ffffffff81069bca>] ? warn_slowpath_null+0x1a/0x20

kernel:[<ffffffff810ea8ae>] ? rb_reserve_next_event+0x2ce/0x370

kernel:[<ffffffff810eab02>] ? ring_buffer_lock_reserve+0xa2/0x160

kernel:[<ffffffff810ec97c>] ? trace_buffer_lock_reserve+0x2c/0x70

kernel:[<ffffffff810ecb16>] ? trace_current_buffer_lock_reserve+0x16/0x20

kernel:[<ffffffff8107ae1e>] ? ftrace_raw_event_hrtimer_cancel+0x4e/0xb0

kernel:[<ffffffff81095e7a>] ? hrtimer_try_to_cancel+0xba/0xd0

kernel:[<ffffffff8106f634>] ? do_setitimer+0xd4/0x220

kernel:[<ffffffff8106f88a>] ? alarm_setitimer+0x3a/0x60

kernel:[<ffffffff8107c27e>] ? sys_alarm+0xe/0x20

kernel:[<ffffffff8100b308>] ? tracesys+0xd9/0xde

kernel: ---[end trace 4d0a1ef2e62cb1a2 ]---

abrt-dump-oops: Reported 1 kernel oopses to Abrt

kernel: BUG: softlockup - CPU#11 stuck for 4278190091s! [qmgr:5492]

kernel:Modules linked in: fuse ipv6 power_meter bnx2 sg microcode serio_raw iTCO_wdtiTCO_vendor_support hpilo hpwdt i7core_edac edac_core shpchp ext4 mbcache jbd2sd_mod crc_t10dif hpsa radeon ttm drm_kms_helper drm i2c_algo_bit i2c_coredm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]

kernel: CPU 11

kernel:Modules linked in: fuse ipv6 power_meter bnx2 sg microcode serio_raw iTCO_wdtiTCO_vendor_support hpilo hpwdt i7core_edac edac_core shpchp ext4 mbcache jbd2sd_mod crc_t10dif hpsa radeon ttm drm_kms_helper drm i2c_algo_bit i2c_coredm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]

kernel:

kernel: Pid:5492, comm: qmgr Tainted: G W ---------------- 2.6.32-220.el6.x86_64 #1 HPProLiant DL360 G7

kernel: RIP:0010:[<ffffffff8106f730>] [<ffffffff8106f730>]do_setitimer+0x1d0/0x220

kernel: RSP:0018:ffff88080a661ef8 EFLAGS: 00000286

kernel: RAX:ffff88080b175a08 RBX: ffff88080a661f18 RCX: 0000000000000000

kernel: RDX:0000000000000000 RSI: 0000000000000082 RDI: ffff88080c8c4c40

kernel: RBP:ffffffff8100bc0e R08: 0000000000000000 R09: 0099d7270e01c3f1

kernel: R10:0000000000000000 R11: 0000000000000246 R12: ffffffff810ef9a3

kernel: R13:ffff88080a661e88 R14: 0000000000000000 R15: ffff88080a65a544

kernel: FS:00007f10b245f7c0(0000) GS:ffff88083c4a0000(0000) knlGS:0000000000000000

kernel: CS:0010 DS: 0000 ES: 0000 CR0: 000000008005003b

kernel: CR2:00007ff955977380 CR3: 000000100a80b000 CR4: 00000000000006e0

kernel: DR0:0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

kernel: DR3:0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

kernel:Process qmgr (pid: 5492, threadinfo ffff88080a660000, task ffff880809577500)

kernel: Stack:

kernel:00007f10b323def0 00007f10b248ead0 00007f10b26d0f78 00007f10b248ede0

kernel:<0>ffff88080a661f68 ffffffff8106f88a 0000000000000000 0000000000000000

kernel:<0>000000000000014c 00000000000f423d 0000000000000000 0000000000000000

kernel: CallTrace:

kernel:[<ffffffff8106f88a>] ? alarm_setitimer+0x3a/0x60

kernel:[<ffffffff8107c27e>] ? sys_alarm+0xe/0x20

kernel:[<ffffffff8100b308>] ? tracesys+0xd9/0xde

kernel: Code:89 ef e8 74 66 02 00 83 3d 15 69 b5 00 00 75 37 49 8b 84 24 70 07 00 00 48 0508 08 00 00 66 ff 00 66 66 90 fb 66 0f 1f 44 00 00 <31>c0 e9 64 fe ff ff49 8b 84 24 68 07 00 00 48 c7 80 d0 00 00

kernel: CallTrace:

kernel:[<ffffffff8106f769>] ? do_setitimer+0x209/0x220

kernel:[<ffffffff8106f88a>] ? alarm_setitimer+0x3a/0x60

kernel:[<ffffffff8107c27e>] ? sys_alarm+0xe/0x20

kernel:[<ffffffff8100b308>] ? tracesys+0xd9/0xde

abrt-dump-oops: Reported 1 kernel oopses to Abrt

2.内核软死锁（soft lockup）bug原因分析

Soft lockup名称解释：所谓，soft lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。

Linux内核对于每一个cpu都有一个监控进程，在技术界这个叫做watchdog（看门狗）。通过ps –ef | grep watchdog能够看见，进程名称大概是watchdog/X（数字：cpu逻辑编号1/2/3/4之类的）。这个进程或者线程每一秒钟运行一次，否则会睡眠和待机。这个进程运行会收集每一个cpu运行时使用数据的时间并且存放到属于每个cpu自己的内核数据结构。在内核中有很多特定的中断函数。这些中断函数会调用soft lockup计数，他会使用当前的时间戳与特定（对应的）cpu的内核数据结构中保存的时间对比，如果发现当前的时间戳比对应cpu保存的时间大于设定的阀值，他就假设监测进程或看门狗线程在一个相当可观的时间还没有执。Cpu软锁为什么会产生，是怎么产生的？如果linux内核是经过精心设计安排的CPU调度访问，那么怎么会产生cpu软死锁？那么只能说由于用户开发的或者第三方软件引入，看我们服务器内核panic的原因就是qmgr进程引起。因为每一个无限的循环都会一直有一个cpu的执行流程（qmgr进程示一个后台邮件的消息队列服务进程），并且拥有一定的优先级。Cpu调度器调度一个驱动程序来运行，如果这个驱动程序有问题并且没有被检测到，那么这个驱动程序将会暂用cpu的很长时间。根据前面的描述，看门狗进程会抓住（catch）这一点并且抛出一个软死锁（soft lockup）错误。软死锁会挂起cpu使你的系统不可用。

如果是用户空间的进程或线程引起的问题backtrace是不会有内容的，如果内核线程那么在soft lockup消息中会显示出backtrace信息。

3.根据linux内核源码分析错误

根据我们第一部分内核抛出的错误信息和call trace（linux内核的跟踪子系统）来分析产生的具体原因。

首先根据我们的centos版本安装相应的linux内核源码，具体步骤如下：

（1）下载源码的rpm包kernel-2.6.32-220.17.1.el6.src.rpm

（2）安装相应的依赖库，命令：yuminstall rpm-build redhat-rpm-config asciidoc newt-devel

（3）安装源码包：rpm -ikernel-2.6.32-220.17.1.el6.src.rpm

（4）进入建立源码的目录：cd~/rpmbuild/SPECS

（5）建立生成源码目录：rpmbuild-bp --target=`uname -m` kernel.spec

下面开始真正的根据内核bug日志分析源码：

（1）第一阶段内核错误日志分析（时间在Dec 4 14:03:34这个阶段的日志输出代码分析，其实这部分代码不会导致cpu软死锁，主要是第二阶段错误日志显示导致cpu软死锁）

我们首先通过日志定位到相关源代码：看下面日志：Dec 4 14:03:34 BP-YZH-1-xxxx kernel: WARNING: atkernel/trace/ring_buffer.c:1988 rb_reserve_next_event+0x2ce/0x370() (Not tainted)

根据日志内容我们可以很容易的定位到kernel/trace/ring_buffer.c这个文件的1988行代码如下：WARN_ON(1)。

先简单解释一下WARN_ON的作用：WARN_ON只是打印出当前栈信息，不会panic。所以会看到后面有一大堆的栈信息。这个宏定义如下：

#ifndef WARN_ON

#defineWARN_ON(condition) ({\

int __ret_warn_on = !!(condition)\

if (unlikely(__ret_warn_on)) \

__WARN() \

unlikely(__ret_warn_on) \

})

#endif

这个宏很简单保证传递进来的条件值为0或者1（两次逻辑非 *** 作的结果），然后使用分支预测技术（保证执行概率大的分支紧邻上面的指令）判断是否需要调用__WARN()宏定义。如果满足条件执行了__WARN()宏定义也接着执行一条空指令。上面调用WARN_ON宏是传递的1，所以会执行__WARN()。下面继续看一下__WARN()宏定义如下：

#define __WARN()warn_slowpath_null(__FILE__,__LINE__)

从接下来的call trace信息中我们也确实发现调用了warn_slowpath_null这个函数。通过在linux内核源代码中搜索这个函数的实现，发现在panic.c（内核恐慌时的相关功能实现）中实现如下：

voidwarn_slowpath_null(const char *file, int line)

{

warn_slowpath_common(file, line,__builtin_return_address(0),

TAINT_WARN, NULL)

}

EXPORT_SYMBOL(warn_slowpath_null)//都出这个符号，让其他模块可以使用这个函数

同样的我们看到了warn_slowpath_common这个函数，而在call trace当中这个函数在warn_slowpath_null函数之前打印出来，再次印证了这个流程是正确的。同样在panic.c这个文件中我发现了warn_slowpath_common这个函数的实现如下：

static voidwarn_slowpath_common(const char *file, int line, void *caller,

unsigned taint, struct slowpath_args *args)

{

const char *board

printk(KERN_WARNING "------------[ cut here]------------\n")

printk(KERN_WARNING "WARNING: at %s:%d %pS()(%s)\n",

file, line, caller, print_tainted())

board = dmi_get_system_info(DMI_PRODUCT_NAME)//得到dmi系统信息

if (board)

printk(KERN_WARNING "Hardware name:%s\n", board)//通过我们的日志信息可以发现我们硬件名称是ProLiant DL360 G7

if (args)

vprintk(args->fmt, args->args)

print_modules()//打印系统模块信息

dump_stack()//dump信息输出（call trace开始）

print_oops_end_marker()//打印oops结束

add_taint(taint)

}

分析这个函数的实现不难发现我们的很多日志信息从这里开始输出，包括打印一些系统信息，就不继续深入分析了（请看代码注释，里面调用相关函数打印对应信息，通过我分析这些函数的实现和我们的日志信息完全能够对应，其中dump_stack是与cpu体系结构相关的，我们的服务器应该是属于x86体系）。这里在继续分析一下dump_stack函数的实现，因为这个是与cpu体系结构相关的，而且这个函数直接反应出导致内核panic的相关进程。这个函数实现如下：

/*

* The architecture-independent dump_stackgenerator

*/

void dump_stack(void)

{

unsigned long stack

printk("Pid: %d, comm: %.20s %s %s %.*s\n",

current->pid, current->comm,print_tainted(),

init_utsname()->release,

(int

天重点对linux网络数据包的处理做下分析，但是并不关系到上层协议，仅仅到链路层。之前转载过一篇文章，对NAPI做了比较详尽的分析，本文结合Linux内核源代码，对当前网络数据包的处理进行梳理。根据NAPI的处理特性，对设备提出一定的要求1、设备需要有足够的缓冲区，保存多个数据分组2、可以禁用当前设备中断，然而不影响其他的 *** 作。当前大部分的设备都支持NAPI，但是为了对之前的保持兼容，内核还是对之前中断方式提供了兼容。我们先看下NAPI具体的处理方式。我们都知道中断分为中断上半部和下半部，上半部完成的任务很是简单，仅仅负责把数据保存下来；而下半部负责具体的处理。为了处理下半部，每个CPU有维护一个softnet_data结构。我们不对此结构做详细介绍，仅仅描述和NAPI相关的部分。结构中有一个poll_list字段，连接所有的轮询设备。还 维护了两个队列input_pkt_queue和process_queue。这两个用户传统不支持NAPI方式的处理。前者由中断上半部的处理函数吧数据包入队，在具体的处理时，使用后者做中转，相当于前者负责接收，后者负责处理。最后是一个napi_struct的backlog，代表一个虚拟设备供轮询使用。在支持NAPI的设备下，每个设备具备一个缓冲队列，存放到来数据。每个设备对应一个napi_struct结构，该结构代表该设备存放在poll_list中被轮询。而设备还需要提供一个poll函数，在设备被轮询到后，会调用poll函数对数据进行处理。基本逻辑就是这样，下面看下具体流程。中断上半部：非NAPI：非NAPI对应的上半部函数为netif_rx，位于Dev.,c中int netif_rx(struct sk_buff *skb){int ret/* if netpoll wants it, pretend we never saw it *//*如果是net_poll想要的，则不作处理*/if (netpoll_rx(skb))return NET_RX_DROP/*检查时间戳*/net_timestamp_check(netdev_tstamp_prequeue, skb)trace_netif_rx(skb)#ifdef CONFIG_RPSif (static_key_false(&rps_needed)) {struct rps_dev_flow voidflow, *rflow = &voidflowint cpu/*禁用抢占*/preempt_disable()rcu_read_lock()cpu = get_rps_cpu(skb->dev, skb, &rflow)if (cpu <0)cpu = smp_processor_id()/*把数据入队*/ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail)rcu_read_unlock()preempt_enable()} else#endif{ unsigned int qtailret = enqueue_to_backlog(skb, get_cpu(), &qtail)put_cpu()}return ret}中间RPS暂时不关心，这里直接调用enqueue_to_backlog放入CPU的全局队列input_pkt_queuestatic int enqueue_to_backlog(struct sk_buff *skb, int cpu,unsigned int *qtail){struct softnet_data *sdunsigned long flags/*获取cpu相关的softnet_data变量*/sd = &per_cpu(softnet_data, cpu)/*关中断*/local_irq_save(flags)rps_lock(sd)/*如果input_pkt_queue的长度小于最大限制，则符合条件*/if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) {/*如果input_pkt_queue不为空，说明虚拟设备已经得到调度，此时仅仅把数据加入input_pkt_queue队列即可*/if (skb_queue_len(&sd->input_pkt_queue)) {enqueue:__skb_queue_tail(&sd->input_pkt_queue, skb)input_queue_tail_incr_save(sd, qtail)rps_unlock(sd)local_irq_restore(flags)return NET_RX_SUCCESS}/* Schedule NAPI for backlog device* We can use non atomic operation since we own the queue lock*//*否则需要调度backlog 即虚拟设备，然后再入队。napi_struct结构中的state字段如果标记了NAPI_STATE_SCHED,则表明该设备已经在调度，不需要再次调度*/if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {if (!rps_ipi_queued(sd))____napi_schedule(sd, &sd->backlog)}goto enqueue}/*到这里缓冲区已经不足了，必须丢弃*/sd->dropped++rps_unlock(sd)local_irq_restore(flags)atomic_long_inc(&skb->dev->rx_dropped)kfree_skb(skb)return NET_RX_DROP}该函数逻辑也比较简单，主要注意的是设备必须先添加调度然后才能接受数据，添加调度调用了____napi_schedule函数，该函数把设备对应的napi_struct结构插入到softnet_data的poll_list链表尾部，然后唤醒软中断，这样在下次软中断得到处理时，中断下半部就会得到处理。不妨看下源码static inline void ____napi_schedule(struct softnet_data *sd,struct napi_struct *napi){list_add_tail(&napi->poll_list, &sd->poll_list)__raise_softirq_irqoff(NET_RX_SOFTIRQ)}NAPI方式NAPI的方式相对于非NAPI要简单许多，看下e100网卡的中断处理函数e100_intr，核心部分if (likely(napi_schedule_prep(&nic->napi))) {e100_disable_irq(nic)//屏蔽当前中断__napi_schedule(&nic->napi)//把设备加入到轮训队列}if条件检查当前设备是否 可被调度，主要检查两个方面：1、是否已经在调度 2、是否禁止了napi pending.如果符合条件，就关闭当前设备的中断，调用__napi_schedule函数把设备假如到轮训列表，从而开启轮询模式。分析：结合上面两种方式，还是可以发现两种方式的异同。其中softnet_data作为主导结构，在NAPI的处理方式下，主要维护轮询链表。NAPI设备均对应一个napi_struct结构，添加到链表中；非NAPI没有对应的napi_struct结构，为了使用NAPI的处理流程，使用了softnet_data结构中的back_log作为一个虚拟设备添加到轮询链表。同时由于非NAPI设备没有各自的接收队列，所以利用了softnet_data结构的input_pkt_queue作为全局的接收队列。这样就处理而言，可以和NAPI的设备进行兼容。但是还有一个重要区别，在NAPI的方式下，首次数据包的接收使用中断的方式，而后续的数据包就会使用轮询处理了；而非NAPI每次都是通过中断通知。下半部：下半部的处理函数，之前提到，网络数据包的接发对应两个不同的软中断，接收软中断NET_RX_SOFTIRQ的处理函数对应net_rx_actionstatic void net_rx_action(struct softirq_action *h){struct softnet_data *sd = &__get_cpu_var(softnet_data)unsigned long time_limit = jiffies + 2int budget = netdev_budgetvoid *havelocal_irq_disable()/*遍历轮询表*/while (!list_empty(&sd->poll_list)) {struct napi_struct *nint work, weight/* If softirq window is exhuasted then punt.* Allow this to run for 2 jiffies since which will allow* an average latency of 1.5/HZ.*//*如果开支用完了或者时间用完了*/if (unlikely(budget <= 0 || time_after_eq(jiffies, time_limit)))goto softnet_breaklocal_irq_enable()/* Even though interrupts have been re-enabled, this* access is safe because interrupts can only add new* entries to the tail of this list, and only ->poll()* calls can remove this head entry from the list.*//*获取链表中首个设备*/n = list_first_entry(&sd->poll_list, struct napi_struct, poll_list)have = netpoll_poll_lock(n)weight = n->weight/* This NAPI_STATE_SCHED test is for avoiding a race* with netpoll's poll_napi(). Only the entity which* obtains the lock and sees NAPI_STATE_SCHED set will* actually make the ->poll() call. Therefore we avoid* accidentally calling ->poll() when NAPI is not scheduled.*/work = 0/*如果被设备已经被调度，则调用其处理函数poll函数*/if (test_bit(NAPI_STATE_SCHED, &n->state)) {work = n->poll(n, weight)//后面weight指定了一个额度trace_napi_poll(n)}WARN_ON_ONCE(work >weight)/*总额度递减*/budget -= worklocal_irq_disable()/* Drivers must not modify the NAPI state if they* consume the entire weight. In such cases this code* still "owns" the NAPI instance and therefore can* move the instance around on the list at-will.*//*如果work=weight的话。任务就完成了，把设备从轮询链表删除*/if (unlikely(work == weight)) {if (unlikely(napi_disable_pending(n))) {local_irq_enable()napi_complete(n)local_irq_disable()} else {if (n->gro_list) {/* flush too old packets* If HZ <1000, flush all packets.*/local_irq_enable()napi_gro_flush(n, HZ >= 1000)local_irq_disable()}/*每次处理完就把设备移动到列表尾部*/list_move_tail(&n->poll_list, &sd->poll_list)}}netpoll_poll_unlock(have)}out:net_rps_action_and_irq_enable(sd)#ifdef CONFIG_NET_DMA/** There may not be any more sk_buffs coming right now, so push* any pending DMA copies to hardware*/dma_issue_pending_all()#endifreturnsoftnet_break:sd->time_squeeze++__raise_softirq_irqoff(NET_RX_SOFTIRQ)goto out}这里有处理方式比较直观，直接遍历poll_list链表，处理之前设置了两个限制：budget和time_limit。前者限制本次处理数据包的总量，后者限制本次处理总时间。只有二者均有剩余的情况下，才会继续处理。处理期间同样是开中断的，每次总是从链表表头取设备进行处理，如果设备被调度，其实就是检查NAPI_STATE_SCHED位，则调用 napi_struct的poll函数，处理结束如果没有处理完，则把设备移动到链表尾部，否则从链表删除。NAPI设备对应的poll函数会同样会调用__netif_receive_skb函数上传协议栈，这里就不做分析了，感兴趣可以参考e100的poll函数e100_poll。而非NAPI对应poll函数为process_backlog。static int process_backlog(struct napi_struct *napi, int quota){int work = 0struct softnet_data *sd = container_of(napi, struct softnet_data, backlog)#ifdef CONFIG_RPS/* Check if we have pending ipi, its better to send them now,* not waiting net_rx_action() end.*/if (sd->rps_ipi_list) {local_irq_disable()net_rps_action_and_irq_enable(sd)}#endifnapi->weight = weight_plocal_irq_disable()while (work <quota) {struct sk_buff *skbunsigned int qlen/*涉及到两个队列process_queue和input_pkt_queue，数据包到来时首先填充input_pkt_queue，而在处理时从process_queue中取，根据这个逻辑，首次处理process_queue必定为空，检查input_pkt_queue如果input_pkt_queue不为空，则把其中的数据包迁移到process_queue中，然后继续处理，减少锁冲突。*/while ((skb = __skb_dequeue(&sd->process_queue))) {local_irq_enable()/*进入协议栈*/__netif_receive_skb(skb)local_irq_disable()input_queue_head_incr(sd)if (++work >= quota) {local_irq_enable()return work}}rps_lock(sd)qlen = skb_queue_len(&sd->input_pkt_queue)if (qlen)skb_queue_splice_tail_init(&sd->input_pkt_queue,&sd->process_queue)if (qlen <quota - work) {/** Inline a custom version of __napi_complete().* only current cpu owns and manipulates this napi,* and NAPI_STATE_SCHED is the only possible flag set on backlog.* we can use a plain write instead of clear_bit(),* and we dont need an smp_mb() memory barrier.*/list_del(&napi->poll_list)napi->state = 0quota = work + qlen}rps_unlock(sd)}local_irq_enable()return work}函数还是比较简单的，需要注意的每次处理都携带一个配额，即本次只能处理quota个数据包，如果超额了，即使没处理完也要返回，这是为了保证处理器的公平使用。处理在一个while循环中完成，循环条件正是work <quota，首先会从process_queue中取出skb,调用__netif_receive_skb上传给协议栈，然后增加work。当work即将大于quota时，即++work >= quota时，就要返回。当work还有剩余额度，但是process_queue中数据处理完了，就需要检查input_pkt_queue，因为在具体处理期间是开中断的，那么期间就有可能有新的数据包到来，如果input_pkt_queue不为空，则调用skb_queue_splice_tail_init函数把数据包迁移到process_queue。如果剩余额度足够处理完这些数据包，那么就把虚拟设备移除轮询队列。这里有些疑惑就是最后为何要增加额度，剩下的额度已经足够处理这些数据了呀？根据此流程不难发现，其实执行的是在两个队列之间移动数据包，然后再做处理。

Linux的内核源代码可以从很多途径得到。一般来讲，在安装的linux系统下，/usr/src/linux目录下的东西就是内核源代码。

对于源代码的阅读，要想比较顺利，事先最好对源代码的知识背景有一定的了解。对于linux内核源代码来讲，我认为，基本要求是:1、 *** 作系统的基本知识2、对C语言比较熟悉，最好要有汇编语言的知识和GNU C对标准C的扩展的知识的了解。另外在阅读之前，还应该知道Linux内核源代码的整体分布情况。我们知道现代的 *** 作系统一般由进程管理、内存管理、文件系统、驱动程序、网络等组成。看一下Linux内核源代码就可看出，各个目录大致对应了这些方面。Linux内核源代码的组成如下(假设相对于linux目录):

arch 这个子目录包含了此核心源代码所支持的硬件体系结构相关的核心代码。如对于X86平台就是i386。

include 这个目录包括了核心的大多数include文件。另外对于每种支持的体系结构分别有一个子目录。

init 此目录包含核心启动代码。

mm 此目录包含了所有的内存管理代码。与具体硬件体系结构相关的内存管理代码位于arch/*/mm目录下，如对应于X86的就是arch/i386/mm/fault.c 。

drivers 系统中所有的设备驱动都位于此目录中。它又进一步划分成几类设备驱动，每一种也有对应的子目录，如声卡的驱动对应于drivers/sound。

ipc 此目录包含了核心的进程间通讯代码。

modules 此目录包含已建好可动态加载的模块。

fs Linux支持的文件系统代码。不同的文件系统有不同的子目录对应，如ext2文件系统对应的就是ext2子目录。

kernel 主要核心代码。同时与处理器结构相关代码都放在arch/*/kernel目录下。

net 核心的网络部分代码。里面的每个子目录对应于网络的一个方面。

lib 此目录包含了核心的库代码。与处理器结构相关库代码被放在arch/*/lib/目录下。

scripts此目录包含用于配置核心的脚本文件。

Documentation 此目录是一些文档，起参考作用。

俗话说:“工欲善其事，必先利其器”。 阅读象Linux核心代码这样的复杂程序令人望而生畏。它象一个越滚越大的雪球，阅读核心某个部分经常要用到好几个其他的相关文件，不久你将会忘记你原来在干什么。所以没有一个好的工具是不行的。由于大部分爱好者对于Window平台比较熟悉，并且还是常用Window系列平台，所以在此我介绍一个Window下的一个工具软件:Source Insight。这是一个有30天免费期的软件，可以从www.sourcedyn.com下载。安装非常简单，和别的安装一样，双击安装文件名，然后按提示进行就可以了。安装完成后，就可启动该程序。这个软件使用起来非常简单，是一个阅读源代码的好工具。它的使用简单介绍如下:先选择Project菜单下的new，新建一个工程，输入工程名，接着要求你把欲读的源代码加入(可以整个目录加)后，该软件就分析你所加的源代码。分析完后，就可以进行阅读了。对于打开的阅读文件，如果想看某一变量的定义，先把光标定位于该变量，然后点击工具条上的相应选项，该变量的定义就显示出来。对于函数的定义与实现也可以同样 *** 作。别的功能在这里就不说了，有兴趣的朋友可以装一个Source Insight，那样你阅读源代码的效率会有很大提高的。怎么样，试试吧!

---