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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E983177.5000005@parallels.com>
Date:	Fri, 14 Oct 2011 16:56:23 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	David Miller <davem@...emloft.net>
CC:	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	<lizf@...fujitsu.com>, <kamezawa.hiroyu@...fujitsu.com>,
	<ebiederm@...ssion.com>, <paul@...lmenage.org>,
	<gthelen@...gle.com>, <netdev@...r.kernel.org>,
	<linux-mm@...ck.org>, <kirill@...temov.name>,
	<avagin@...allels.com>, <devel@...nvz.org>
Subject: Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers

On 10/14/2011 12:18 AM, David Miller wrote:
> From: Glauber Costa<glommer@...allels.com>
> Date: Fri, 14 Oct 2011 00:14:40 +0400
>
>> Are you happy, or at least willing to accept, an approach that keep
>> things as they were with cgroups *compiled out*, or were you referring
>> to not in use == compiled in, but with no users?
>
> To me these are the same exact thing, because %99 of users will be running
> a kernel with every feature turned on in the Kconfig.

Ok.
Please let me know what do you think of the following patch. It is still 
crude, and applies on top of what I had, for simplicity. I can of course 
rework all the series for the next submission. The main idea is:

We basically don't care about accounting if all tasks are in the same, 
root, cgroup. So I am using static_branch to enable this code path when 
the first !root cgroup is created - a stronger statement than just 
enabled/disabled by a runtime option. This should cover every single 
user that is not *actively* using cgroups (I understand that most 
distros will not only compile it in, but also leave it enabled...). When 
this code path is disabled, we should be doing the same as before.

If you think this approach is valid, I am not left with the problem of
how to replace the fields when cgroups are enabled. But for that I guess 
I can just copy the struct proto (probably only 2, or at most 3 protos 
will need it anyway), and make the new sockets run on this new
structure.

Cheers

View attachment "test.patch" of type "text/plain" (14382 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ