rmmod 为何陷入"uninterruptible sleep"状态

grep_one

问题描述：
application A, B共用模块C， C的主要功能：查找，挂载，卸载usb设备，该模块用脚本实现。
A和B都是先fork一个进程，然后执行（exec*）C模块，整个流程没什么区别，但C模块在A中
工作很好，在B中却会使rmmod（在C中调用）进程陷入“uninterruptible sleep”状态（-D）。

请问有人曾经碰到过类似的问题，或知道怎么解决吗？

scutan

原帖由 grep_one 于 2007-5-7 16:10 发表于 1楼  
问题描述：
application A, B共用模块C， C的主要功能：查找，挂载，卸载usb设备，该模块用脚本实现。
A和B都是先fork一个进程，然后执行（exec*）C模块，整个流程没什么区别，但C模块在A中
工作很好，在B中 ...

LKD上面第三章讲进程那儿写的

TASK_UNINTERRUPTIBLE This state is identical to TASK_INTERRUPTIBLE except that it does not wake up and become runnable if it receives a signal. This is used in situations where the process must wait without interruption or when the event is expected to occur quite quickly. Because the task does not respond to signals in this state, TASK_UNINTERRUPTIBLE is less often used than TASK_INTERRUPTIBLE

This is why you have those dreaded unkillable processes with state D in ps(1). Because the task will not respond to signals, you cannot send it a SIGKILL signal. Further, even if you could terminate the task, it would not be wise as the task is supposedly in the middle of an important operation and may hold a semaphore.

也就是说你的进程现在是uninterruptible sleep状态,这个状态是不能够被信号所中断的,所以说你的rmmod不能成功.
解决方法是你在睡眠的时候不要调用uninterruptible_sleep()这一系列的函数,而调用interruptible_sleep()这一类函数.

grep_one

我猜rmmod在卸载usb-storage模块时应该被设置为uninterruptible sleep状态，因为它持有usb设备的信号。我现在的问题不是怎么样能让rmmod在工作时能被中止（能响应SIGKILL信号），而是它为什么会在A和B中出现不一致的行为。
NOTE：该问题在A中能100％地被复制，在B中我好像还没有碰到过。

scutan

原帖由 grep_one 于 2007-5-7 16:46 发表于 3楼  
我猜rmmod在卸载usb-storage模块时应该被设置为uninterruptible sleep状态，因为它持有usb设备的信号。我现在的问题不是怎么样能让rmmod在工作时能被中止（能响应SIGKILL信号），而是它为什么会在A和B中出现不一 ...

最好的办法就是比较A和B这两个程序有哪些地方不相同, 从不相同的地方着手去想解决的方法!

grep_one

或者能帮我解释下rmmod -a吗，我用rmmod -a是能让它们正常工作的，但是对原因却不是很清楚。

grep_one

原帖由 grep_one 于 2007-5-7 17:02 发表于 5楼  
或者能帮我解释下rmmod -a吗，我用rmmod -a是能让它们正常工作的，但是对原因却不是很清楚。

Sorry，rmmod -a usb-storage是不行的，我看错了，运行前后所有加载的模块好像没有任何改变，这是不对的。

scutan

原帖由 grep_one 于 2007-5-7 17:02 发表于 5楼  
或者能帮我解释下rmmod -a吗，我用rmmod -a是能让它们正常工作的，但是对原因却不是很清楚。

rmmod -a 是指删除所有目前不需要的模块。

[ 本帖最后由 scutan 于 2007-5-7 17:33 编辑 ]

grep_one

问题的症结所在（或者说解决办法）为：

C中的rmmod进程是作为A或B的子进程存在的。A中有对SIGHUP信号的处理（要的效果是在A中要忽略掉SIGHUP信号），
B中没有，我发现当我设置信号处理句柄为SIGIGN（即xx.sa_handler ＝ SIGIGN）时，问题就会出现，而用空的函数代替，
则可避免。

现在只能确定父进程对信号的处理方式影响了子进程。只是具体的细节却不甚了了。

希望能有达人帮助释疑。

[ 本帖最后由 grep_one 于 2007-5-8 14:30 编辑 ]