1. 17 3月, 2015 2 次提交
  2. 10 3月, 2015 3 次提交
  3. 07 3月, 2015 3 次提交
    • D
      x86/asm: Optimize unnecessarily wide TEST instructions · 3e1aa7cb
      Denys Vlasenko 提交于
      By the nature of the TEST operation, it is often possible to test
      a narrower part of the operand:
      
          "testl $3,  mem"  ->  "testb $3, mem",
          "testq $3, %rcx"  ->  "testb $3, %cl"
      
      This results in shorter instructions, because the TEST instruction
      has no sign-entending byte-immediate forms unlike other ALU ops.
      
      Note that this change does not create any LCP (Length-Changing Prefix)
      stalls, which happen when adding a 0x66 prefix, which happens when
      16-bit immediates are used, which changes such TEST instructions:
      
        [test_opcode] [modrm] [imm32]
      
      to:
      
        [0x66] [test_opcode] [modrm] [imm16]
      
      where [imm16] has a *different length* now: 2 bytes instead of 4.
      This confuses the decoder and slows down execution.
      
      REX prefixes were carefully designed to almost never hit this case:
      adding REX prefix does not change instruction length except MOVABS
      and MOV [addr],RAX instruction.
      
      This patch does not add instructions which would use a 0x66 prefix,
      code changes in assembly are:
      
          -48 f7 07 01 00 00 00 	testq  $0x1,(%rdi)
          +f6 07 01             	testb  $0x1,(%rdi)
          -48 f7 c1 01 00 00 00 	test   $0x1,%rcx
          +f6 c1 01             	test   $0x1,%cl
          -48 f7 c1 02 00 00 00 	test   $0x2,%rcx
          +f6 c1 02             	test   $0x2,%cl
          -41 f7 c2 01 00 00 00 	test   $0x1,%r10d
          +41 f6 c2 01          	test   $0x1,%r10b
          -48 f7 c1 04 00 00 00 	test   $0x4,%rcx
          +f6 c1 04             	test   $0x4,%cl
          -48 f7 c1 08 00 00 00 	test   $0x8,%rcx
          +f6 c1 08             	test   $0x8,%cl
      
      Linus further notes:
      
         "There are no stalls from using 8-bit instruction forms.
      
          Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
          *could* cause problems if it ends up having forwarding issues, so that
          instead of just forwarding the result, you end up having to wait for
          it to be stable in the L1 cache (or possibly the register file). The
          forwarding from the store buffer is simplest and most reliable if the
          read is done at the exact same address and the exact same size as the
          write that gets forwarded.
      
          But that's true only if:
      
           (a) the write was very recent and is still in the write queue. I'm
               not sure that's the case here anyway.
      
           (b) on at least most Intel microarchitectures, you have to test a
               different byte than the lowest one (so forwarding a 64-bit write
               to a 8-bit read ends up working fine, as long as the 8-bit read
               is of the low 8 bits of the written data).
      
          A very similar issue *might* show up for registers too, not just
          memory writes, if you use 'testb' with a high-byte register (where
          instead of forwarding the value from the original producer it needs to
          go through the register file and then shifted). But it's mainly a
          problem for store buffers.
      
          But afaik, the way Denys changed the test instructions, neither of the
          above issues should be true.
      
          The real problem for store buffer forwarding tends to be "write 8
          bits, read 32 bits". That can be really surprisingly expensive,
          because the read ends up having to wait until the write has hit the
          cacheline, and we might talk tens of cycles of latency here. But
          "write 32 bits, read the low 8 bits" *should* be fast on pretty much
          all x86 chips, afaik."
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Drewry <wad@chromium.org>
      Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3e1aa7cb
    • A
      x86/asm/entry: Replace this_cpu_sp0() with current_top_of_stack() and fix it on x86_32 · a7fcf28d
      Andy Lutomirski 提交于
      I broke 32-bit kernels.  The implementation of sp0 was correct
      as far as I can tell, but sp0 was much weirder on x86_32 than I
      realized.  It has the following issues:
      
       - Init's sp0 is inconsistent with everything else's: non-init tasks
         are offset by 8 bytes.  (I have no idea why, and the comment is unhelpful.)
      
       - vm86 does crazy things to sp0.
      
      Fix it up by replacing this_cpu_sp0() with
      current_top_of_stack() and using a new percpu variable to track
      the top of the stack on x86_32.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 75182b16 ("x86/asm/entry: Switch all C consumers of kernel_stack to this_cpu_sp0()")
      Link: http://lkml.kernel.org/r/d09dbe270883433776e0cbee3c7079433349e96d.1425692936.git.luto@amacapital.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a7fcf28d
    • A
      x86/asm/entry: Delay loading sp0 slightly on task switch · b27559a4
      Andy Lutomirski 提交于
      The change:
      
        75182b16 ("x86/asm/entry: Switch all C consumers of kernel_stack to this_cpu_sp0()")
      
      had the unintended side effect of changing the return value of
      current_thread_info() during part of the context switch process.
      Change it back.
      
      This has no effect as far as I can tell -- it's just for
      consistency.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/9fcaa47dd8487db59eed7a3911b6ae409476763e.1425692936.git.luto@amacapital.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b27559a4
  4. 06 3月, 2015 6 次提交
  5. 05 3月, 2015 17 次提交
  6. 04 3月, 2015 9 次提交
    • I
      Merge tag 'alternatives_padding' of... · f8e92fb4
      Ingo Molnar 提交于
      Merge tag 'alternatives_padding' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp into x86/asm
      
      Pull alternative instructions framework improvements from Borislav Petkov:
      
       "A more involved rework of the alternatives framework to be able to
        pad instructions and thus make using the alternatives macros more
        straightforward and without having to figure out old and new instruction
        sizes but have the toolchain figure that out for us.
      
        Furthermore, it optimizes JMPs used so that fetch and decode can be
        relieved with smaller versions of the JMPs, where possible.
      
        Some stats:
      
          x86_64 defconfig:
      
          Alternatives sites total:               2478
          Total padding added (in Bytes):         6051
      
        The padding is currently done for:
      
          X86_FEATURE_ALWAYS
          X86_FEATURE_ERMS
          X86_FEATURE_LFENCE_RDTSC
          X86_FEATURE_MFENCE_RDTSC
          X86_FEATURE_SMAP
      
        This is with the latest version of the patchset. Of course, on each
        machine the alternatives sites actually being patched are a proper
        subset of the total number."
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f8e92fb4
    • I
      Merge tag 'v4.0-rc2' into x86/asm, to refresh the tree · d2c032e3
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      d2c032e3
    • B
      x86/compat: Remove sys32_vm86_warning · 7e8e385a
      Brian Gerst 提交于
      The check against lastcomm is racy, and the message it produces
      isn't necessary.  vm86 support can be disabled on a 32-bit
      kernel also, and doesn't have this message.  Switch to
      sys_ni_syscall instead.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1425439896-8322-4-git-send-email-brgerst@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7e8e385a
    • B
      x86/compat: Merge native and compat 32-bit syscall tables · 2aa4a710
      Brian Gerst 提交于
      Combine the 32-bit syscall tables into one file.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1425439896-8322-3-git-send-email-brgerst@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2aa4a710
    • B
      x86/compat: Remove compat_ni_syscall() · 29a5ff97
      Brian Gerst 提交于
      compat_ni_syscall() does the same thing as sys_ni_syscall().
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1425439896-8322-2-git-send-email-brgerst@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      29a5ff97
    • L
      Linux 4.0-rc2 · 13a7a6ac
      Linus Torvalds 提交于
      13a7a6ac
    • D
      drm/i915: Fix modeset state confusion in the load detect code · 9128b040
      Daniel Vetter 提交于
      This is a tricky story of the new atomic state handling and the legacy
      code fighting over each another. The bug at hand is an underrun of the
      framebuffer reference with subsequent hilarity caused by the load
      detect code. Which is peculiar since the the exact same code works
      fine as the implementation of the legacy setcrtc ioctl.
      
      Let's look at the ingredients:
      
      - Currently our code is a crazy mix of legacy modeset interfaces to
        set the parameters and half-baked atomic state tracking underneath.
        While this transition is going we're using the transitional plane
        helpers to update the atomic side (drm_plane_helper_disable/update
        and friends), i.e. plane->state->fb. Since the state structure owns
        the fb those functions take care of that themselves.
      
        The legacy state (specifically crtc->primary->fb) is still managed
        by the old code (and mostly by the drm core), with the fb reference
        counting done by callers (core drm for the ioctl or the i915 load
        detect code). The relevant commit is
      
        commit ea2c67bb
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Tue Dec 23 10:41:52 2014 -0800
      
            drm/i915: Move to atomic plane helpers (v9)
      
      - drm_plane_helper_disable has special code to handle multiple calls
        in a row - it checks plane->crtc == NULL and bails out. This is to
        match the proper atomic implementation which needs the crtc to get
        at the implied locking context atomic updates always need. See
      
        commit acf24a39
        Author: Daniel Vetter <daniel.vetter@ffwll.ch>
        Date:   Tue Jul 29 15:33:05 2014 +0200
      
            drm/plane-helper: transitional atomic plane helpers
      
      - The universal plane code split out the implicit primary plane from
        the CRTC into it's own full-blown drm_plane object. As part of that
        the setcrtc ioctl (which updated both the crtc mode and primary
        plane) learned to set crtc->primary->crtc on modeset to make sure
        the plane->crtc assignments statate up to date in
      
        commit e13161af
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Tue Apr 1 15:22:38 2014 -0700
      
            drm: Add drm_crtc_init_with_planes() (v2)
      
        Unfortunately we've forgotten to update the load detect code. Which
        wasn't a problem since the load detect modeset is temporary and
        always undone before we drop the locks.
      
      - Finally there is a organically grown history (i.e. don't ask) around
        who sets the legacy plane->fb for the various driver entry points.
        Originally updating that was the drivers duty, but for almost all
        places we've moved that (plus updating the refcounts) into the core.
        Again the exception is the load detect code.
      
      Taking all together the following happens:
      - The load detect code doesn't set crtc->primary->crtc. This is only
        really an issue on crtcs never before used or when userspace
        explicitly disabled the primary plane.
      
      - The plane helper glue code short-circuits because of that and leaves
        a non-NULL fb behind in plane->state->fb and plane->fb. The state
        fb isn't a real problem (it's properly refcounted on its own), it's
        just the canary.
      
      - Load detect code drops the reference for that fb, but doesn't set
        plane->fb = NULL. This is ok since it's still living in that old
        world where drivers had to clear the pointer but the core/callers
        handled the refcounting.
      
      - On the next modeset the drm core notices plane->fb and takes care of
        refcounting it properly by doing another unref. This drops the
        refcount to zero, leaving state->plane now pointing at freed memory.
      
      - intel_plane_duplicate_state still assume it owns a reference to that
        very state->fb and bad things start to happen.
      
      Fix this all by applying the same duct-tape as for the legacy setcrtc
      ioctl code and set crtc->primary->crtc properly.
      
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Paul Bolle <pebolle@tiscali.nl>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9128b040
    • B
      perf/bench: Add -r all so that you can run all mem* routines · dfecb95c
      Borislav Petkov 提交于
      perf bench mem mem{set,cpy} -r all thus runs all available mem
      benchmarking routines.
      Reviewed-by: NHitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      dfecb95c
    • B
      perf/bench: Carve out mem routine benchmarking · 515e23f0
      Borislav Petkov 提交于
      ... so that we can call it multiple times. See next patch.
      Reviewed-by: NHitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      515e23f0