linux-kernel - Re: [PATCH -mm] slab: use cgroup ino for naming per memcg caches

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, 7 Apr 2015 13:38:19 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Vladimir Davydov <vdavydov@...allels.com>
Cc:	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>, <linux-mm@...ck.org>,
	<cgroups@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mm] slab: use cgroup ino for naming per memcg caches

On Tue, 7 Apr 2015 16:53:18 +0300 Vladimir Davydov <vdavydov@...allels.com> wrote:

> The name of a per memcg kmem cache consists of three parts: the global
> kmem cache name, the cgroup name, and the css id. The latter is used to
> guarantee cache name uniqueness.
> 
> Since css ids are opaque to the userspace, in general it is impossible
> to find a cache's owner cgroup given its name: there might be several
> same-named cgroups with different parents so that their caches' names
> will only differ by css id. Looking up the owner cgroup by a cache name,
> however, could be useful for debugging. For instance, the cache name is
> dumped to dmesg on a slab allocation failure. Another example is
> /sys/kernel/slab, which exports some extra info/tunables for SLUB caches

/proc/sys/kernel/slab?

> referring to them by name.
> 
> This patch substitutes the css id with cgroup inode number, which, just
> like css id, is reserved until css free, so that the cache names are
> still guaranteed to be unique, but, in contrast to css id, it can be
> easily obtained from userspace.
> 
> ...
>
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -478,7 +478,7 @@ void memcg_create_kmem_cache(struct mem_cgroup *memcg,
>  			     struct kmem_cache *root_cache)
>  {
>  	static char memcg_name_buf[NAME_MAX + 1]; /* protected by slab_mutex */
> -	struct cgroup_subsys_state *css = mem_cgroup_css(memcg);
> +	struct cgroup *cgroup;
>  	struct memcg_cache_array *arr;
>  	struct kmem_cache *s = NULL;
>  	char *cache_name;
> @@ -508,9 +508,10 @@ void memcg_create_kmem_cache(struct mem_cgroup *memcg,
>  	if (arr->entries[idx])
>  		goto out_unlock;
>  
> -	cgroup_name(css->cgroup, memcg_name_buf, sizeof(memcg_name_buf));
> -	cache_name = kasprintf(GFP_KERNEL, "%s(%d:%s)", root_cache->name,
> -			       css->id, memcg_name_buf);
> +	cgroup = mem_cgroup_css(memcg)->cgroup;
> +	cgroup_name(cgroup, memcg_name_buf, sizeof(memcg_name_buf));
> +	cache_name = kasprintf(GFP_KERNEL, "%s(%lu:%s)", root_cache->name,
> +			(unsigned long)cgroup_ino(cgroup), memcg_name_buf);
>  	if (!cache_name)
>  		goto out_unlock;

Is this interface documented anywhere?
--
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/