lkml.org 
[lkml]   [2011]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] oom: fix integer overflow of points in oom_badness
On Mon, 31 Oct 2011, Frantisek Hrbata wrote:

> An integer overflow will happen on 64bit archs if task's sum of rss, swapents
> and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit
>
> f755a04 oom: use pte pages in OOM score
>

This commit was introduced in 2.6.39 but also backported to stable since
2.6.36, so presumably we'd need to mark this for stable as well going back
that far.

> where the oom score computation was divided into several steps and it's no
> longer computed as one expression in unsigned long(rss, swapents, nr_pte are
> unsigned long), where the result value assigned to points(int) is in
> range(1..1000). So there could be an int overflow while computing
>
> 176 points *= 1000;
>
> and points may have negative value. Meaning the oom score for a mem hog task
> will be one.
>
> 196 if (points <= 0)
> 197 return 1;
>
> For example:
> [ 3366] 0 3366 35390480 24303939 5 0 0 oom01
> Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child
>
> Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
> memory, but it's oom score is one.
>
> In this situation the mem hog task is skipped and oom killer kills another and
> most probably innocent task with oom score greater than one.
>
> The points variable should be of type long instead of int to prevent the int
> overflow.
>
> Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>

Acked-by: David Rientjes <rientjes@google.com>
Cc: stable@kernel.org [2.6.36+]


\
 
 \ /
  Last update: 2011-10-31 19:25    [W:0.087 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site