From: Minchan Kim on
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
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
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
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/