On Fri, Nov 4, 2011 at 4:59 AM, Michal Hocko <mhocko@suse.cz> wrote:

> c9f01245 (oom: remove oom_disable_count) has removed oom_disable_count
> counter which has been used for early break out from oom_badness so we
> could never select a task with oom_score_adj set to OOM_SCORE_ADJ_MIN
> (oom disabled).
>
> Now that the counter is gone we are always going through heuristics
> calculation and we always return a non zero positive value.  This
> means that we can end up killing a task with OOM disabled because it is
> indistinguishable from regular tasks with 1% resp. CAP_SYS_ADMIN tasks
> with 3% usage of memory or tasks with oom_score_adj set but OOM enabled.
>
> Let's break out early if the task should have OOM disabled.
>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> Acked-by: David Rientjes <rientjes@google.com>
> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> ---
>  mm/oom_kill.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index e916168..4465fb8 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -185,6 +185,11 @@ unsigned int oom_badness(struct task_struct *p,
> struct mem_cgroup *mem,
>         if (!p)
>                return 0;
>
> +       if (p->signal->oom_score_adj == OOM_SCORE_ADJ_MIN) {
> +               task_unlock(p);
> +               return 0;
> +       }
> +
>        /*
>         * The memory controller may have a limit of 0 bytes, so avoid a
> divide
>         * by zero, if necessary.
>


This might be late, but still:

Acked-by: Ying Han <yinghan@google.com>

Thanks for fixing this up.

--Ying

> --
> 1.7.7.1
>
>