netdev - Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers

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]

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)