linux-kernel - Re: [RFC/PATCH -v2] Add sysfs control to modify a user's cpu share

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, 04 Oct 2007 12:02:01 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	lkml <linux-kernel@...r.kernel.org>, maneesh@...ux.vnet.ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sudhir Kumar <skumar@...ux.vnet.ibm.com>
Subject: Re: [RFC/PATCH -v2] Add sysfs control to modify a user's cpu share

Heiko Carstens wrote:
>>> Changelog since v1:
>>> 1. Added a mutex to serialize directory creation/destruction for a user in
>>>    sysfs
>>> 2. Added a spinlock in the task_group structure to serialize writes to
>>>    tg->shares.
>>> 3. Removed /proc/root_user_cpu_shares.
>>> 4. Added Documentation about the group scheduler.
>> thanks - I have added this to the queue.
>>
>> i'm wondering about the following: could not (yet) existing UIDs be made 
>> configurable too? I.e. if i do this in a bootup script:
>>
>>   echo 2048 > /sys/kernel/uids/500/cpu_share
>>
>> this should just work too, regardless of there not being any UID 500 
>> tasks yet. Likewise, once configured, the /sys/kernel/uids/* directories 
>> (with the settings in them) should probably not go away either.
> 
> Shouldn't that be done via uevents? E.g. UID x gets added to the sysfs tree,
> generates a uevent and a script then figures out the cpu_share and sets it.
> That way you also don't need to keep the directories. No?

That sounds complex administratively. It means that instead of setting a 
higher or lower than default once and having it persist until reboot I 
have to create a script, which *will* in some cases be left in place 
even after the need has gone.

I agree with Ingo, once it's done it should be persistent.

And as another administrative convenience I can look at that set of 
values and see what shares are being used, even when the user is not 
currently active.

Final question, how do setuid processes map into this implementation?

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
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/