oom: Make coredump interruptible
in [Kernel]
|
Prev: [PATCH] Documentation: Add doc about aerdriver.* parameters to kernel-parameters.txt
Next: [PATCH] Allow empty e820 map if EFI map will be provided later.
From: David Rientjes on 9 Jun 2010 16:50 On Wed, 9 Jun 2010, Oleg Nesterov wrote: > --- x/mm/oom_kill.c > +++ x/mm/oom_kill.c > @@ -414,6 +414,7 @@ static void __oom_kill_task(struct task_ > p->rt.time_slice = HZ; > set_tsk_thread_flag(p, TIF_MEMDIE); > > + clear_bit(MMF_COREDUMP, &p->mm->flags); > force_sig(SIGKILL, p); > } > This requires task_lock(p). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 9 Jun 2010 17:10 On 06/09, David Rientjes wrote: > > On Wed, 9 Jun 2010, Oleg Nesterov wrote: > > > --- x/mm/oom_kill.c > > +++ x/mm/oom_kill.c > > @@ -414,6 +414,7 @@ static void __oom_kill_task(struct task_ > > p->rt.time_slice = HZ; > > set_tsk_thread_flag(p, TIF_MEMDIE); > > > > + clear_bit(MMF_COREDUMP, &p->mm->flags); > > force_sig(SIGKILL, p); > > } > > > > This requires task_lock(p). Yes, yes, sure. This is only template. I'll wait for the next mmotm to send the actual patch on top of recent changes. Unless Kosaki/Roland have other ideas. Imho, we really need to fix the coredump/oom problem. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 13 Jun 2010 07:30 Sorry for the delay. > On 06/04, Oleg Nesterov wrote: > > > > On 06/04, KOSAKI Motohiro wrote: > > > > > > In multi threaded OOM case, we have two problematic routine, coredump > > > and vmscan. Roland's idea can only solve the former. > > > > > > But I also interest vmscan quickly exit if OOM received. > > > > Yes, agreed. See another email from me, MMF_ flags looks "obviously > > useful" to me. > > Well. But somehow we forgot about the !coredumping case... Suppose > that select_bad_process() chooses the process P to kill and we have > other processes (not sub-threads) which share the same ->mm. Ah, yes. I think you are correct. > In that case I am not sure we should blindly set MMF_OOMKILL. Suppose > that we kill P and after that the "out-of-memory" condition goes away. > But its ->mm still has MMF_OOMKILL set, and it is used. Who/when will > clear this flag? > > Perhaps something like below makes sense for now. Probably, this works. at least I don't find any problems. But umm... Do you mean we can't implement per-process oom flags? example, 1) back to implement signal->oom_victim because We are using SIGKILL for OOM and struct signal naturally represent signal target. 2) mm->nr_oom_killed_task just avoid simple flag. instead counting number of tasks of oom-killed. I think both avoid your explained problem. Am I missing something? But, again, I have no objection to your patch. because I really hope to fix coredump vs oom issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 13 Jun 2010 12:00 On 06/13, KOSAKI Motohiro wrote: > > > On 06/04, Oleg Nesterov wrote: > > > > > Perhaps something like below makes sense for now. > > Probably, this works. at least I don't find any problems. > But umm... Do you mean we can't implement per-process oom flags? Sorry, can't understand what you mean. > example, > 1) back to implement signal->oom_victim > because We are using SIGKILL for OOM and struct signal > naturally represent signal target. Yes, but if this process participates in the coredump, we should find the right thread, or mark mm or mm->core_state. In fact, I was never sure that oom-kill should kill the single process. Perhaps it should kill all tasks using the same ->mm instead. But this is another story. > 2) mm->nr_oom_killed_task > just avoid simple flag. instead counting number of tasks of > oom-killed. again, can't understand. > I think both avoid your explained problem. Am I missing something? I guess that I am missing something ;) Please clarify? > But, again, I have no objection to your patch. because I really hope to > fix coredump vs oom issue. Yes, I think this is important. And if we keep the PF_EXITING check in select_bad_process(), it should be fixed so that at least the coredump can't fool it. And the "p != current" is obviously not right too. I'll try to do something next week, the patches should be simple. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roland McGrath on 13 Jun 2010 20:30
> Oh. This needs more thinking. Definitely the task sleeping in exit_mm() > must not exit until core_state->dumper->thread returns from do_coredump(). > If nothing else, the dumper can use its task_struct and it relies on > the stable core_thread->next list. And right now TASK_KILLABLE can't > work anyway, it is possible that fatal_signal_pending() is true. Yes, I was right to say this should be another thread. Let's not get into all this right now. I think it is mostly orthogonal to the oom_kill issue. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |