On 29.09.2018 00:15, Andrew Morton wrote: > On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai <ktk...@virtuozzo.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 <gorcu...@openvz.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.
Yeah, it was just code inspection. It's need to be a really unlucky person to meet this in real life -- the probability is very small. The runtime effect would be the following. Such the unlucky person would have a single shrinker, which is never called for a single memory cgroup, despite there are objects charged. Thanks, Kirill
