linux-kernel - Re: Re: [RFC] How to handle the rules engine for cgroups

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:	Sat, 19 Jul 2008 08:10:24 +0900 (JST)
From:	kamezawa.hiroyu@...fujitsu.com
To:	balbir@...ux.vnet.ibm.com
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Libcg Devel Mailing List <libcg-devel@...ts.sourceforge.net>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Paul Menage <menage@...gle.com>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	Kazunaga Ikeno <k-ikeno@...jp.nec.com>,
	Morton Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Re: [RFC] How to handle the rules engine for cgroups

----- Original Message -----
>KAMEZAWA Hiroyuki wrote:
>> On Tue, 1 Jul 2008 15:11:26 -0400
>> Vivek Goyal <vgoyal@...hat.com> wrote:
>> 
>>> Hi,
>>>
>>> While development is going on for cgroup and various controllers, we also
>>> need a facility so that an admin/user can specify the group creation and
>>> also specify the rules based on which tasks should be placed in respective
>>> groups. Group creation part will be handled by libcg which is already
>>> under development. We still need to tackle the issue of how to specify
>>> the rules and how these rules are enforced (rules engine).
>>>
>> 
>> A different topic.
>> 
>> Recently I'm interested in "How to write userland daemon program
>> to control group subsystem." To implement that effectively, we need
>> some notifier between user <-> kernel.
>> 
>> Can we use "inotify" to catch changes in cgroup (by daemon program) ?
>> 
>> For example, create a new file under memory cgroup
>> ==
>>   /opt/memory_cgroup/group_A/notify_at_memory_reach_limit
>> ==
>> And a user watches the file by inotify.
>> The kernel modify modified-time of notify_at_memory_reach_limit file and ca
ll
>> fs/notify_user.c::notify_change() against this inode. He can catchthe event
>> by inotify.
>
>Won't the time latency be an issue (time between exceeding the limit and the
>user space being notified?). Since the notification does not use user memory 
at
>the moment (it will not stress the limits futher :)), provided the notificati
on
>handler is not running under the group that has exceeded its limit. Do we exp
ect
>the user space application to ACK that it's seen the notification? We could u
se
>a netlink channel as well (in the case that we need two way communication).
>
>I would prefer to notify on memory.failcnt, if we do use this interface.
>
Maybe we need some technique "How to run a daemon in proper way."
(use special daemon cgroup etc...)
I don't think the user space has to do ACK to the kernel. The user space
can modify control file when he get events, but that's all he can do, anyway.

Thanks,
-Kame 

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