On Tue, Oct 27, 2015 at 11:37:14AM +0100, mho...@kernel.org wrote: > From: Michal Hocko <mho...@suse.com> > > 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: sta...@vger.kernel.org > Reported-by: Ben Hutchings <b...@decadent.org.uk> > Signed-off-by: Michal Hocko <mho...@suse.com>
Acked-by: Johannes Weiner <han...@cmpxchg.org> > +++ 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/