[GIT PULL] x86 cleanups for v5.7

[GIT PULL] x86 cleanups for v5.7

[Ingo Molnar]

Linus,

Please pull the latest x86-cleanups-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cleanups-for-linus

   # HEAD: a2150327250efa866c412caee84aaf05ebff9a8f Merge branch 'next.uaccess-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into x86/cleanups

This topic tree contains more commits than usual:

 - most of it are uaccess cleanups/reorganization by Al

 - there's a bunch of prototype declaration (--Wmissing-prototypes) cleanups

 - misc other cleanups all around the map.


  out-of-topic modifications in x86-cleanups-for-linus:
  -------------------------------------------------------
  include/linux/compat.h             # 39f16c1c0f14: x86: get rid of put_user_try
  include/linux/signal.h             # 119cd59fcfbe: x86: get rid of put_user_try

 Thanks,

	Ingo

------------------>
Al Viro (22):
      x86 user stack frame reads: switch to explicit __get_user()
      x86 kvm page table walks: switch to explicit __get_user()
      x86: switch sigframe sigset handling to explict __get_user()/__put_user()
      x86: get rid of small constant size cases in raw_copy_{to,from}_user()
      vm86: get rid of get_user_ex() use
      x86: get rid of get_user_ex() in ia32_restore_sigcontext()
      x86: get rid of get_user_ex() in restore_sigcontext()
      x86: kill get_user_{try,catch,ex}
      x86: switch save_v86_state() to unsafe_put_user()
      x86: switch setup_sigcontext() to unsafe_put_user()
      x86: switch ia32_setup_sigcontext() to unsafe_put_user()
      x86: get rid of put_user_try in {ia32,x32}_setup_rt_frame()
      x86: ia32_setup_sigcontext(): lift user_access_{begin,end}() into the callers
      x86: ia32_setup_frame(): consolidate uaccess areas
      x86: ia32_setup_rt_frame(): consolidate uaccess areas
      x86: get rid of put_user_try in __setup_rt_frame() (both 32bit and 64bit)
      x86: setup_sigcontext(): list user_access_{begin,end}() into callers
      x86: __setup_frame(): consolidate uaccess areas
      x86: __setup_rt_frame(): consolidate uaccess areas
      x86: x32_setup_rt_frame(): consolidate uaccess areas
      x86: unsafe_put-style macro for sigmask
      kill uaccess_try()

Anshuman Khandual (1):
      x86/mm: Drop pud_mknotpresent()

Benjamin Thiel (8):
      x86/iopl: Include prototype header for ksys_ioperm()
      x86/syscalls: Add prototypes for C syscall callbacks
      x86/cpu: Move prototype for get_umwait_control_msr() to a global location
      x86/cpu: Fix a -Wmissing-prototypes warning for init_ia32_feat_ctl()
      x86/platform/uv: Add a missing prototype for uv_bau_message_interrupt()
      x86/mm: Mark setup_emu2phys_nid() static
      x86/efi: Add a prototype for efi_arch_mem_reserve()
      x86/mm/set_memory: Fix -Wmissing-prototypes warnings

Martin Molnar (1):
      x86: Fix a handful of typos

Qiujun Huang (1):
      x86/alternatives: Mark text_poke_loc_init() static

Randy Dunlap (2):
      x86/configs: Slightly reduce defconfigs
      x86/jump_label: Move 'inline' keyword placement

afzal mohammed (1):
      x86: Replace setup_irq() by request_irq()


 Documentation/x86/exception-tables.rst |   6 -
 arch/x86/configs/i386_defconfig        |   2 -
 arch/x86/configs/x86_64_defconfig      |   2 -
 arch/x86/entry/common.c                |   1 +
 arch/x86/events/core.c                 |  27 +--
 arch/x86/ia32/ia32_signal.c            | 304 +++++++++++--------------
 arch/x86/include/asm/asm.h             |   6 -
 arch/x86/include/asm/mwait.h           |   2 +
 arch/x86/include/asm/pgtable.h         |   6 -
 arch/x86/include/asm/processor.h       |   1 -
 arch/x86/include/asm/set_memory.h      |   2 +
 arch/x86/include/asm/sigframe.h        |   6 +-
 arch/x86/include/asm/sighandling.h     |   3 -
 arch/x86/include/asm/syscall.h         |   5 +
 arch/x86/include/asm/uaccess.h         | 140 ------------
 arch/x86/include/asm/uaccess_32.h      |  27 ---
 arch/x86/include/asm/uaccess_64.h      | 108 +--------
 arch/x86/include/asm/uv/uv_bau.h       |   2 +
 arch/x86/kernel/alternative.c          |   4 +-
 arch/x86/kernel/cpu/feat_ctl.c         |   1 +
 arch/x86/kernel/cpu/umwait.c           |   1 +
 arch/x86/kernel/ioport.c               |   1 +
 arch/x86/kernel/irqinit.c              |  18 +-
 arch/x86/kernel/jump_label.c           |   2 +-
 arch/x86/kernel/nmi.c                  |   4 +-
 arch/x86/kernel/reboot.c               |   2 +-
 arch/x86/kernel/signal.c               | 399 +++++++++++++++------------------
 arch/x86/kernel/smpboot.c              |   2 +-
 arch/x86/kernel/stacktrace.c           |   6 +-
 arch/x86/kernel/time.c                 |  15 +-
 arch/x86/kernel/tsc.c                  |   2 +-
 arch/x86/kernel/tsc_sync.c             |   2 +-
 arch/x86/kernel/vm86_32.c              | 115 +++++-----
 arch/x86/kvm/mmu/paging_tmpl.h         |   2 +-
 arch/x86/kvm/vmx/vmx.c                 |   1 +
 arch/x86/kvm/vmx/vmx.h                 |   2 -
 arch/x86/mm/extable.c                  |  12 -
 arch/x86/mm/numa_emulation.c           |   2 +-
 arch/x86/mm/pat/set_memory.c           |   3 +
 arch/x86/mm/pti.c                      |   8 +-
 include/linux/compat.h                 |   9 +-
 include/linux/efi.h                    |   2 +
 include/linux/signal.h                 |   8 +-
 43 files changed, 445 insertions(+), 828 deletions(-)

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Tue, Mar 31, 2020 at 1:01 AM Ingo Molnar <mingo@kernel.org> wrote:
>
> This topic tree contains more commits than usual:
>
>  - most of it are uaccess cleanups/reorganization by Al

Lovely. This now makes my local boot-test tree be much closer to my
upstream tree, since I've had my clang asm-goto stuff in my boot tree
(and it had that series from Al).

Thanks.

                  Linus

Re: [GIT PULL] x86 cleanups for v5.7

[pr-tracker-bot]

The pull request you sent on Tue, 31 Mar 2020 10:01:11 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cleanups-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fdf5563a720004199324371c08071b8ea27bd994

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Tue, Mar 31, 2020 at 11:09 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Lovely. This now makes my local boot-test tree be much closer to my
> upstream tree, since I've had my clang asm-goto stuff in my boot tree
> (and it had that series from Al).

Side note: I've extended on the x86 uaccess cleanups a bit with a
couple of commits:

  x86: start using named parameters for low-level uaccess asms
  x86: get rid of 'rtype' argument to __get_user_asm() macro
  x86: get rid of 'rtype' argument to __put_user_goto() macro
  x86: get rid of 'errret' argument to __get_user_xyz() macross
  x86: remove __put_user_asm() infrastructure

which I _tried_ to make complete no-ops (comparing code generation
before and after). Sadly, one of them (the "get rid of 'rtype'
argument to __get_user_asm" one) causes gcc to pick different
registers for me because now the temporary variables have different
sizes.

(The others cause line number data changes, of course, but I didn't
see any _code_ changes).

So that one commit results in a lot of small noise changes to the
generated code for me, but the few I looked at closer all looked the
same (mostly just different register, sometimes odd improvements where
it avoided doing a stupid "andq $0xffffffff", and in one or two cases
it seemed to randomly just change the stack frame size, sometimes to
the better, sometimes to worse).

The others should be purely semantically identical.

It was all just small prep to make the patch I have for "asm goto with
outputs" have a smaller footprint - particularly when I try to then
make it work with compilers that don't have the capability, and I need
to have different output registers for that case.

I'm not planning on actually doing that patch this merge window, it's
just not ready enough. But just in case somebody (Al?) is still
working on the uaccess.h file, letting you know about my preparatory
cleanups.

                Linus

Re: [GIT PULL] x86 cleanups for v5.7

[Thomas Gleixner]

Linus,

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, Mar 31, 2020 at 11:09 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Lovely. This now makes my local boot-test tree be much closer to my
>> upstream tree, since I've had my clang asm-goto stuff in my boot tree
>> (and it had that series from Al).
>
> Side note: I've extended on the x86 uaccess cleanups a bit with a
> couple of commits:
>
>   x86: start using named parameters for low-level uaccess asms
>   x86: get rid of 'rtype' argument to __get_user_asm() macro
>   x86: get rid of 'rtype' argument to __put_user_goto() macro
>   x86: get rid of 'errret' argument to __get_user_xyz() macross
>   x86: remove __put_user_asm() infrastructure

A few comments:

  - x86 starts the short log after the colon with an uppercase
    letter

  - 'macross' is really gross :)

  - All commits lack a Link:https//lore.kernel.org/r/$MSG-ID tag. That
    might be an oversight or just reflecting the fact that these patches
    have never seen a mailing list.

    If my brain hasn't gone into complete wishful thinking mode there is
    general consenus that we want to have visability and traceability of
    changes including those which come from maintainers for various good
    reasons (The obvious 'fix a typo breaking the build' exempted).

    Of course that's at your discretion.

> which I _tried_ to make complete no-ops (comparing code generation
> before and after). Sadly, one of them (the "get rid of 'rtype'
> argument to __get_user_asm" one) causes gcc to pick different
> registers for me because now the temporary variables have different
> sizes.
>
> (The others cause line number data changes, of course, but I didn't
> see any _code_ changes).
>
> So that one commit results in a lot of small noise changes to the
> generated code for me, but the few I looked at closer all looked the
> same (mostly just different register, sometimes odd improvements where
> it avoided doing a stupid "andq $0xffffffff", and in one or two cases
> it seemed to randomly just change the stack frame size, sometimes to
> the better, sometimes to worse).

From a quick check I can confirm that the resulting text changes are
just random noise and I did not notice anything horrible in the
generated code either.

> The others should be purely semantically identical.
>
> It was all just small prep to make the patch I have for "asm goto with
> outputs" have a smaller footprint - particularly when I try to then
> make it work with compilers that don't have the capability, and I need
> to have different output registers for that case.
>
> I'm not planning on actually doing that patch this merge window, it's
> just not ready enough. But just in case somebody (Al?) is still
> working on the uaccess.h file, letting you know about my preparatory
> cleanups.

See above.

Thanks,

        tglx

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Wed, Apr 1, 2020 at 4:55 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
>   - x86 starts the short log after the colon with an uppercase
>     letter

Ahh. I actually tried to match the previous ones by Al, and they don't
follow that pattern.

>   - 'macross' is really gross :)

Oops.

>   - All commits lack a Link:https//lore.kernel.org/r/$MSG-ID tag. That
>     might be an oversight or just reflecting the fact that these patches
>     have never seen a mailing list.

Yeah. They were literally me looking at my patch in my other tree, and
trying to make incremental progress.

Nobody else has a working compiler to even test that patch, because
even upstream tip-of-the-day llvm mis-generates code (I have a patch
that makes it generate ok code, but that one isn't good enough to
actually go upstream in llvm).

I don't think I'll do any more, because the next stage really is to
actually have some CONFIG_ASM_GOTO_WITH_INPUTS code and then try to
make something similar to the SET_CC for this.

> From a quick check I can confirm that the resulting text changes are
> just random noise and I did not notice anything horrible in the
> generated code either.

Btw, do you guys have some better object code comparison thing than my
"objdump plus a few sed scripts to hide code movement effects"

               Linus

Re: [GIT PULL] x86 cleanups for v5.7

[Thomas Gleixner]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, Apr 1, 2020 at 4:55 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>>   - x86 starts the short log after the colon with an uppercase
>>     letter
>
> Ahh. I actually tried to match the previous ones by Al, and they don't
> follow that pattern.

Yeah. As Al's stuff was late already, I just took it as is.

>>   - All commits lack a Link:https//lore.kernel.org/r/$MSG-ID tag. That
>>     might be an oversight or just reflecting the fact that these patches
>>     have never seen a mailing list.
>
> Yeah. They were literally me looking at my patch in my other tree, and
> trying to make incremental progress.
>
> Nobody else has a working compiler to even test that patch, because
> even upstream tip-of-the-day llvm mis-generates code (I have a patch
> that makes it generate ok code, but that one isn't good enough to
> actually go upstream in llvm).

Fair enough.

> I don't think I'll do any more, because the next stage really is to
> actually have some CONFIG_ASM_GOTO_WITH_INPUTS code and then try to
> make something similar to the SET_CC for this.
>
>> From a quick check I can confirm that the resulting text changes are
>> just random noise and I did not notice anything horrible in the
>> generated code either.
>
> Btw, do you guys have some better object code comparison thing than my
> "objdump plus a few sed scripts to hide code movement effects"

Not sure whether s/sed/python/ makes it any better :)

Thanks,

        tglx

Re: [GIT PULL] x86 cleanups for v5.7

[Borislav Petkov]

On Wed, Apr 01, 2020 at 05:16:24PM -0700, Linus Torvalds wrote:
> Nobody else has a working compiler to even test that patch, because
> even upstream tip-of-the-day llvm mis-generates code (I have a patch
> that makes it generate ok code, but that one isn't good enough to
> actually go upstream in llvm).

Btw, looking at this:

https://reviews.llvm.org/rG50cac248773

and talking to a gcc guy (CCed), it should be also relatively easy to do
the fallthrough variant in gcc too so you could open a feature request
for that in the gcc bugzilla.

HTH.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Thu, Apr 2, 2020 at 6:40 AM Borislav Petkov <bp@alien8.de> wrote:
>
> Btw, looking at this:
>
> https://reviews.llvm.org/rG50cac248773
>
> and talking to a gcc guy (CCed), it should be also relatively easy to do
> the fallthrough variant in gcc too so you could open a feature request
> for that in the gcc bugzilla.

I absolutely want to have that in gcc too (I've mentioned it a couple
of times to people like rth), but I wanted to have more than just an
abstract test-case for it.

Sure, I could attach my current patch to the bug report, but honestly,
if I was a compiler guy, I'd care a lot less about a "hey, you have to
apply this patch that won't even _compile_ for you right now to a tree
you don't really care about that much" kind of bug-report than a "hey.
look, upstream Linux already does this, and with clang I get this
code, and with gcc it's much worse".

And to be honest, while I love the asm goto output, it's not *that*
noticeable. Particularly since we don't have a lot. This is the inner
loop of "strncpy_from_user" with the feature (and clang, of course):

  90: mov    (%r15,%r13,1),%rdx
  94: mov    %rdx,(%r12,%r13,1)
  98: mov    %rdx,%rsi
  9b: not    %rsi
  9e: and    %rax,%rsi
  a1: add    %rcx,%rdx
  a4: and    %rsi,%rdx
  a7: jne    ec <strncpy_from_user+0xec>
  a9: add    $0x8,%r13
  ad: add    $0xfffffffffffffff8,%rbx
  b1: cmp    $0x7,%rbx
  b5: ja     90 <strncpy_from_user+0x90>

And all the jumps are just for testing if there was a zero in there
(the jne in the middle) or testing for the length of the remaining
space (that "cmp $7;ja" at the end).

This is the same thing with gcc (and without asm goto, of course):

  91: lea    (%rcx,%rdi,1),%rdx
  95: mov    %rcx,0x0(%r13,%rax,1)
  9a: not    %rcx
  9d: and    %rcx,%rdx
  a0: mov    %rdx,%rcx
  a3: and    %rsi,%rcx
  a6: jne    108 <strncpy_from_user+0x108>
  a8: sub    $0x8,%rbx
  ac: add    $0x8,%rax
  b0: cmp    $0x7,%rbx
  b4: jbe    12d <strncpy_from_user+0x12d>
  b6: mov    %r8d,%edx
  b9: mov    0x0(%rbp,%rax,1),%rcx
  be: test   %edx,%edx
  c0: je     91 <strncpy_from_user+0x91>

and the only real difference in that inner loop from the asm goto is
that the gcc code has three extra instructions (don't ask me why gcc
decided to cache the value 0 in %r8, that just looks stupid):

  b6: mov    %r8d,%edx
...
  be: test   %edx,%edx
  c0: je     91 <strncpy_from_user+0x91>

(Ok, the code sequence looks completely different because the two
compilers also end up generating the function differently: gcc does
the user space load at the end of the loop while clang does it at the
top. That's probably related to the fact that gcc has to generate that
extra jump anyway, and decided to make that the loop finishing jump).

So realistically, it doesn't make a huge difference. It's a bit more
noticeable when you have the "multiple unsafe_get_user()s in a row"
pattern, but we don't really have that (we have lots of "multiple
unsafe_put_user() in a row").

Of course, one reason we don't have that pattern is that it generates
nasty code with gcc (exactly because of the extra test for each
access).

But while I love looking at small things like this, and I'd like to
have all compilers support it, I have to admit that it's not likely to
really _matter_ much.

                Linus

Re: [GIT PULL] x86 cleanups for v5.7

[Borislav Petkov]

On Thu, Apr 02, 2020 at 10:00:26AM -0700, Linus Torvalds wrote:
> But while I love looking at small things like this, and I'd like to
> have all compilers support it, I have to admit that it's not likely to
> really _matter_ much.

Yap, doesn't look like it.

But, TBH, I have myself wondered a couple of times, "dang, if that
asm goto only had outputs" so I'm thinking if gcc guys are bored and
wondering what to put in gcc11, why not this. :-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Thu, Apr 2, 2020 at 10:24 AM Borislav Petkov <bp@alien8.de> wrote:
>
> But, TBH, I have myself wondered a couple of times, "dang, if that
> asm goto only had outputs" so I'm thinking if gcc guys are bored and
> wondering what to put in gcc11, why not this. :-)

Yeah. And there are other places where we might want to use it.

Yes, it happens to be particularly useful for exception handling where
it avoids some register pressure (that can be a bigger deal than the
trivial extra instructions) and gets rid of the fixup code in a
different segment.

But it's potentially very useful for alternatives code too (where a
fallback alternatives could be "jump out-of-line to different code
entirely").

I originally wanted it for things like cmpxchg, but getting the
condition codes out of the asm and letting the compiler generate the
jump was even better.

            Linus

Re: [GIT PULL] x86 cleanups for v5.7

[Borislav Petkov]

On Thu, Apr 02, 2020 at 10:40:14AM -0700, Linus Torvalds wrote:
> Yeah. And there are other places where we might want to use it.

My only worry is that if we had that support, we would have to keep two
versions of the facilities which use it - one with asm goto with outputs
and one without.

Dunno how ugly that would become ...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Thu, Apr 2, 2020 at 11:04 AM Borislav Petkov <bp@alien8.de> wrote:
>
> My only worry is that if we had that support, we would have to keep two
> versions of the facilities which use it - one with asm goto with outputs
> and one without.

That's why it took three years for me to merge the "unsafe_put_user()"
stuff. I only did it once other issues had made PeterZ and people
decide that "asm goto is a required feature" for some of the other
stuff (static branches, whatever).

Because when it comes to small details like "we can remove a test and
a branch", it generally isn't worth the code complexity to have two
different copies. Particularly with how messy uaccess.h was.

The reason I did the additional uaccess.h cleanups was exactly because
I think I can have a CONFIG_ASM_GOTO_OUTPUTS thing, and minimize the
differences the same way we minimize them with CC_SET/CC_OUT doe the
__GCC_ASM_FLAG_OUTPUTS__ compiler support flag.

I haven't actually sat down to _do_ it, though. I spent several hours
on the cleanups as a break from pulling stuff during the merge window,
but this _is_ my busy time..

              Linus

Re: [GIT PULL] x86 cleanups for v5.7

[Jiri Kosina]

On Wed, 1 Apr 2020, Linus Torvalds wrote:

> Btw, do you guys have some better object code comparison thing than my
> "objdump plus a few sed scripts to hide code movement effects"

FWIW, I am routinely using Joerg's

	https://github.com/joergroedel/asmtool

for exactly this.

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] x86 cleanups for v5.7

[Linus Torvalds]

On Fri, Apr 3, 2020 at 6:47 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> FWIW, I am routinely using Joerg's
>
>         https://github.com/joergroedel/asmtool
>
> for exactly this.

Ahh, that seems to be on *.s files only.

I really prefer working on the object file basis, so that I can do a
diff of the whole kernel if required, and (if I care about just one
file) so that it shows the real code rather than all the odd section
stuff we end up having for alternatives etc.

               Linus