[Devel] BUG: Overflow in mem_cgroup_apply_beancounter leads to ENOMEM
Vladimir Meshkov
vmeshkov at cloudlinux.com
Wed May 31 00:58:22 PDT 2017
When unlimited UBC is created next code is performed in
mem_cgroup_apply_beancounter:
mem = ub->ub_parms[UB_PHYSPAGES].limit;
memsw = ub->ub_parms[UB_SWAPPAGES].limit;
if (memsw < PAGE_COUNTER_MAX - mem)
memsw += mem;
else
memsw = PAGE_COUNTER_MAX;
If mem == memsw == UB_MAXVALUE == 9223372036854775807, the condition if
(memsw < PAGE_COUNTER_MAX - mem) will be true,
due to (LONG_MAX/PAGE_SIZE - LONG_MAX) > LONG_MAX and memsw is unsigned
long long.
Then we add 9223372036854775807 + 9223372036854775807, and this leads to
overflow, and as a result we have unsigned long
memcg->memsw.limit==18446744073709551614, or -2 for long type variable.
The value memsw==18446744073709551614 is used in mem_cgroup_enough_memory
to calculate variable free:
long free = memcg->memsw.limit - page_counter_read(&memcg->memsw);
Due to type 'long' memcg->memsw.limit == -2 (18446744073709551614), and the
function returns -ENOMEM despite of unlimited UBC.
Could you please check the condition if (memsw < PAGE_COUNTER_MAX - mem) ?
It's pretty strange to compare LONG_MAX/PAGE_SIZE and LONG_MAX values.
--
Best regards,
Vladimir Meshkov,
CloudLinux kernel team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/devel/attachments/20170531/4e8c8430/attachment.html>
More information about the Devel
mailing list