On Tue, Oct 27, 2015 at 11:37:14AM +0100, mhocko@xxxxxxxxxx wrote:
> From: Michal Hocko <mhocko@xxxxxxxx>
>
> 424cdc141380 ("memcg: convert threshold to bytes") has fixed a
> regression introduced by 3e32cb2e0a12 ("mm: memcontrol: lockless page
> counters") where thresholds were silently converted to use page units
> rather than bytes when interpreting the user input.
>
> The fix is not complete, though, as properly pointed out by Ben
> Hutchings during stable backport review. The page count is converted
> to bytes but unsigned long is used to hold the value which would
> be obviously not sufficient for 32b systems with more than 4G
> thresholds. The same applies to usage as taken from mem_cgroup_usage
> which might overflow.
>
> Let's remove this bytes vs. pages internal tracking differences and
> handle thresholds in page units internally. Chage mem_cgroup_usage()
> to return the value in page units and revert 424cdc141380 because this
> should be sufficient for the consistent handling.
> mem_cgroup_read_u64 as the only users of mem_cgroup_usage outside of
> the threshold handling code is converted to give the proper in bytes
> result. It is doing that already for page_counter output so this is
> more consistent as well.
>
> The value presented to the userspace is still in bytes units.
>
> Fixes: 424cdc141380 ("memcg: convert threshold to bytes")
> Fixes: 3e32cb2e0a12 ("mm: memcontrol: lockless page counters")
> CC: stable@xxxxxxxxxxxxxxx
> Reported-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
> Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> +++ b/mm/memcontrol.c
> @@ -2802,7 +2802,7 @@ static unsigned long tree_stat(struct mem_cgroup *memcg,
> return val;
> }
>
> -static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap)
> +static inline unsigned long mem_cgroup_usage(struct mem_cgroup *memcg, bool swap)
> {
> u64 val;
Minor nit, but this should probably be unsigned long now.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html