linux-kernel - Re: [PATCH v2 3/7] memcg, slab: separate memcg vs root cache creation paths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Feb 2014 17:03:36 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	Vladimir Davydov <vdavydov@...allels.com>
Cc:	akpm@...ux-foundation.org, rientjes@...gle.com, penberg@...nel.org,
	cl@...ux.com, glommer@...il.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, devel@...nvz.org
Subject: Re: [PATCH v2 3/7] memcg, slab: separate memcg vs root cache
 creation paths

On Mon 03-02-14 19:54:38, Vladimir Davydov wrote:
> Memcg-awareness turned kmem_cache_create() into a dirty interweaving of
> memcg-only and except-for-memcg calls. To clean this up, let's create a
> separate function handling memcg caches creation. Although this will
> result in the two functions having several hunks of practically the same
> code, I guess this is the case when readability fully covers the cost of
> code duplication.

I don't know. The code is apparently cleaner because calling a function
with NULL memcg just to go via several if (memcg) branches is ugly as
hell. But having a duplicated function like this calls for a problem
later.

Would it be possible to split kmem_cache_create into memcg independant
part and do the rest in a single memcg branch?
 
> Signed-off-by: Vladimir Davydov <vdavydov@...allels.com>
> ---
>  include/linux/memcontrol.h |   14 ++---
>  include/linux/slab.h       |    9 ++-
>  mm/memcontrol.c            |   16 ++----
>  mm/slab_common.c           |  130 ++++++++++++++++++++++++++------------------
>  4 files changed, 90 insertions(+), 79 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 84e4801fc36c..de79a9617e09 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -500,8 +500,8 @@ int memcg_cache_id(struct mem_cgroup *memcg);
>  
>  char *memcg_create_cache_name(struct mem_cgroup *memcg,
>  			      struct kmem_cache *root_cache);
> -int memcg_alloc_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
> -			     struct kmem_cache *root_cache);
> +int memcg_alloc_cache_params(struct kmem_cache *s,
> +		struct mem_cgroup *memcg, struct kmem_cache *root_cache);

Why is the parameters ordering changed? It really doesn't help
review the patch. Also what does `s' stand for and can we use a more
descriptive name, please?

[...]
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/