【求助】OOM的时候kill进程失败

nswcfd

还是由等待的事件源来wakeup要安全一些。

这种情况下，倒不如想办法终止或减少磁盘IO的频率？

bfdhczw

回复 11# nswcfd


    我也想等到事件来源，但是现在系统已经不调度了，几乎是卡死状态，没法等到事件来源。
减少磁盘操作是不可能的，原因有两个
其一，这个进程的源码不在我们手上，
其二，这个进程本身是个下载器，不操作磁盘不可能。

所以，我现在期望能达到的最好效果就是，OOM的时候kill这个进程，保证系统不被卡死。

nswcfd

11楼表达的不准确，意思是接管内核的disk io入口(hack/hack/hack)，替换成空操作，避免新的io操作产生。
这样，旧的请求才能及时被旧的io模块满足，产生wakeup调用，进程才能结束D状态。

当然，也可以去模拟disk io的complete事件，终极目标是触发wakeup。
不太建议绕过io系统去直接wakeup处于D状态的进程，除非先cancel掉原来的wait。

不建议的原因是出于稳定性考虑。
waitq通常位于等待进程的stack上（类似DEFINE_WAIT），如果自行把进程wakeup，则进程会继续执行。
像楼主的例子，就响应OOM的kill signal结束进程了。
但是io子系统不知道这些事情，当事件完成后，依然会调用wakeup，去修改waitq的状态。
这时候就不知道会touch到谁的内存了。

bfdhczw

回复 13# nswcfd


    我是这样做的，直接active，但还是杀不掉

1. int kill_etm(void)
   
2. {
   
3.         int ret = 0;
   
4.         struct task_struct *p;
   
5. 
   
6.         read_lock(&tasklist_lock);
   
7.         for_each_process(p){
   
8.                 if(!strcmp("my_process_name", p->comm)){
   
9.                         oom_kill_task(p, NULL);
   
10.                         ret = 1;
    
11.                         break;
    
12.                 }
    
13.         }
    
14.         read_unlock(&tasklist_lock);
    
15. 
    
16.         if(likely(ret) && likely(p!=current)){
    
17.                 printk("%s active %s and schedule()\n", __func__, p->comm);
    
18.                 activate_task_priv(p);               
    
19.                 schedule_timeout_uninterruptible(HZ>>2);
    
20.         }
    
21.        
    
22.         return ret;
    
23. }

复制代码

nswcfd

不好意思，忽略了一件事情，D状态是不考虑signal的。

1. #define __wait_event(wq, condition)                                         \
   
2. do {                                                                        \
   
3.         DEFINE_WAIT(__wait);                                                \
   
4.                                                                         \
   
5.         for (;;) {                                                        \
   
6.                 prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);        \
   
7.                 if (condition)                                                \
   
8.                         break;                                                \
   
9.                 schedule();                                                \
   
10.         }                                                                \
    
11.         finish_wait(&wq, &__wait);                                        \
    
12. } while (0)

复制代码

其中的schedule会被楼主显式的wake_up恢复，但是如果继续检查条件（IO未完成等），还是不满足，继续schedule。
关键还是得破坏（或者说满足）condition条件。

bfdhczw

回复 15# nswcfd


    D状态不响应signal我是知道的，我理解的不响应只是暂时不响应，信号被挂起而已，等到进程退出D状态的时候，就会响应了。难道我理解错了？

bfdhczw

回复 15# nswcfd

1. #define __wait_event(wq, condition)                                         \
   
2. do {                                                                        \
   
3.         DEFINE_WAIT(__wait);                                                \
   
4.                                                                         \
   
5.         for (;;) {                                                        \
   
6.                 prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);        \
   
7.                 if (condition)                                                \
   
8.                         break;                                                \
   
9.                 if(current->force_quit)\
   
10.                         break;\
    
11.                 schedule();                                                \
    
12.         }                                                                \
    
13.         finish_wait(&wq, &__wait);                                        \
    
14.         if(current->force_quit){\
    
15.                 printk("=========> force_quit at %s\n", __func__);\
    
16.                 force_sig(SIGKILL, current);\
    
17.         }\
    
18. } while (0)

复制代码

我把代码改成了这样，在task_struct里面加了force_quit成员，看起来wait queue上不会出什么问题，不知道会不会引起其他问题。
目前还没有测试结果，等后面有测试结果了，再继续更新状况。

nswcfd

回复 16# bfdhczw
“退出D状态去响应信号”不会平白无故的发生，一定对应某个kernel code path，比如
1）等待的条件满足，结束wait_event循环，在核心态返回用户态的路径上检查信号处理；
2）像wait_event_interruptible那样，在wait循环里面，每次醒来之后显式的检查是否有信号发生，如果有退出循环，在返回用户态的路径上处理signal。