linux-kernel - Re: [PATCH 3/3] pids: Make it possible to clone tasks with given pids

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:	Fri, 11 Nov 2011 21:13:56 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Glauber Costa <glommer@...allels.com>,
	Nathan Lynch <ntl@...ox.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Serge Hallyn <serue@...ibm.com>,
	Daniel Lezcano <dlezcano@...ibm.com>
Subject: Re: [PATCH 3/3] pids: Make it possible to clone tasks with given
 pids

On 11/11/2011 09:02 PM, Tejun Heo wrote:
> Hello,
> 
> On Fri, Nov 11, 2011 at 08:49:50PM +0400, Pavel Emelyanov wrote:
>> 1 cpu 500k forks                                         - 37s
> 
> That's ~14k forks per sec.  Do you still think you need parallel
> forking?
> 
>> 2 cpus on different cores 500k forks on each in parallel - 39s
>> 4 cpus on different cores 500k forks on each in parallel - 41s
>>
>> 8 cpus 500k forks on each in parallel                    - 1m5s
>>
>> So the fork() scaling seems quite good to me.
> 
> Yeah, looks pretty good actually.  Hmmm, this is on a single socket w/
> shared cache where cacheline bouncing is quite cheap, right?  Also,
> how are those forking processes related?  On multiple sockets, it's
> gonna scale worse.  Dunno how much tho.
> 
> At any rate, if you do the rest in paralllel, whether forking is
> parallel or not is immaterial.  Let's just do something least
> intrusive.

Hm, so intrusiveness is your main concern here, I see.

OK, let's assume we go with sysctl setting the last_pid.

One of the major concerns with previous attempts have been - someone creates 
a process with a pid that was in use by some app recently and screws things 
up with pid reuse. My approach solves this, how can sysctl handle it? Allowing 
the last_pid change by the CAP_SYA_ADMIN only is not an option, since people
are looking forward to non-root restore.

> Thanks.
> 

--
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/