1. 29 11月, 2017 28 次提交
  2. 11 11月, 2017 1 次提交
    • I
      tooling/headers: Sync the tools/include/uapi/drm/i915_drm.h UAPI header · 505ee767
      Ingo Molnar 提交于
      Last minute upstream update to one of the UAPI headers - sync it with tooling,
      to address this warning:
      
        Warning: Kernel ABI header at 'tools/include/uapi/drm/i915_drm.h' differs from latest version at 'include/uapi/drm/i915_drm.h'
      
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      505ee767
  3. 10 11月, 2017 1 次提交
    • M
      locking/x86: Use LOCK ADD for smp_mb() instead of MFENCE · 450cbdd0
      Michael S. Tsirkin 提交于
      MFENCE appears to be way slower than a locked instruction - let's use
      LOCK ADD unconditionally, as we always did on old 32-bit.
      
      Performance testing results:
      
        perf stat -r 10 -- ./virtio_ring_0_9 --sleep --host-affinity 0 --guest-affinity 0
        Before:
               0.922565990 seconds time elapsed                                          ( +-  1.15% )
        After:
               0.578667024 seconds time elapsed                                          ( +-  1.21% )
      
      i.e. about ~60% faster.
      
      Just poking at SP would be the most natural, but if we then read the
      value from SP, we get a false dependency which will slow us down.
      
      This was noted in this article:
      
        http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
      
      And is easy to reproduce by sticking a barrier in a small non-inline
      function.
      
      So let's use a negative offset - which avoids this problem since we
      build with the red zone disabled.
      
      For userspace, use an address just below the redzone.
      
      The one difference between LOCK ADD and MFENCE is that LOCK ADD does
      not affect CLFLUSH, previous patches converted all uses of CLFLUSH to
      call mb(), such that changes to smp_mb() won't affect it.
      
      Update mb/rmb/wmb() on 32-bit to use the negative offset, too, for
      consistency.
      
      As a follow-up, it might be worth considering switching users
      of CLFLUSH to another API (e.g. clflush_mb()?) - we will
      then be able to convert mb() to smp_mb() again.
      
      Also arguably, GCC should switch to use LOCK ADD for __sync_synchronize().
      This might be worth pursuing separately.
      Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: qemu-devel@nongnu.org
      Cc: virtualization@lists.linux-foundation.org
      Link: http://lkml.kernel.org/r/1509118355-4890-1-git-send-email-mst@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      450cbdd0
  4. 09 11月, 2017 3 次提交
    • A
      perf trace: Call machine__exit() at exit · 33974a41
      Andrei Vagin 提交于
      Otherwise 'perf trace' leaves a temporary file /tmp/perf-vdso.so-XXXXXX.
      
        $ perf trace -o log true
        $ ls -l /tmp/perf-vdso.*
        -rw------- 1 root root 8192 Nov  8 03:08 /tmp/perf-vdso.so-5bCpD0
      Signed-off-by: NAndrei Vagin <avagin@openvz.org>
      Reviewed-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Vasily Averin <vvs@virtuozzo.com>
      Link: http://lkml.kernel.org/r/20171108002246.8924-1-avagin@openvz.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      33974a41
    • J
      perf tools: Fix eBPF event specification parsing · a271bfaf
      Jiri Olsa 提交于
      Looks like I've reached the new level of stupidity, adding missing braces.
      
      Committer testing:
      
      Given the following eBPF C filter, that will add a record when it
      returns true, i.e. when the tv_nsec variable is > 2000ns, should be
      built and installed via sys_bpf(), but fails to do so before this patch:
      
        # cat filter.c
        #include <uapi/linux/bpf.h>
        #define SEC(NAME) __attribute__((section(NAME), used))
      
        SEC("func=hrtimer_nanosleep rqtp->tv_nsec")
        int func(void *ctx, int err, long nsec)
        {
      	  return nsec > 1000;
        }
        char _license[] SEC("license") = "GPL";
        int _version SEC("version") = LINUX_VERSION_CODE;
        #
      
        # perf trace -e nanosleep,filter.c usleep 1
        invalid or unsupported event: 'filter.c'
        Run 'perf list' for a list of valid events
      
         Usage: perf trace [<options>] [<command>]
            or: perf trace [<options>] -- <command> [<options>]
            or: perf trace record [<options>] [<command>]
            or: perf trace record [<options>] -- <command> [<options>]
      
            -e, --event <event>   event/syscall selector. use 'perf list' to list available events
        #
      
      And works again after it is applied, the nothing is inserted when the co
      
        # perf trace -e *sleep,filter.c usleep 1
           0.000 ( 0.066 ms): usleep/23994 nanosleep(rqtp: 0x7ffead94a0d0) = 0
        # perf trace -e *sleep,filter.c usleep 2
           0.000 ( 0.008 ms): usleep/24378 nanosleep(rqtp: 0x7fffa021ba50) ...
           0.008 (         ): perf_bpf_probe:func:(ffffffffb410cb30) tv_nsec=2000)
           0.000 ( 0.066 ms): usleep/24378  ... [continued]: nanosleep()) = 0
        #
      
      The intent of 9445464b is kept:
      
        # perf stat -e 'cpu/uops_executed.core,krava/'  true
        event syntax error: '..cuted.core,krava/'
                                          \___ unknown term
      
        valid terms: cmask,pc,event,edge,in_tx,any,ldlat,inv,umask,in_tx_cp,offcore_rsp,config,config1,config2,name,period
        Run 'perf list' for a list of valid events
      
         Usage: perf stat [<options>] [<command>]
      
            -e, --event <event>   event selector. use 'perf list' to list available events
        #
        # perf stat -e 'cpu/uops_executed.core,period=1/'  true
      
         Performance counter stats for 'true':
      
                 808,332      cpu/uops_executed.core,period=1/
      
             0.002997237 seconds time elapsed
      
        #
      Reported-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: 9445464b ("perf tools: Unwind properly location after REJECT")
      Link: http://lkml.kernel.org/n/tip-diea0ihbwpxfw6938huv3whj@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a271bfaf
    • J
      perf tools: Add "reject" option for parse-events.l · b6af53b7
      Jiri Olsa 提交于
      Arnaldo reported broken builds in some distros using a newer flex
      release, 2.6.4, found in Alpine Linux 3.6 and Edge, with flex not
      spotting the REJECT macro:
      
        CC       /tmp/build/perf/util/parse-events-flex.o
        util/parse-events.l: In function 'parse_events_lex':
        /tmp/build/perf/util/parse-events-flex.c:4734:16: error: \
        'reject_used_but_not_detected' undeclared (first use in this function)
      
      It's happening because we put the REJECT under another USER_REJECT macro
      in following commit:
      
        9445464b perf tools: Unwind properly location after REJECT
      
      Fortunately flex provides option for force it to use REJECT, adding it
      to parse-events.l.
      Reported-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Reviewed-by: NAndi Kleen <andi@firstfloor.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: 9445464b ("perf tools: Unwind properly location after REJECT")
      Link: http://lkml.kernel.org/n/tip-7kdont984mw12ijk7rji6b8p@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b6af53b7
  5. 08 11月, 2017 2 次提交
    • R
      selftests/x86: Add tests for the STR and SLDT instructions · a9e017d5
      Ricardo Neri 提交于
      The STR and SLDT instructions are not valid when running on virtual-8086
      mode and generate an invalid operand exception. These two instructions are
      protected by the Intel User-Mode Instruction Prevention (UMIP) security
      feature. In protected mode, if UMIP is enabled, these instructions generate
      a general protection fault if called from CPL > 0. Linux traps the general
      protection fault and emulates the instructions sgdt, sidt and smsw; but not
      str and sldt.
      
      These tests are added to verify that the emulation code does not emulate
      these two instructions but the expected invalid operand exception is
      seen.
      
      Tests fallback to exit with INT3 in case emulation does happen.
      Signed-off-by: NRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chen Yucong <slaoub@gmail.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang Rui <ray.huang@amd.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi V. Shankar <ravi.v.shankar@intel.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: ricardo.neri@intel.com
      Link: http://lkml.kernel.org/r/1509935277-22138-13-git-send-email-ricardo.neri-calderon@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a9e017d5
    • R
      selftests/x86: Add tests for User-Mode Instruction Prevention · 9390afeb
      Ricardo Neri 提交于
      Certain user space programs that run on virtual-8086 mode may utilize
      instructions protected by the User-Mode Instruction Prevention (UMIP)
      security feature present in new Intel processors: SGDT, SIDT and SMSW. In
      such a case, a general protection fault is issued if UMIP is enabled. When
      such a fault happens, the kernel traps it and emulates the results of
      these instructions with dummy values. The purpose of this new
      test is to verify whether the impacted instructions can be executed
      without causing such #GP. If no #GP exceptions occur, we expect to exit
      virtual-8086 mode from INT3.
      
      The instructions protected by UMIP are executed in representative use
      cases:
      
       a) displacement-only memory addressing
       b) register-indirect memory addressing
       c) results stored directly in operands
      
      Unfortunately, it is not possible to check the results against a set of
      expected values because no emulation will occur in systems that do not
      have the UMIP feature. Instead, results are printed for verification. A
      simple verification is done to ensure that results of all tests are
      identical.
      Signed-off-by: NRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Chen Yucong <slaoub@gmail.com>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang Rui <ray.huang@amd.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi V. Shankar <ravi.v.shankar@intel.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: ricardo.neri@intel.com
      Link: http://lkml.kernel.org/r/1509935277-22138-12-git-send-email-ricardo.neri-calderon@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9390afeb
  6. 07 11月, 2017 5 次提交