[转贴]对内核重入的理解

雪中独行

原文出自：http://www.linuxforum.net
作者：lucian_yao
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

下面是我的理解，不知道对不对。

首先要界定一个范围(代码段，函数)然后才可以讨论重入。

比如以函数A,B分别为一个范围。在运行A的时候发生中断，调用B,B运行完了又返回A,这个时候称B进入A.

如果A=B,那么称A重入A,或者可以说有两个A的实例在运行。

重入导致的问题主要就是由于这两个A可以会几乎同时访问一些堆中的变量而出现不一致。
解决这个问题的办法有几个:

干脆不允许某个函数(某段代码)重入，也就是如果A运行，当发生中断的时候，调用A，发现已经有A运行了，则返回，不再运行这个新的A.bottom half采用这个办法。

或者对一些临界区上锁。

或者干脆关中断。

内核的重入，首先界定的范围就是整个处于内核级的代码段。

因此，内核的重入可以说是经常发生的，比如中断发生时。

内核的重入有两种情况：

1与进程无关的中断发生时，CPU已经在内核中运行，也就是中断嵌套。一般内核会做一定的保护，比如关中断，锁临界区等。但是这种中断有一个特点，就是先进后出的栈的模式，因此，用一个栈足矣。

2与进程相关的切换。如果总是在内核返回到用户级代码段时才切换，那么这个意义上的重入就不存在，用一个内核栈就可以了。还有一种可能是在内核中就切换，由于进程执行并不是按照先进先出的模式，因此，每个进程都有一个内核栈。

还有一个问题，上面与进程无关的中断一般访问与进程无关的数据，所以需要保护的数据比较少。在这种重入中，几个进程的内核实例会访问与进程相关的共有数据，会导致不一致，而这种临界区会比较多，所以上锁可能会比较麻烦，Linux采用的是一种非透明的切换，即当前进程的内核部分必须主动放弃CPU,才可能切换。这样使内核同步比较简单。所以Linux内核的重入是一定条件下的重入,非抢占式的重入。

现在有人给Linux打了个补丁，使得它成为抢占式的内核(见新闻版)。也许看了这个补丁，会对内核的重入有一个更深入的认识。

bhpang2

内核的重入问题可以通过临界资源的保护解决。传统的UNIX内核是不可抢占的，除非核心态的用户进程自愿放弃或用完它的时间片或等待资源，因而不存在重入问题。通过锁、优先级等方法保护临界资源可以做到重入。这里的临界资源是指OS用于管理各种队列，比如进程队列、BUFFERS队列、I/O队列等公用的内核资源。


---------------------------
学而不精

menp9999

[quote]原帖由 "bhpang2"]内核的重入问题可以通过临界资源的保护解决。传统的UNIX内核是不可抢占的，除非核心态的用户进程自愿放弃或用完它的时间片或等待资源，因而不存在重入问题。通过锁、优先级等方法保护临界资源可以做到重入。这里的临..........[/quote 发表：

最好在设计的尽量减少临界区，因为那是一个等待的过程哦。对性能的影响比较大。

menp999

抽象的讲内核重入,往往让人摸不着头序,与其说是对内核的重入,不如讲是对内核的某些模块的重入,那么哪些模块是可以重入的呢?需要引进一个概念来辅助一下:
纯代码,对与一段纯代码,是可以重入的,我这样理解纯代码的:在这一段程序代码中,没有任何代码直接或间接写全局变量的动作同时也不存在其他任何代码写这段代码中可能用到的全局变量的可能性.
最典型的例子(以LINUX为例子)就是系统调用表,在system_call的派遣程序段需要考虑重入的问题么?(其实也是考虑了,譬如关中断,也就是说,保护环境是不允许被重入的)

menp999

[quote]原帖由 "bhpang2"]内核的重入问题可以通过临界资源的保护解决。传统的UNIX内核是不可抢占的，除非核心态的用户进程自愿放弃或用完它的时间片或等待资源，因而不存在重入问题。通过锁、优先级等方法保护临界资源可以做到重入。这里的临..........[/quote 发表：

LINUX2.4也是不抢占呀内核呀.

wolfop

原帖由 "menp999" 发表：

LINUX2.4也是不抢占呀内核呀.

2.6都不一定是，那个抢占的补丁还没有被正式收录，何况内核是否能被抢占，对服务器似乎影响不大。

menp999

原帖由 "wolfop" 发表：

2.6都不一定是，那个抢占的补丁还没有被正式收录，何况内核是否能被抢占，对服务器似乎影响不大。

是么?不会吧?要你网卡驱动是多线程呢?

wolfop

网卡驱动时多线程的？我没有见过，可能比较土。

menp999

[quote]原帖由 "wolfop"]网卡驱动时多线程的？我没有见过，可能比较土。[/quote 发表：

是么?你可以到SCO的网站去看看呀,关于怎么写多现成的驱动.
LINUX的内河线程都是与进程相光的,所以不能算上真正的内核线程.
如果你还是不明白的话,WINDOWS你知道吧,他的有一个线程就是专门管理RIQ的.

menp9999

[quote]原帖由 "wolfop"]网卡驱动时多线程的？我没有见过，可能比较土。[/quote 发表：

For DDI 8 drivers, if the driver is being run from kernel context (such as in response to an interrupt), all calls to blockable functions must be run on a thread that the driver creates. DDI 8 drivers use the kthread_spawn(D3) function to execute a kernel function that is guaranteed to run in blockable context.

The model is to have the kthread-spawn'ed function blocked on a synchronization variable that the driver sets in response to some kernel event such as queuing the result of an interrupt. The following pseudo-code illustrates this:

   mydrv_init() {
           SVALLOC(mysvp);
           kthread_spawn(myfunc,...)
   }
   
   myfunc(args) {
           SV_WAIT(mysvp);
           drv_open(otherdrv)
           /* do other stuff */
           /* back to SV_WAIT() */
   }
   
   myintr(){
           LOCK(<some stuff>
           /* put otherdrv data someplace safe */
           UNLOCK
           SV_BROADCAST(mysvp);
   }

Note that you never have user context when running in a kernel thread. Even if you spawn the thread from an entry point routine that has user context, the kernel thread does not have user context.