linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	Ingo Molnar <mingo@kernel.org>,
	Richard Biener <rguenther@suse.de>, Michael Matz <matz@suse.de>,
	gcc@gcc.gnu.org, Nadav Amit <namit@vmware.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Alok Kataria <akataria@vmware.com>,
	Christopher Li <sparse@chrisli.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Jan Beulich <JBeulich@suse.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Juergen Gross <jgross@suse.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Kees Cook <keescook@chromium.org>,
	linux-sparse@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	virtualization@lists.linux-foundation.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>,
	linux-xtensa@linux-xtensa.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: PROPOSAL: Extend inline asm syntax with size spec
Date: Thu, 25 Oct 2018 12:24:05 +0200	[thread overview]
Message-ID: <20181025102405.GE14020@nazgul.tnic> (raw)
In-Reply-To: <20181013193335.GD31650@zn.tnic>

Ping.

This is a good point in time, methinks, where kernel folk on CC here
should have a look at this and speak up whether it is useful for us in
this form.

Frankly, I'm a bit unsure on the aspect of us using this and supporting
old compilers which don't have it and new compilers which do. Because
the old compilers should get to see the now upstreamed assembler macros
and the new compilers will simply inline the "asm volatile inline"
constructs. And how ugly that would become...

I guess we can try this with smaller macros first and keep them all
nicely hidden in header files.

On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> Ok,
> 
> with Segher's help I've been playing with his patch ontop of bleeding
> edge gcc 9 and here are my observations. Please double-check me for
> booboos so that they can be addressed while there's time.
> 
> So here's what I see ontop of 4.19-rc7:
> 
> First marked the alternative asm() as inline and undeffed the "inline"
> keyword. I need to do that because of the funky games we do with
> "inline" redefinitions in include/linux/compiler_types.h.
> 
> And Segher hinted at either doing:
> 
> asm volatile inline(...
> 
> or
> 
> asm volatile __inline__(...
> 
> but both "inline" variants are defined as macros in that file.
> 
> Which means we either need to #undef inline before using it in asm() or
> come up with something cleverer.
> 
> Anyway, did this:
> 
> ---
> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
> index 4cd6a3b71824..7c0639087da7 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -165,11 +165,13 @@ static inline int alternatives_text_reserved(void *start, void *end)
>   * For non barrier like inlines please define new variants
>   * without volatile and memory clobber.
>   */
> +
> +#undef inline
>  #define alternative(oldinstr, newinstr, feature)                       \
> -       asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
> +       asm volatile inline(ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
>  
>  #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
> -       asm volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) ::: "memory")
> +       asm volatile inline(ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) ::: "memory")
>  
>  /*
>   * Alternative inline assembly with input.
> ---
> 
> Build failed at link time with:
> 
> arch/x86/boot/compressed/cmdline.o: In function `native_save_fl':
> cmdline.c:(.text+0x0): multiple definition of `native_save_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1e0): first defined here
> arch/x86/boot/compressed/cmdline.o: In function `native_restore_fl':
> cmdline.c:(.text+0x10): multiple definition of `native_restore_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1f0): first defined here
> arch/x86/boot/compressed/error.o: In function `native_save_fl':
> error.c:(.text+0x0): multiple definition of `native_save_fl'
> 
> which I had to fix with this:
> 
> ---
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index 15450a675031..0d772598c37c 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -14,8 +14,7 @@
>   */
>  
>  /* Declaration required for gcc < 4.9 to prevent -Werror=missing-prototypes */
> -extern inline unsigned long native_save_fl(void);
> -extern inline unsigned long native_save_fl(void)
> +static inline unsigned long native_save_fl(void)
>  {
>         unsigned long flags;
>  
> @@ -33,8 +32,7 @@ ex
> ---
> 
> That "extern inline" declaration looks fishy to me anyway, maybe not really
> needed ? Apparently, gcc < 4.9 complains with -Werror=missing-prototypes...
> 
> Then the build worked and the results look like this:
> 
>    text    data     bss     dec     hex filename
> 17287384        5040656 2019532 24347572        17383b4 vmlinux-before
> 17288020        5040656 2015436 24344112        1737630 vmlinux-2nd-version
> 
> so some inlining must be happening.
> 
> Then I did this:
> 
> ---
> diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
> index 9c5606d88f61..a0170344cf08 100644
> --- a/arch/x86/lib/usercopy_64.c
> +++ b/arch/x86/lib/usercopy_64.c
> @@ -20,7 +20,7 @@ unsigned long __clear_user(void __user *addr, unsigned long size)
>         /* no memory constraint because it doesn't change any memory gcc knows
>            about */
>         stac();
> -       asm volatile(
> +       asm volatile inline(
>                 "       testq  %[size8],%[size8]\n"
>                 "       jz     4f\n"
>                 "0:     movq $0,(%[dst])\n"
> ---
> 
> to force inlining of a somewhat bigger asm() statement. And yap, more
> got inlined:
> 
>    text    data     bss     dec     hex filename
> 17287384        5040656 2019532 24347572        17383b4 vmlinux-before
> 17288020        5040656 2015436 24344112        1737630 vmlinux-2nd-version
> 17288076        5040656 2015436 24344168        1737668 vmlinux-2nd-version__clear_user
> 
> so more stuff gets inlined.
> 
> Looking at the asm output, it had before:
> 
> ---
> clear_user:
> # ./arch/x86/include/asm/current.h:15:  return this_cpu_read_stable(current_task);
> #APP
> # 15 "./arch/x86/include/asm/current.h" 1
>         movq %gs:current_task,%rax      #, pfo_ret__
> # 0 "" 2
> # arch/x86/lib/usercopy_64.c:51:        if (access_ok(VERIFY_WRITE, to, n))
> #NO_APP
>         movq    2520(%rax), %rdx        # pfo_ret___12->thread.addr_limit.seg, _1
>         movq    %rdi, %rax      # to, tmp93
>         addq    %rsi, %rax      # n, tmp93
>         jc      .L3     #,
> # arch/x86/lib/usercopy_64.c:51:        if (access_ok(VERIFY_WRITE, to, n))
>         cmpq    %rax, %rdx      # tmp93, _1
>         jb      .L3     #,
> # arch/x86/lib/usercopy_64.c:52:                return __clear_user(to, n);
>         jmp     __clear_user    #
> ---
> 
> note the JMP to __clear_user. After marking the asm() in __clear_user() as
> inline, clear_user() inlines __clear_user() directly:
> 
> ---
> clear_user:
> # ./arch/x86/include/asm/current.h:15:  return this_cpu_read_stable(current_task);
> #APP
> # 15 "./arch/x86/include/asm/current.h" 1
>         movq %gs:current_task,%rax      #, pfo_ret__
> # 0 "" 2
> # arch/x86/lib/usercopy_64.c:51:        if (access_ok(VERIFY_WRITE, to, n))
> #NO_APP
>         movq    2520(%rax), %rdx        # pfo_ret___12->thread.addr_limit.seg, _1
>         movq    %rdi, %rax      # to, tmp95
>         addq    %rsi, %rax      # n, tmp95
>         jc      .L8     #,
> # arch/x86/lib/usercopy_64.c:51:        if (access_ok(VERIFY_WRITE, to, n))
>         cmpq    %rax, %rdx      # tmp95, _1
>         jb      .L8     #,
> # ./arch/x86/include/asm/smap.h:58:     alternative("", __stringify(__ASM_STAC), X86_FEATURE_SMAP);
> ...
> 
> this last line is the stac() macro which gets inlined due to the
> alternative() inlined macro above.
> 
> So I guess this all looks like what we wanted.
> 
> And if this lands in gcc9, we would need to do a asm_volatile() macro
> which is defined differently based on the compiler used.
> 
> Thoughts, suggestions, etc are most welcome.
> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  parent reply	other threads:[~2018-10-25 10:23 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 21:30 [PATCH v9 00/10] x86: macrofying inline asm Nadav Amit
2018-10-03 21:30 ` [PATCH v9 01/10] xtensa: defining LINKER_SCRIPT for the linker script Nadav Amit
2018-10-04 10:00   ` [tip:x86/build] kbuild/arch/xtensa: Define " tip-bot for Nadav Amit
2018-10-03 21:30 ` [PATCH v9 02/10] Makefile: Prepare for using macros for inline asm Nadav Amit
2018-10-04 10:01   ` [tip:x86/build] kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs tip-bot for Nadav Amit
2018-11-06 18:57   ` [PATCH v9 02/10] Makefile: Prepare for using macros for inline asm Logan Gunthorpe
2018-11-06 19:18     ` Nadav Amit
2018-11-06 20:01       ` Logan Gunthorpe
2018-11-07 18:01         ` Nadav Amit
2018-11-07 18:53           ` Logan Gunthorpe
2018-11-07 18:56             ` Nadav Amit
2018-11-07 21:43               ` Logan Gunthorpe
2018-11-07 21:50                 ` hpa
2018-11-08  6:18                   ` Nadav Amit
2018-11-08 17:14                     ` Logan Gunthorpe
2018-11-08 19:54                       ` Nadav Amit
2018-11-08 20:00                         ` Logan Gunthorpe
2018-11-08 20:18                           ` Nadav Amit
2018-11-10 22:04                             ` Nadav Amit
2018-11-13  4:56                               ` Logan Gunthorpe
2018-10-03 21:30 ` [PATCH v9 03/10] x86: objtool: use asm macro for better compiler decisions Nadav Amit
2018-10-04 10:02   ` [tip:x86/build] x86/objtool: Use asm macros to work around GCC inlining bugs tip-bot for Nadav Amit
2018-10-03 21:30 ` [PATCH v9 04/10] x86: refcount: prevent gcc distortions Nadav Amit
2018-10-04  7:57   ` Ingo Molnar
2018-10-04  8:33     ` Ingo Molnar
2018-10-04  8:40       ` hpa
2018-10-04  8:56         ` Ingo Molnar
2018-10-04  8:56         ` Nadav Amit
2018-10-04  9:02           ` hpa
2018-10-04  9:16             ` Ingo Molnar
2018-10-04 19:33               ` H. Peter Anvin
2018-10-04 20:05                 ` Nadav Amit
2018-10-04 20:08                   ` H. Peter Anvin
2018-10-04 20:29                 ` Andy Lutomirski
2018-10-04 23:11                   ` H. Peter Anvin
2018-10-06  1:40                 ` Rasmus Villemoes
2018-10-04  9:12           ` Ingo Molnar
2018-10-04  9:17             ` hpa
2018-10-04  9:30             ` Nadav Amit
2018-10-04  9:45               ` Ingo Molnar
2018-10-04 10:23                 ` Nadav Amit
2018-10-05  9:31                   ` Ingo Molnar
2018-10-05 11:20                     ` Borislav Petkov
2018-10-05 12:52                       ` Ingo Molnar
2018-10-05 20:27                     ` [PATCH 0/3] Macrofying inline asm rebased Nadav Amit
2018-10-05 20:27                       ` [PATCH 1/3] x86/extable: Macrofy inline assembly code to work around GCC inlining bugs Nadav Amit
2018-10-06 14:42                         ` [tip:x86/build] " tip-bot for Nadav Amit
2018-10-05 20:27                       ` [PATCH 2/3] x86/cpufeature: " Nadav Amit
2018-10-06 14:43                         ` [tip:x86/build] " tip-bot for Nadav Amit
2018-10-05 20:27                       ` [PATCH 3/3] x86/jump-labels: " Nadav Amit
2018-10-06 14:44                         ` [tip:x86/build] " tip-bot for Nadav Amit
2018-10-08  2:17                     ` [PATCH v9 04/10] x86: refcount: prevent gcc distortions Nadav Amit
2018-10-04  8:40     ` Nadav Amit
2018-10-04  9:01       ` Ingo Molnar
2018-10-04 10:02   ` [tip:x86/build] x86/refcount: Work around GCC inlining bug tip-bot for Nadav Amit
2018-10-03 21:30 ` [PATCH v9 05/10] x86: alternatives: macrofy locks for better inlining Nadav Amit
2018-10-04 10:03   ` [tip:x86/build] x86/alternatives: Macrofy lock prefixes to work around GCC inlining bugs tip-bot for Nadav Amit
2018-10-03 21:30 ` [PATCH v9 06/10] x86: bug: prevent gcc distortions Nadav Amit
2018-10-04 10:03   ` [tip:x86/build] x86/bug: Macrofy the BUG table section handling, to work around GCC inlining bugs tip-bot for Nadav Amit
2018-10-03 21:30 ` [PATCH v9 07/10] x86: prevent inline distortion by paravirt ops Nadav Amit
2018-10-04 10:04   ` [tip:x86/build] x86/paravirt: Work around GCC inlining bugs when compiling " tip-bot for Nadav Amit
2018-10-03 21:30 ` [PATCH v9 08/10] x86: extable: use macros instead of inline assembly Nadav Amit
2018-10-03 21:30 ` [PATCH v9 09/10] x86: cpufeature: " Nadav Amit
2018-10-03 21:31 ` [PATCH v9 10/10] x86: jump-labels: " Nadav Amit
2018-10-07  9:18 ` PROPOSAL: Extend inline asm syntax with size spec Borislav Petkov
     [not found]   ` <20181007132228.GJ29268@gate.crashing.org>
2018-10-07 14:13     ` Borislav Petkov
2018-10-07 15:14       ` Segher Boessenkool
2018-10-08  5:58         ` Ingo Molnar
2018-10-08  7:53           ` Segher Boessenkool
2018-10-07 15:53     ` Michael Matz
2018-10-08  6:13       ` Ingo Molnar
2018-10-08  8:18         ` Segher Boessenkool
2018-10-08  7:31       ` Segher Boessenkool
2018-10-08  9:07         ` Richard Biener
2018-10-08 10:02           ` Segher Boessenkool
2018-10-09 14:53           ` Segher Boessenkool
2018-10-10  6:35             ` Ingo Molnar
2018-10-10  7:12             ` Richard Biener
2018-10-10  7:22               ` Ingo Molnar
2018-10-10  8:03                 ` Segher Boessenkool
2018-10-10  8:19                   ` Borislav Petkov
2018-10-10  8:35                     ` Richard Biener
2018-10-10 18:54                     ` Segher Boessenkool
2018-10-10 19:14                       ` Borislav Petkov
2018-10-13 19:33                         ` Borislav Petkov
2018-10-13 21:14                           ` Alexander Monakov
2018-10-13 21:30                             ` Borislav Petkov
2018-10-25 10:24                           ` Borislav Petkov [this message]
2018-10-31 12:55                           ` Peter Zijlstra
2018-10-31 13:11                             ` Peter Zijlstra
2018-10-31 16:31                             ` Segher Boessenkool
2018-11-01  5:20                             ` Joe Perches
2018-11-01  9:01                               ` Peter Zijlstra
2018-11-01  9:20                                 ` Joe Perches
2018-11-01 11:15                                   ` Peter Zijlstra
2018-12-27  4:47                             ` Masahiro Yamada
2018-10-10 10:29                   ` Richard Biener
2018-10-10  7:53               ` Segher Boessenkool
2018-10-10 16:31             ` Nadav Amit
2018-10-10 19:21               ` Segher Boessenkool
2018-10-11  7:04               ` Richard Biener
2018-11-29 11:46             ` Masahiro Yamada
2018-11-29 12:25               ` Segher Boessenkool
2018-11-30  9:06                 ` Boris Petkov
2018-11-30 13:16                   ` Segher Boessenkool
2018-12-10  8:16                     ` Masahiro Yamada
2018-11-29 13:07               ` Borislav Petkov
2018-11-29 13:09                 ` Richard Biener
2018-11-29 13:16                   ` Borislav Petkov
2018-11-29 13:24                     ` Richard Biener
2018-10-08 16:24       ` David Laight
2018-10-07 16:09   ` Nadav Amit
2018-10-07 16:46     ` Richard Biener
2018-10-07 19:06       ` Nadav Amit
2018-10-07 19:52         ` Jeff Law
2018-10-08  7:46         ` Richard Biener

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=20181025102405.GE14020@nazgul.tnic \
    --to=bp@alien8.de \
    --cc=JBeulich@suse.com \
    --cc=akataria@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@zankel.net \
    --cc=gcc@gcc.gnu.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=matz@suse.de \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namit@vmware.com \
    --cc=peterz@infradead.org \
    --cc=pombredanne@nexb.com \
    --cc=rguenther@suse.de \
    --cc=sam@ravnborg.org \
    --cc=segher@kernel.crashing.org \
    --cc=sparse@chrisli.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /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).