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  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:	Mon, 19 Oct 2009 20:33:10 -0700
From: (Eric W. Biederman)
To:	Matt Helsley <>
Cc:	Oren Laadan <>,
	Daniel Lezcano <>,,,,
	Containers <>,
	Nathan Lynch <>,,,,,,
	Sukadev Bhattiprolu <>,,
	Alexey Dobriyan <>,,
	Pavel Emelyanov <>
Subject: Re: [RFC][v8][PATCH 0/10] Implement clone3() system call

Matt Helsley <> writes:

> On Mon, Oct 19, 2009 at 05:47:43PM -0400, Oren Laadan wrote:
>> Daniel Lezcano wrote:
>> > Sukadev Bhattiprolu wrote:
>> >> Daniel Lezcano [] wrote:
>> >>   
>> >>> Sukadev Bhattiprolu wrote:
>> >>>     
>> >>>> Subject: [RFC][v8][PATCH 0/10] Implement clone3() system call
>> >>>>
> <snip>
>> > Another point. It's another way to extend the exhausted clone  flags as 
>> > the cloneat can be called as a compatibility way, with cloneat(getpid(), 
>> > 0, ... )
>> Which is what the proposed new clone_....() does.
> Just to be clear -- Suka's proposing to extend the clone flags. However I
> don't believe reusing the "pid" parameters as Daniel seemed to suggest
> was ever part of Suka's proposed changes.
> <snip>
>> > I don't really see a difference between sys_restart(pid_t pid , int fd, 
>> > long flags) where pid_t is the topmost in the hierarchy, fd is a file 
>> > descriptor to a structure "pid_t * + struct clone_args *" and flags is 
>> > "PROCTREE".
> I think the difference has to do with keeping the code maintainable.
> Clone creates the process so it's already involved in allocating and
> assigning pids to the new task. Switching pids at sys_restart() would 
> add another point in the code where pids are allocated and assigned.
> This suggests we may have to worry about introducing new obscure races
> for anyone who's working on the pid allocator to be careful of. At
> least when all the code is "localized" to the clone paths we can be
> reasonably certain of proper maintenance.
> <snip>
>> I really really really hope we can settle down on *a* name,
>> *any* name, and move forward. Amen.
> clone3() seemed to be the leading contender from what I've read so far.
> Does anyone still object to clone3() after reading the whole thread?

I object to what clone3() is.  The name is not particularly interesting.

The sanity checks for assigning pids are missing and there is a todo
about it.  I am not comfortable with assigning pids to a new process
in a pid namespace with other processes user space processes executing
in it.

How we handle a clone extension depends critically on if we want to
create a processes for restart in user space or kernel space.

Could some one give me or point me at a strong case for creating the
processes for restart in user space?

The pid assignment code is currently ugly.  I asked that we just pass
in the min max pid pids that already exist into the core pid
assignment function and a constrained min/max that only admits a
single pid when we are allocating a struct pid for restart.  That was
not done and now we have a weird abortion with unnecessary special cases.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists