1. 27 Aug, 2019 1 commit
    • Marc Zyngier's avatar
      kallsyms: Don't let kallsyms_lookup_size_offset() fail on retrieving the first symbol · 2a1a3fa0
      Marc Zyngier authored
      An arm64 kernel configured with
      
        CONFIG_KPROBES=y
        CONFIG_KALLSYMS=y
        # CONFIG_KALLSYMS_ALL is not set
        CONFIG_KALLSYMS_BASE_RELATIVE=y
      
      reports the following kprobe failure:
      
        [    0.032677] kprobes: failed to populate blacklist: -22
        [    0.033376] Please take care of using kprobes.
      
      It appears that kprobe fails to retrieve the symbol at address
      0xffff000010081000, despite this symbol being in System.map:
      
        ffff000010081000 T __exception_text_start
      
      This symbol is part of the first group of aliases in the
      kallsyms_offsets array (symbol names generated using ugly hacks in
      scripts/kallsyms.c):
      
        kallsyms_offsets:
                .long   0x1000 // do_undefinstr
                .long   0x1000 // efi_header_end
                .long   0x1000 // _stext
                .long   0x1000 // __exception_text_start
                .long   0x12b0 // do_cp15instr
      
      Looking at the implementation of get_symbol_pos(), it returns the
      lowest index for aliasing symbols. In this case, it return 0.
      
      But kallsyms_lookup_size_offset() considers 0 as a failure, which
      is obviously wrong (there is definitely a valid symbol living there).
      In turn, the kprobe blacklisting stops abruptly, hence the original
      error.
      
      A CONFIG_KALLSYMS_ALL kernel wouldn't fail as there is always
      some random symbols at the beginning of this array, which are never
      looked up via kallsyms_lookup_size_offset.
      
      Fix it by considering that get_symbol_pos() is always successful
      (which is consistent with the other uses of this function).
      
      Fixes: ffc50891 ("[PATCH] Create kallsyms_lookup_size_offset()")
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      2a1a3fa0
  2. 16 Aug, 2019 1 commit
    • Will Deacon's avatar
      arm64: ftrace: Ensure module ftrace trampoline is coherent with I-side · b6143d10
      Will Deacon authored
      The initial support for dynamic ftrace trampolines in modules made use
      of an indirect branch which loaded its target from the beginning of
      a special section (e71a4e1b ("arm64: ftrace: add support for far
      branches to dynamic ftrace")). Since no instructions were being patched,
      no cache maintenance was needed. However, later in be0f272b ("arm64:
      ftrace: emit ftrace-mod.o contents through code") this code was reworked
      to output the trampoline instructions directly into the PLT entry but,
      unfortunately, the necessary cache maintenance was overlooked.
      
      Add a call to __flush_icache_range() after writing the new trampoline
      instructions but before patching in the branch to the trampoline.
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: <stable@vger.kernel.org>
      Fixes: be0f272b ("arm64: ftrace: emit ftrace-mod.o contents through code")
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b6143d10
  3. 13 Aug, 2019 1 commit
    • Will Deacon's avatar
      arm64: cpufeature: Don't treat granule sizes as strict · 5717fe5a
      Will Deacon authored
      If a CPU doesn't support the page size for which the kernel is
      configured, then we will complain and refuse to bring it online. For
      secondary CPUs (and the boot CPU on a system booting with EFI), we will
      also print an error identifying the mismatch.
      
      Consequently, the only time that the cpufeature code can detect a
      granule size mismatch is for a granule other than the one that is
      currently being used. Although we would rather such systems didn't
      exist, we've unfortunately lost that battle and Kevin reports that
      on his amlogic S922X (odroid-n2 board) we end up warning and taining
      with defconfig because 16k pages are not supported by all of the CPUs.
      
      In such a situation, we don't actually care about the feature mismatch,
      particularly now that KVM only exposes the sanitised view of the CPU
      registers (commit 93390c0a - "arm64: KVM: Hide unsupported AArch64
      CPU features from guests"). Treat the granule fields as non-strict and
      let Kevin run without a tainted kernel.
      
      Cc: Marc Zyngier <maz@kernel.org>
      Reported-by: default avatarKevin Hilman <khilman@baylibre.com>
      Tested-by: default avatarKevin Hilman <khilman@baylibre.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      [catalin.marinas@arm.com: changelog updated with KVM sanitised regs commit]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      5717fe5a
  4. 08 Aug, 2019 1 commit
    • Jia He's avatar
      arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64 · 30e23538
      Jia He authored
      Without this patch, the MAP_SYNC test case will cause a print_bad_pte
      warning on arm64 as follows:
      
      [   25.542693] BUG: Bad page map in process mapdax333 pte:2e8000448800f53 pmd:41ff5f003
      [   25.546360] page:ffff7e0010220000 refcount:1 mapcount:-1 mapping:ffff8003e29c7440 index:0x0
      [   25.550281] ext4_dax_aops
      [   25.550282] name:"__aaabbbcccddd__"
      [   25.551553] flags: 0x3ffff0000001002(referenced|reserved)
      [   25.555802] raw: 03ffff0000001002 ffff8003dfffa908 0000000000000000 ffff8003e29c7440
      [   25.559446] raw: 0000000000000000 0000000000000000 00000001fffffffe 0000000000000000
      [   25.563075] page dumped because: bad pte
      [   25.564938] addr:0000ffffbe05b000 vm_flags:208000fb anon_vma:0000000000000000 mapping:ffff8003e29c7440 index:0
      [   25.574272] file:__aaabbbcccddd__ fault:ext4_dax_fault mmmmap:ext4_file_mmap readpage:0x0
      [   25.578799] CPU: 1 PID: 1180 Comm: mapdax333 Not tainted 5.2.0+ #21
      [   25.581702] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      [   25.585624] Call trace:
      [   25.587008]  dump_backtrace+0x0/0x178
      [   25.588799]  show_stack+0x24/0x30
      [   25.590328]  dump_stack+0xa8/0xcc
      [   25.591901]  print_bad_pte+0x18c/0x218
      [   25.593628]  unmap_page_range+0x778/0xc00
      [   25.595506]  unmap_single_vma+0x94/0xe8
      [   25.597304]  unmap_vmas+0x90/0x108
      [   25.598901]  unmap_region+0xc0/0x128
      [   25.600566]  __do_munmap+0x284/0x3f0
      [   25.602245]  __vm_munmap+0x78/0xe0
      [   25.603820]  __arm64_sys_munmap+0x34/0x48
      [   25.605709]  el0_svc_common.constprop.0+0x78/0x168
      [   25.607956]  el0_svc_handler+0x34/0x90
      [   25.609698]  el0_svc+0x8/0xc
      [...]
      
      The root cause is in _vm_normal_page, without the PTE_SPECIAL bit,
      the return value will be incorrectly set to pfn_to_page(pfn) instead
      of NULL. Besides, this patch also rewrite the pmd_mkdevmap to avoid
      setting PTE_SPECIAL for pmd
      
      The MAP_SYNC test case is as follows(Provided by Yibo Cai)
      $#include <stdio.h>
      $#include <string.h>
      $#include <unistd.h>
      $#include <sys/file.h>
      $#include <sys/mman.h>
      
      $#ifndef MAP_SYNC
      $#define MAP_SYNC 0x80000
      $#endif
      
      /* mount -o dax /dev/pmem0 /mnt */
      $#define F "/mnt/__aaabbbcccddd__"
      
      int main(void)
      {
          int fd;
          char buf[4096];
          void *addr;
      
          if ((fd = open(F, O_CREAT|O_TRUNC|O_RDWR, 0644)) < 0) {
              perror("open1");
              return 1;
          }
      
          if (write(fd, buf, 4096) != 4096) {
              perror("lseek");
              return 1;
          }
      
          addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_SYNC, fd, 0);
          if (addr == MAP_FAILED) {
              perror("mmap");
              printf("did you mount with '-o dax'?\n");
              return 1;
          }
      
          memset(addr, 0x55, 4096);
      
          if (munmap(addr, 4096) == -1) {
              perror("munmap");
              return 1;
          }
      
          close(fd);
      
          return 0;
      }
      
      Fixes: 73b20c84 ("arm64: mm: implement pte_devmap support")
      Reported-by: default avatarYibo Cai <Yibo.Cai@arm.com>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Acked-by: default avatarRobin Murphy <Robin.Murphy@arm.com>
      Signed-off-by: default avatarJia He <justin.he@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      30e23538
  5. 05 Aug, 2019 1 commit
  6. 04 Aug, 2019 10 commits
  7. 03 Aug, 2019 25 commits