netdev - Re: pkt_sched: Control group classifier

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:	Thu, 30 Oct 2008 15:24:17 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Ranjit Manomohan <ranjitm@...gle.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: pkt_sched: Control group classifier

* Ranjit Manomohan <ranjitm@...gle.com> 2008-10-30 06:29
> By assigning the parent to the cgroup before the new process is forked.
> 
> An excerpt from the patch I had sent out:
> 
> # write the current shell pid to the cgroup
> echo $$ > /dev/cgroup/file_transfer/tasks
> #start the new task (e.g. ftp)
> ftp foo.bar.com

This is actually new information, so far you have been proposing
echo $PID_OF_FILE_XFER_PROCESS > /dev/cgroup/file_transfer/tasks

I think this is a reasonable approach but not enough in some
situations. The cgroup documentation lists a web browser cgroup
as one of its example, how would you configure this exactly?
Creating wrapper scripts is possible but doesn't guarantee that
the user actually runs the wrapper rather than the actual browser
itself.

How does it work with kernel threads? F.e. knfsd.

I thought the point with cgroups was to allow the administrator to
classify processes based on exec notifications as found in the
documentation:

<quote>
With the ability to classify tasks differently for different resources
(by putting those resource subsystems in different hierarchies) then
the admin can easily set up a script which receives exec notifications
and depending on who is launching the browser he can

       # echo browser_pid > /mnt/<restype>/<userclass>/tasks
<endquote>

I think all arguments have been brought up. There are pros and cons
with either solution.

> Again in practice both these may be overkill since it should be
> relatively easy for a resource management daemon on the system to
> start new processes in a cgroup instead of attempting live migration.

I guess this is a matter of perspective. Personally I would find it
useful to be able to throw running processes into a cgroup and
limit their resource consumption.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html