Prev: [PATCH] x86, hpet.c: Changed type of field work of hpet_work_struct (delayed_work to work_struct)
Next: oom: oom_kill_process() need to check p is unkillable
From: Minchan Kim on 16 Jun 2010 11:10 On Wed, Jun 16, 2010 at 08:32:08PM +0900, KOSAKI Motohiro wrote: > Now, select_bad_process() have PF_KTHREAD check, but oom_kill_process > doesn't. It mean oom_kill_process() may choose wrong task, especially, > when the child are using use_mm(). Now oom_kill_process is called by three place. 1. mem_cgroup_out_of_memory 2. out_of_memory with sysctl_oom_kill_allocating_task 3. out_of_memory with non-sysctl_oom_kill_allocating_task I think it's no problem in 1 and 3 since select_bad_process already checks PF_KTHREAD. The problem in in 2. So How about put the check before calling oom_kill_process in case of sysctl_oom_kill_allocating task? if (sysctl_oom_kill_allocating_task) { if (!current->flags & PF_KTHREAD) oom_kill_process(); It can remove duplicated PF_KTHREAD check in select_bad_process and oom_kill_process. -- Kind regards, Minchan Kim -- 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: David Rientjes on 21 Jun 2010 16:20 On Thu, 17 Jun 2010, KOSAKI Motohiro wrote: > > Now, select_bad_process() have PF_KTHREAD check, but oom_kill_process > doesn't. It mean oom_kill_process() may choose wrong task, especially, > when the child are using use_mm(). > This type of check should be moved to badness(), it will prevent these types of tasks from being selected both in select_bad_process() and oom_kill_process() if the score it returns is 0. -- 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: Minchan Kim on 30 Jun 2010 10:30 On Wed, Jun 30, 2010 at 06:27:52PM +0900, KOSAKI Motohiro wrote: > Now, select_bad_process() have PF_KTHREAD check, but oom_kill_process > doesn't. It mean oom_kill_process() may choose wrong task, especially, > when the child are using use_mm(). Is it possible child is kthread even though parent isn't kthread? -- Kind regards, Minchan Kim -- 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: Minchan Kim on 1 Jul 2010 09:40
On Thu, Jul 01, 2010 at 09:07:02AM +0900, KOSAKI Motohiro wrote: > > On Wed, Jun 30, 2010 at 06:27:52PM +0900, KOSAKI Motohiro wrote: > > > Now, select_bad_process() have PF_KTHREAD check, but oom_kill_process > > > doesn't. It mean oom_kill_process() may choose wrong task, especially, > > > when the child are using use_mm(). > > > > Is it possible child is kthread even though parent isn't kthread? > > Usually unhappen. but crappy driver can do any strange thing freely. > As I said, oom code should have conservative assumption as far as possible. Okay. You change the check with oom_unkillable_task at last. The oom_unkillable_task is generic function so that the kthread check in oom_kill_process is tivial, I think. Reviewed-by: Minchan Kim <minchan.kim(a)gmail.com> > > > -- Kind regards, Minchan Kim -- 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/ |