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]
Message-ID: <4FC732F5.6080706@parallels.com>
Date:	Thu, 31 May 2012 12:59:33 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC:	Gao feng <gaofeng@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	David Rientjes <rientjes@...gle.com>, <hannes@...xchg.org>,
	<mhocko@...e.cz>, <bsingharora@...il.com>,
	<akpm@...ux-foundation.org>, <linux-kernel@...r.kernel.org>,
	<cgroups@...r.kernel.org>, <linux-mm@...ck.org>,
	<containers@...ts.linux-foundation.org>
Subject: Re: [PATCH] meminfo: show /proc/meminfo base on container's memcg

On 05/31/2012 12:51 PM, Kamezawa Hiroyuki wrote:
>> One think to keep in mind: A file in memcg does not need to follow the
>> same format
>> of /proc/meminfo so we can bind mount. We should be able to
>> reconstruct that in
>>  userspace based on information available from the kernel. You can
>> even collect that
>> from multiple locations, and *then* you bind mount.
>
> I'm sorry I couldn't fully understand. Could you explain more ?
> Do you mean
>   - bind mount memory cgroup directory into the container for exporting
> information
>   - Some user-space apps, FUSE-procfs or some, can provide enough
> information
>

Implementation details aside, the idea is to have something like FUSE to 
hook the read(), and then construct the information it needs to present 
in the proper format.

Alternatively, for files that doesn't change a lot, you can create a 
file /container-storage-area/my_copy_of_meminfo at container creation, 
and bind mount *that* file.

There is no reason to bind mount a kernel-provided file directly.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ