Re: [PATCHv2 0/2] clone: Support passing tls argument via C rather than pt_regs magic

* Josh Triplett [off-list ref] wrote:

clone has some of the quirkiest syscall handling in the kernel, with 
a pile of special cases, historical curiosities, and 
architecture-specific calling conventions.  In particular, clone 
with CLONE_SETTLS accepts a parameter "tls" that the C entry point 
completely ignores and some assembly entry points overwrite; 
instead, the low-level arch-specific code pulls the tls parameter 
out of the arch-specific register captured as part of pt_regs on 
entry to the kernel.  That's a massive hack, and it makes the 
arch-specific code only work when called via the specific existing 
syscall entry points; because of this hack, any new clone-like 
system call would have to accept an identical tls argument in 
exactly the same arch-specific position, rather than providing a 
unified system call entry point across architectures.

The first patch allows architectures to handle the tls argument via 
normal C parameter passing, if they opt in by selecting 
HAVE_COPY_THREAD_TLS.  The second patch makes 32-bit and 64-bit x86 
opt into this.

These two patches came out of the clone4 series, which isn't ready 
for this merge window, but these first two cleanup patches were 
entirely uncontroversial and have acks.  I'd like to go ahead and 
submit these two so that other architectures can begin building on 
top of this and opting into HAVE_COPY_THREAD_TLS.  However, I'm also 
happy to wait and send these through the next merge window (along 
with v3 of clone4) if anyone would prefer that.

v2: Move co-author from signoffs to a note in the commit message, as
    required by Ingo Molnar.

Josh Triplett (2):
  clone: Support passing tls argument via C rather than pt_regs magic
  x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit

 arch/Kconfig                 |  7 ++++++
 arch/x86/Kconfig             |  1 +
 arch/x86/ia32/ia32entry.S    |  2 +-
 arch/x86/kernel/process_32.c |  6 ++---
 arch/x86/kernel/process_64.c |  8 +++----
 include/linux/sched.h        | 14 +++++++++++
 include/linux/syscalls.h     |  6 ++---
 kernel/fork.c                | 55 +++++++++++++++++++++++++++++---------------
 8 files changed, 69 insertions(+), 30 deletions(-)

So I have no objections if Linus doesn't see a cleaner/better 
approach.

Thanks,

	Ingo