1. 06 Jan, 2019 1 commit
    • Masahiro Yamada's avatar
      jump_label: move 'asm goto' support test to Kconfig · e9666d10
      Masahiro Yamada authored
      Currently, CONFIG_JUMP_LABEL just means "I _want_ to use jump label".
      
      The jump label is controlled by HAVE_JUMP_LABEL, which is defined
      like this:
      
        #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
        # define HAVE_JUMP_LABEL
        #endif
      
      We can improve this by testing 'asm goto' support in Kconfig, then
      make JUMP_LABEL depend on CC_HAS_ASM_GOTO.
      
      Ugly #ifdef HAVE_JUMP_LABEL will go away, and CONFIG_JUMP_LABEL will
      match to the real kernel capability.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      e9666d10
  2. 04 Jan, 2019 2 commits
    • Matthew Wilcox's avatar
      fls: change parameter to unsigned int · 3fc2579e
      Matthew Wilcox authored
      When testing in userspace, UBSAN pointed out that shifting into the sign
      bit is undefined behaviour.  It doesn't really make sense to ask for the
      highest set bit of a negative value, so just turn the argument type into
      an unsigned int.
      
      Some architectures (eg ppc) already had it declared as an unsigned int,
      so I don't expect too many problems.
      
      Link: http://lkml.kernel.org/r/20181105221117.31828-1-willy@infradead.orgSigned-off-by: default avatarMatthew Wilcox <willy@infradead.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3fc2579e
    • Linus Torvalds's avatar
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds authored
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      
      There were a couple of notable cases:
      
       - csky still had the old "verify_area()" name as an alias.
      
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
      
       - microblaze used the type argument for a debug printout
      
      but other than those oddities this should be a total no-op patch.
      
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      96d4f267
  3. 03 Jan, 2019 1 commit
  4. 02 Jan, 2019 8 commits
  5. 01 Jan, 2019 1 commit
  6. 28 Dec, 2018 20 commits
  7. 21 Dec, 2018 7 commits
    • Dave Jiang's avatar
      tools/testing/nvdimm: add Intel DSM 1.8 support for nfit_test · ecaa4a97
      Dave Jiang authored
      Adding test support for new Intel DSM from v1.8. The ability of simulating
      master passphrase update and master secure erase have been added to
      nfit_test.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      ecaa4a97
    • Dave Jiang's avatar
      tools/testing/nvdimm: Add overwrite support for nfit_test · 926f7480
      Dave Jiang authored
      With the implementation of Intel NVDIMM DSM overwrite, we are adding unit
      test to nfit_test for testing of overwrite operation.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      926f7480
    • Dave Jiang's avatar
      tools/testing/nvdimm: Add test support for Intel nvdimm security DSMs · 3c13e2ac
      Dave Jiang authored
      Add nfit_test support for DSM functions "Get Security State",
      "Set Passphrase", "Disable Passphrase", "Unlock Unit", "Freeze Lock",
      and "Secure Erase" for the fake DIMMs.
      
      Also adding a sysfs knob in order to put the DIMMs in "locked" state. The
      order of testing DIMM unlocking would be.
      1a. Disable DIMM X.
      1b. Set Passphrase to DIMM X.
      2. Write to
      /sys/devices/platform/nfit_test.0/nfit_test_dimm/test_dimmX/lock_dimm
      3. Renable DIMM X
      4. Check DIMM X state via sysfs "security" attribute for nmemX.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      3c13e2ac
    • Daniel Borkmann's avatar
      bpf: fix segfault in test_verifier selftest · 7fa4bd73
      Daniel Borkmann authored
      Minor fallout from merge resolution, test_verifier was segfaulting
      because the REJECT result was correct, but errstr was NULL. Properly
      fix it as in 339bbff2.
      
      Fixes: 339bbff2 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7fa4bd73
    • Andrew Jones's avatar
      kvm: selftests: ucall: fix exit mmio address guessing · 57d5edfe
      Andrew Jones authored
      Fix two more bugs in the exit_mmio address guessing.
      The first bug was that the start and step calculations were
      wrong since they were dividing the number of address bits instead
      of the address space. The second other bug was that the guessing
      algorithm wasn't considering the valid physical and virtual address
      ranges correctly for an identity map.
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      57d5edfe
    • Arnaldo Carvalho de Melo's avatar
      perf trace: Do not hardcode the size of the tracepoint common_ fields · b9b6a2ea
      Arnaldo Carvalho de Melo authored
      We shouldn't hardcode the size of the tracepoint common_ fields, use the
      offset of the 'id'/'__syscallnr' field in the sys_enter event instead.
      
      This caused the augmented syscalls code to fail on a particular build of a
      PREEMPT_RT_FULL kernel where these extra 'common_migrate_disable' and
      'common_padding' fields were before the syscall id one:
      
        # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/format
        name: sys_enter
        ID: 22
        format:
      	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
      	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
      	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
      	field:int common_pid;	offset:4;	size:4;	signed:1;
      	field:unsigned short common_migrate_disable;	offset:8;	size:2;	signed:0;
      	field:unsigned short common_padding;	offset:10;	size:2;	signed:0;
      
      	field:long id;	offset:16;	size:8;	signed:1;
      	field:unsigned long args[6];	offset:24;	size:48;	signed:0;
      
        print fmt: "NR %ld (%lx, %lx, %lx, %lx, %lx, %lx)", REC->id, REC->args[0], REC->args[1], REC->args[2], REC->args[3], REC->args[4], REC->args[5]
        #
      
      All those 'common_' prefixed fields are zeroed when they hit a BPF tracepoint
      hook, we better just discard those, i.e. somehow pass an offset to the
      BPF program from the start of the ctx and make adjustments in the 'perf trace'
      handlers to adjust the offset of the syscall arg offsets obtained from tracefs.
      
      Till then, fix it the quick way and add this to the augmented_raw_syscalls.c to
      bet it to work in such kernels:
      
        diff --git a/tools/perf/examples/bpf/augmented_raw_syscalls.c b/tools/perf/examples/bpf/augmented_raw_syscalls.c
        index 53c233370fae..1f746f931e13 100644
        --- a/tools/perf/examples/bpf/augmented_raw_syscalls.c
        +++ b/tools/perf/examples/bpf/augmented_raw_syscalls.c
        @@ -38,12 +38,14 @@ struct bpf_map SEC("maps") syscalls = {
      
         struct syscall_enter_args {
                unsigned long long common_tp_fields;
        +       long               rt_common_tp_fields;
                long               syscall_nr;
                unsigned long      args[6];
         };
      
         struct syscall_exit_args {
                unsigned long long common_tp_fields;
        +       long               rt_common_tp_fields;
                long               syscall_nr;
                long               ret;
         };
      
      Just to check that this was the case. Fix it properly later, for now remove the
      hardcoding of the offset in the 'perf trace' side and document the situation
      with this patch.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-2pqavrktqkliu5b9nzouio21@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b9b6a2ea
    • Stanislav Fomichev's avatar
      perf build: Don't unconditionally link the libbfd feature test to -liberty and -lz · 14541b1e
      Stanislav Fomichev authored
      Current libbfd feature test unconditionally links against -liberty and -lz.
      While it's required on some systems (e.g. opensuse), it's completely
      unnecessary on the others, where only -lbdf is sufficient (debian).
      This patch streamlines (and renames) the following feature checks:
      
      feature-libbfd           - only link against -lbfd (debian),
                                 see commit 2cf90407 ("perf tools: Fix bfd
      			   dependency libraries detection")
      feature-libbfd-liberty   - link against -lbfd and -liberty
      feature-libbfd-liberty-z - link against -lbfd, -liberty and -lz (opensuse),
                                 see commit 280e7c48 ("perf tools: fix BFD
      			   detection on opensuse")
      
      (feature-liberty{,-z} were renamed to feature-libbfd-liberty{,z}
      for clarity)
      
      The main motivation is to fix this feature test for bpftool which is
      currently broken on debian (libbfd feature shows OFF, but we still
      unconditionally link against -lbfd and it works).
      
      Tested on debian with only -lbfd installed (without -liberty); I'd
      appreciate if somebody on the other systems can test this new detection
      method.
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/4dfc634cfcfb236883971b5107cf3c28ec8a31be.1542328222.git.sdf@google.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      14541b1e