From: Andy Lutomirski <luto@amacapital.net>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>, Kees Cook <keescook@chromium.org>,
Oleg Nesterov <oleg@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>, Rik van Riel <riel@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Thiago Macieira <thiago.macieira@intel.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
X86 ML <x86@kernel.org>
Subject: Re: [PATCH 2/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit
Date: Fri, 13 Mar 2015 15:45:16 -0700 [thread overview]
Message-ID: <CALCETrW3kJSVz4ffVC6YdB+ELukhOHNgPFKZSziMq5nn_Nq3Zg@mail.gmail.com> (raw)
In-Reply-To: <20150313224319.GA11282@cloud>
On Fri, Mar 13, 2015 at 3:43 PM, <josh@joshtriplett.org> wrote:
> On Fri, Mar 13, 2015 at 03:38:31PM -0700, Andy Lutomirski wrote:
>> On Fri, Mar 13, 2015 at 3:31 PM, <josh@joshtriplett.org> wrote:
>> > On Fri, Mar 13, 2015 at 03:01:16PM -0700, Andy Lutomirski wrote:
>> >> On Thu, Mar 12, 2015 at 6:40 PM, Josh Triplett <josh@joshtriplett.org> wrote:
>> >> > For 32-bit userspace on a 64-bit kernel, this requires modifying
>> >> > stub32_clone to actually swap the appropriate arguments to match
>> >> > CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
>> >> > broken.
>> >> >
>> >> > Signed-off-by: Josh Triplett <josh@joshtriplett.org>
>> >> > Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
>> >> > ---
>> >> > arch/x86/Kconfig | 1 +
>> >> > arch/x86/ia32/ia32entry.S | 2 +-
>> >> > arch/x86/kernel/process_32.c | 6 +++---
>> >> > arch/x86/kernel/process_64.c | 8 ++++----
>> >> > 4 files changed, 9 insertions(+), 8 deletions(-)
>> >> >
>> >> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> >> > index b7d31ca..4960b0d 100644
>> >> > --- a/arch/x86/Kconfig
>> >> > +++ b/arch/x86/Kconfig
>> >> > @@ -124,6 +124,7 @@ config X86
>> >> > select MODULES_USE_ELF_REL if X86_32
>> >> > select MODULES_USE_ELF_RELA if X86_64
>> >> > select CLONE_BACKWARDS if X86_32
>> >> > + select HAVE_COPY_THREAD_TLS
>> >> > select ARCH_USE_BUILTIN_BSWAP
>> >> > select ARCH_USE_QUEUE_RWLOCK
>> >> > select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
>> >> > diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
>> >> > index 156ebca..0286735 100644
>> >> > --- a/arch/x86/ia32/ia32entry.S
>> >> > +++ b/arch/x86/ia32/ia32entry.S
>> >> > @@ -487,7 +487,7 @@ GLOBAL(\label)
>> >> > ALIGN
>> >> > GLOBAL(stub32_clone)
>> >> > leaq sys_clone(%rip),%rax
>> >> > - mov %r8, %rcx
>> >> > + xchg %r8, %rcx
>> >> > jmp ia32_ptregs_common
>> >>
>> >> Do I understand correct that whatever function this is a stub for just
>> >> takes its arguments in the wrong order? If so, can we just fix it
>> >> instead of using xchg here?
>> >
>> > 32-bit x86 and 64-bit x86 take the arguments to clone in a different
>> > order, and stub32_clone fixes up the argument order then calls the
>> > 64-bit sys_clone.
>> >
>> > I'd love to see *all* the 32-on-64 compat stubs for clone rewritten in C
>> > under CONFIG_COMPAT. However, doing so would require encoding the
>> > knowledge for each 64-bit architecture for how its corresponding 32-bit
>> > architecture accepts arguments to clone, which is information that the
>> > current CONFIG_CLONE_BACKWARDS{1,2,3} don't include; it would then
>> > require cleaning up all the architecture-specific assembly stubs for
>> > 32-bit clone entry points.
>> >
>> > In the meantime, doing that *just* for 32-bit x86 on 64-bit x86 doesn't
>> > seem worth it, since it would require adding a new C entry point for
>> > compat_sys_clone under arch/x86 somewhere.
>> >
>> > One cleanup at a time. :)
>>
>> Fine w/ me.
>
> Thanks.
>
>> >
>> >> In general, I much prefer C code to new asm where it makes sense to
>> >> make this tradeoff.
>> >
>> > Agreed completely. However, this is at least conservation-of-asm, or
>> > reduction if you consider the pt_regs argument-grabbing hack to be
>> > asm-esque code.
>> >
>> >> Other than that, this is a huge improvement. You'll have minor
>> >> conflicts against -tip, though.
>> >
>> > Right, I've seen your current changes there. Should be a trivial merge
>> > though.
>> >
>> > Would you mind providing an ack for the series, or at least for the
>> > first two patches?
>>
>> I can give you an ok-in-principle on the first two. I'd need to stare
>> at the awful code for a bit to understand the @!*&! clone variants to
>> really ack them convincingly.
>
> I'd definitely appreciate the staring. :)
>
>> OTOH, it would be rather surprising if you messed it up in a way that
>> still boots on all three variants (native 32-bit, native 64-bit, and
>> compat).
>>
>> So, for the first two patches:
>>
>> Acked-by: Andy Lutomirski <luto@kernel.org> # assuming all bitnesses boot
>
> I did test all three, not just with booting but with a thread-local
> storage test.
And it's fairly clear that no one ever tested clone-based TLS in 32
bits from a 64-bit ELF binary, because it was broken until very
recently :-/
This stuff is too magical and too poorly documented for my tastes.
--Andy
next prev parent reply other threads:[~2015-03-13 22:45 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 1:40 [PATCH 0/6] CLONE_FD: Task exit notification via file descriptor Josh Triplett
2015-03-13 1:40 ` [PATCH 1/6] clone: Support passing tls argument via C rather than pt_regs magic Josh Triplett
2015-03-13 1:40 ` [PATCH 2/6] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit Josh Triplett
2015-03-13 22:01 ` Andy Lutomirski
2015-03-13 22:31 ` josh
2015-03-13 22:38 ` Andy Lutomirski
2015-03-13 22:43 ` josh
2015-03-13 22:45 ` Andy Lutomirski [this message]
2015-03-13 23:01 ` josh
2015-03-13 1:40 ` [PATCH 3/6] Introduce a new clone4 syscall with more flag bits and extensible arguments Josh Triplett
2015-03-13 1:40 ` [PATCH 4/6] signal: Factor out a helper function to process task_struct exit_code Josh Triplett
2015-03-13 1:40 ` [PATCH 5/6] fs: Make alloc_fd non-private Josh Triplett
2015-03-13 1:41 ` [PATCH 6/6] clone4: Introduce new CLONE_FD flag to get task exit notification via fd Josh Triplett
2015-03-13 16:21 ` Oleg Nesterov
2015-03-13 19:57 ` josh
2015-03-13 21:34 ` Andy Lutomirski
2015-03-13 22:20 ` josh
2015-03-13 22:28 ` Andy Lutomirski
2015-03-13 22:34 ` josh
2015-03-13 22:38 ` Andy Lutomirski
2015-03-14 14:14 ` Oleg Nesterov
2015-03-14 14:32 ` Oleg Nesterov
2015-03-14 18:38 ` Thiago Macieira
2015-03-14 18:54 ` Oleg Nesterov
2015-03-14 22:03 ` Josh Triplett
2015-03-14 22:26 ` Thiago Macieira
2015-03-14 19:01 ` Josh Triplett
2015-03-14 19:18 ` Oleg Nesterov
2015-03-14 19:47 ` Oleg Nesterov
2015-03-14 20:14 ` Josh Triplett
2015-03-14 20:30 ` Oleg Nesterov
2015-03-14 22:14 ` Josh Triplett
2015-03-14 20:03 ` Josh Triplett
2015-03-14 20:20 ` Oleg Nesterov
2015-03-14 22:09 ` Josh Triplett
2015-03-14 14:35 ` Oleg Nesterov
2015-03-14 19:15 ` Josh Triplett
2015-03-14 19:24 ` Oleg Nesterov
2015-03-14 19:48 ` Josh Triplett
2015-03-13 1:41 ` [PATCH] clone4.2: New manpage documenting clone4(2) Josh Triplett
2015-03-13 2:07 ` [PATCH 0/6] CLONE_FD: Task exit notification via file descriptor Thiago Macieira
2015-03-13 16:05 ` David Drysdale
2015-03-13 19:42 ` Josh Triplett
2015-03-13 21:16 ` Thiago Macieira
2015-03-13 21:44 ` josh
2015-03-13 21:33 ` Andy Lutomirski
2015-03-13 21:45 ` josh
2015-03-13 21:51 ` Andy Lutomirski
2015-03-14 1:11 ` Thiago Macieira
2015-03-14 19:03 ` Thiago Macieira
2015-03-14 19:29 ` Josh Triplett
2015-03-15 10:18 ` David Drysdale
2015-03-15 10:59 ` Josh Triplett
2015-03-15 8:55 ` David Drysdale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrW3kJSVz4ffVC6YdB+ELukhOHNgPFKZSziMq5nn_Nq3Zg@mail.gmail.com \
--to=luto@amacapital.net \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=thiago.macieira@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).