linux-kernel - RE: [RFC][patch 3/11][CFQ-cgroup] Introduce cgroup subsystem

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: <003001c89532$dae5dd20$90b19760$@jp.nec.com>
Date:	Thu, 3 Apr 2008 11:31:43 +0900
From:	"Satoshi UCHIDA" <s-uchida@...jp.nec.com>
To:	"'Paul Menage'" <menage@...gle.com>,
	<linux-kernel@...r.kernel.org>,
	<containers@...ts.linux-foundation.org>
Cc:	<axboe@...nel.dk>, <tom-sugawara@...jp.nec.com>,
	<m-takahashi@...jp.nec.com>
Subject: RE: [RFC][patch 3/11][CFQ-cgroup] Introduce cgroup subsystem

Thank you for reply.

> >  +
> >  +static struct cgroup_subsys_state *
> >  +cfq_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
> >  +{
> >  +       struct cfq_cgroup *cfqc;
> >  +
> >  +       if (!capable(CAP_SYS_ADMIN))
> >  +               return ERR_PTR(-EPERM);
> >  +
> >  +       if (!cgroup_is_descendant(cont))
> >  +               return ERR_PTR(-EPERM);
> 
> What are these checks for? Cgroups already provides filesystem
> permissions to control directory creation, and the "descendant" check
> looks like it may have been cut/pasted from the nsproxy subsystem.
> 

This code was referred one of io-throttle.
Is it not necessary these checks?
IF not necessary, remove this code.

> 
> >   /* */
> >  +
> >  +#ifdef CONFIG_CGROUP_CFQ
> >  +SUBSYS(cfq_cgroup)
> >  +#endif
> >  +
> >  +/* */
> 
> To fit with the convention for other subsystems, simply "cfq" would be
> a better name than "cfq_cgroup". (Clearly it's a cgroup subsystem from
> context).
> 

Ok, I change name.
I hesitated whether using "_cgroup".
The cpuset and the cpuacct does not use it,
but cpu and memory uses it(cpu_cgroup and mem_cgroup).
In this patchset, I select the latter case.

> Is this subsystem meant to allow you to control any device that uses
> CFQ, or is it specific to disks? It would be nice to be able to allow
> different groups have different guarantees on different disks.
>

I want to allow to control any devices. (Now, any devices using CFQ)
However, I think the main target of above device is disk devices.

I think so that a different groups have different guarantees on different disks.
And, It would be more better to be able to allow different hierarchies for different disks.

Now, I consider two solutions.

One is that a new resource manager(subsystem) is created when new device is plugged.
But, The current cgroup framework would not be resisted dynamically.

The another is that a new file entry is resisted when new device is plugged.
But, when a new cgroup is created, there are only information that request_queue and cgroup structure.
So, I seem that device name cannot be referred.
Namely, a name of entry cannot be defined.
And, this means cannot have different hierarchies.

I try to this mechanism in future.

I missed.
This patchset is not all.
There is not a patch for adding the "ioprio" entry.
I resend this patchset after fixing name and checking.

Thanks,
Satoshi UCHIDA

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (4961 bytes)