[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ABBFE77.30402@librato.com>
Date: Thu, 24 Sep 2009 19:19:19 -0400
From: Oren Laadan <orenl@...rato.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org,
Containers <containers@...ts.linux-foundation.org>,
Nathan Lynch <nathanl@...tin.ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>, hpa@...or.com,
mingo@...e.hu, torvalds@...ux-foundation.org,
Alexey Dobriyan <adobriyan@...il.com>,
Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [RFC][v7][PATCH 0/9] Implement clone2() system call
Arnd Bergmann wrote:
> On Friday 25 September 2009, Oren Laadan wrote:
>> In this form, you place a constraints on where userspace may
>> place the {parent,child}_tid variable, and require that this
>> particular clone_struct remain valid memory in the parent until
>> the child terminates. This may break existing programs that
>> use this (threads libraries ?)
>
> No existing program uses sys_clone2, and the kernel function
> may well differ from the user space calling conventions, which
> are not bound by the six-argument limitation.
>
> So a clone2 library call could set up the structure with the
> arguments to the real syscall, call into the kernel and
> copy the output data back into the pointers it was given by
> the user.
That may work well for parent_tid, however child_tid is also
kept on the task_struct and written to when the child exits,
and there is no explicit user-space wrapper on that.
Also, I may be mistaken, but I thought that the idea of these
was that the kernel writes them to user space, so other threads
may see them quickly, _before_ the parent returns to userspace;
otherwise, the parent (at the library) could himself copy the
return value.
Oren.
--
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/
Powered by blists - more mailing lists