[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180928141509.fd8f8ac8c0ea61f0cb79d494@linux-foundation.org>
Date: Fri, 28 Sep 2018 14:15:09 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Kirill Tkhai <ktkhai@...tuozzo.com>
Cc: gorcunov@...nvz.org, mhocko@...e.com, aryabinin@...tuozzo.com,
hannes@...xchg.org, penguin-kernel@...ove.SAKURA.ne.jp,
shakeelb@...gle.com, jbacik@...com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()
On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai <ktkhai@...tuozzo.com> wrote:
> do_shrink_slab() returns unsigned long value, and
> the placing into int variable cuts high bytes off.
> Then we compare ret and 0xfffffffe (since SHRINK_EMPTY
> is converted to ret type).
>
> Thus, big number of objects returned by do_shrink_slab()
> may be interpreted as SHRINK_EMPTY, if low bytes of
> their value are equal to 0xfffffffe. Fix that
> by declaration ret as unsigned long in these functions.
Sigh. How many times has this happened.
> Reported-by: Cyrill Gorcunov <gorcunov@...nvz.org>
What did he report? Was it code inspection? Did the kernel explode?
etcetera. I'm thinking that the fix should be backported but to
determine that, we need to understand the end-user runtime effects, as
always. Please.
Powered by blists - more mailing lists