* [GIT PULL] x86 cleanups for v5.7 @ 2020-03-31 8:01 Ingo Molnar 2020-03-31 18:09 ` Linus Torvalds 2020-03-31 19:15 ` pr-tracker-bot 0 siblings, 2 replies; 15+ messages in thread From: Ingo Molnar @ 2020-03-31 8:01 UTC (permalink / raw) To: Linus Torvalds Cc: linux-kernel, Thomas Gleixner, Borislav Petkov, Peter Zijlstra, Andrew Morton 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(-) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-03-31 8:01 [GIT PULL] x86 cleanups for v5.7 Ingo Molnar @ 2020-03-31 18:09 ` Linus Torvalds 2020-04-01 22:45 ` Linus Torvalds 2020-03-31 19:15 ` pr-tracker-bot 1 sibling, 1 reply; 15+ messages in thread From: Linus Torvalds @ 2020-03-31 18:09 UTC (permalink / raw) To: Ingo Molnar Cc: Linux Kernel Mailing List, Thomas Gleixner, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-03-31 18:09 ` Linus Torvalds @ 2020-04-01 22:45 ` Linus Torvalds 2020-04-01 23:55 ` Thomas Gleixner 0 siblings, 1 reply; 15+ messages in thread From: Linus Torvalds @ 2020-04-01 22:45 UTC (permalink / raw) To: Ingo Molnar, Al Viro, Andy Lutomirski Cc: Linux Kernel Mailing List, Thomas Gleixner, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-01 22:45 ` Linus Torvalds @ 2020-04-01 23:55 ` Thomas Gleixner 2020-04-02 0:16 ` Linus Torvalds 0 siblings, 1 reply; 15+ messages in thread From: Thomas Gleixner @ 2020-04-01 23:55 UTC (permalink / raw) To: Linus Torvalds, Ingo Molnar, Al Viro, Andy Lutomirski Cc: Linux Kernel Mailing List, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-01 23:55 ` Thomas Gleixner @ 2020-04-02 0:16 ` Linus Torvalds 2020-04-02 8:19 ` Thomas Gleixner ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Linus Torvalds @ 2020-04-02 0:16 UTC (permalink / raw) To: Thomas Gleixner Cc: Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 0:16 ` Linus Torvalds @ 2020-04-02 8:19 ` Thomas Gleixner 2020-04-02 13:40 ` Borislav Petkov 2020-04-03 13:46 ` Jiri Kosina 2 siblings, 0 replies; 15+ messages in thread From: Thomas Gleixner @ 2020-04-02 8:19 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 0:16 ` Linus Torvalds 2020-04-02 8:19 ` Thomas Gleixner @ 2020-04-02 13:40 ` Borislav Petkov 2020-04-02 17:00 ` Linus Torvalds 2020-04-03 13:46 ` Jiri Kosina 2 siblings, 1 reply; 15+ messages in thread From: Borislav Petkov @ 2020-04-02 13:40 UTC (permalink / raw) To: Linus Torvalds Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Peter Zijlstra, Andrew Morton, Michael Matz 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 13:40 ` Borislav Petkov @ 2020-04-02 17:00 ` Linus Torvalds 2020-04-02 17:24 ` Borislav Petkov 0 siblings, 1 reply; 15+ messages in thread From: Linus Torvalds @ 2020-04-02 17:00 UTC (permalink / raw) To: Borislav Petkov Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Peter Zijlstra, Andrew Morton, Michael Matz 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 17:00 ` Linus Torvalds @ 2020-04-02 17:24 ` Borislav Petkov 2020-04-02 17:40 ` Linus Torvalds 0 siblings, 1 reply; 15+ messages in thread From: Borislav Petkov @ 2020-04-02 17:24 UTC (permalink / raw) To: Linus Torvalds Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Peter Zijlstra, Andrew Morton, Michael Matz 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 17:24 ` Borislav Petkov @ 2020-04-02 17:40 ` Linus Torvalds 2020-04-02 18:03 ` Borislav Petkov 0 siblings, 1 reply; 15+ messages in thread From: Linus Torvalds @ 2020-04-02 17:40 UTC (permalink / raw) To: Borislav Petkov Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Peter Zijlstra, Andrew Morton, Michael Matz 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 17:40 ` Linus Torvalds @ 2020-04-02 18:03 ` Borislav Petkov 2020-04-02 18:13 ` Linus Torvalds 0 siblings, 1 reply; 15+ messages in thread From: Borislav Petkov @ 2020-04-02 18:03 UTC (permalink / raw) To: Linus Torvalds Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Peter Zijlstra, Andrew Morton, Michael Matz 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 18:03 ` Borislav Petkov @ 2020-04-02 18:13 ` Linus Torvalds 0 siblings, 0 replies; 15+ messages in thread From: Linus Torvalds @ 2020-04-02 18:13 UTC (permalink / raw) To: Borislav Petkov Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Peter Zijlstra, Andrew Morton, Michael Matz 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-02 0:16 ` Linus Torvalds 2020-04-02 8:19 ` Thomas Gleixner 2020-04-02 13:40 ` Borislav Petkov @ 2020-04-03 13:46 ` Jiri Kosina 2020-04-03 17:03 ` Linus Torvalds 2 siblings, 1 reply; 15+ messages in thread From: Jiri Kosina @ 2020-04-03 13:46 UTC (permalink / raw) To: Linus Torvalds Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-04-03 13:46 ` Jiri Kosina @ 2020-04-03 17:03 ` Linus Torvalds 0 siblings, 0 replies; 15+ messages in thread From: Linus Torvalds @ 2020-04-03 17:03 UTC (permalink / raw) To: Jiri Kosina Cc: Thomas Gleixner, Ingo Molnar, Al Viro, Andy Lutomirski, Linux Kernel Mailing List, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [GIT PULL] x86 cleanups for v5.7 2020-03-31 8:01 [GIT PULL] x86 cleanups for v5.7 Ingo Molnar 2020-03-31 18:09 ` Linus Torvalds @ 2020-03-31 19:15 ` pr-tracker-bot 1 sibling, 0 replies; 15+ messages in thread From: pr-tracker-bot @ 2020-03-31 19:15 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, linux-kernel, Thomas Gleixner, Borislav Petkov, Peter Zijlstra, Andrew Morton 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-04-03 17:03 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-31 8:01 [GIT PULL] x86 cleanups for v5.7 Ingo Molnar 2020-03-31 18:09 ` Linus Torvalds 2020-04-01 22:45 ` Linus Torvalds 2020-04-01 23:55 ` Thomas Gleixner 2020-04-02 0:16 ` Linus Torvalds 2020-04-02 8:19 ` Thomas Gleixner 2020-04-02 13:40 ` Borislav Petkov 2020-04-02 17:00 ` Linus Torvalds 2020-04-02 17:24 ` Borislav Petkov 2020-04-02 17:40 ` Linus Torvalds 2020-04-02 18:03 ` Borislav Petkov 2020-04-02 18:13 ` Linus Torvalds 2020-04-03 13:46 ` Jiri Kosina 2020-04-03 17:03 ` Linus Torvalds 2020-03-31 19:15 ` pr-tracker-bot
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).