1. 06 7月, 2018 1 次提交
    • G
      arm64: remove no-op -p linker flag · 1a381d4a
      Greg Hackmann 提交于
      Linking the ARM64 defconfig kernel with LLVM lld fails with the error:
      
        ld.lld: error: unknown argument: -p
        Makefile:1015: recipe for target 'vmlinux' failed
      
      Without this flag, the ARM64 defconfig kernel successfully links with
      lld and boots on Dragonboard 410c.
      
      After digging through binutils source and changelogs, it turns out that
      -p is only relevant to ancient binutils installations targeting 32-bit
      ARM.  binutils accepts -p for AArch64 too, but it's always been
      undocumented and silently ignored.  A comment in
      ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
      compatibility".
      
      Since this flag is a no-op on ARM64, we can safely drop it.
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NGreg Hackmann <ghackmann@google.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      1a381d4a
  2. 05 7月, 2018 2 次提交
  3. 29 6月, 2018 5 次提交
    • H
      parisc: Build kernel without -ffunction-sections · 24b6c225
      Helge Deller 提交于
      As suggested by Nick Piggin it seems we can drop the -ffunction-sections
      compile flag, now that the kernel uses thin archives. Testing with 32-
      and 64-bit kernel showed no difference in kernel size.
      Suggested-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      24b6c225
    • H
      parisc: Reduce debug output in unwind code · 63ba82c0
      Helge Deller 提交于
      Signed-off-by: NHelge Deller <deller@gmx.de>
      63ba82c0
    • N
      x86/e820: put !E820_TYPE_RAM regions into memblock.reserved · 124049de
      Naoya Horiguchi 提交于
      There is a kernel panic that is triggered when reading /proc/kpageflags
      on the kernel booted with kernel parameter 'memmap=nn[KMG]!ss[KMG]':
      
        BUG: unable to handle kernel paging request at fffffffffffffffe
        PGD 9b20e067 P4D 9b20e067 PUD 9b210067 PMD 0
        Oops: 0000 [#1] SMP PTI
        CPU: 2 PID: 1728 Comm: page-types Not tainted 4.17.0-rc6-mm1-v4.17-rc6-180605-0816-00236-g2dfb086ef02c+ #160
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014
        RIP: 0010:stable_page_flags+0x27/0x3c0
        Code: 00 00 00 0f 1f 44 00 00 48 85 ff 0f 84 a0 03 00 00 41 54 55 49 89 fc 53 48 8b 57 08 48 8b 2f 48 8d 42 ff 83 e2 01 48 0f 44 c7 <48> 8b 00 f6 c4 01 0f 84 10 03 00 00 31 db 49 8b 54 24 08 4c 89 e7
        RSP: 0018:ffffbbd44111fde0 EFLAGS: 00010202
        RAX: fffffffffffffffe RBX: 00007fffffffeff9 RCX: 0000000000000000
        RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffffed1182fff5c0
        RBP: ffffffffffffffff R08: 0000000000000001 R09: 0000000000000001
        R10: ffffbbd44111fed8 R11: 0000000000000000 R12: ffffed1182fff5c0
        R13: 00000000000bffd7 R14: 0000000002fff5c0 R15: ffffbbd44111ff10
        FS:  00007efc4335a500(0000) GS:ffff93a5bfc00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: fffffffffffffffe CR3: 00000000b2a58000 CR4: 00000000001406e0
        Call Trace:
         kpageflags_read+0xc7/0x120
         proc_reg_read+0x3c/0x60
         __vfs_read+0x36/0x170
         vfs_read+0x89/0x130
         ksys_pread64+0x71/0x90
         do_syscall_64+0x5b/0x160
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x7efc42e75e23
        Code: 09 00 ba 9f 01 00 00 e8 ab 81 f4 ff 66 2e 0f 1f 84 00 00 00 00 00 90 83 3d 29 0a 2d 00 00 75 13 49 89 ca b8 11 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 db d3 01 00 48 89 04 24
      
      According to kernel bisection, this problem became visible due to commit
      f7f99100 ("mm: stop zeroing memory during allocation in vmemmap")
      which changes how struct pages are initialized.
      
      Memblock layout affects the pfn ranges covered by node/zone.  Consider
      that we have a VM with 2 NUMA nodes and each node has 4GB memory, and
      the default (no memmap= given) memblock layout is like below:
      
        MEMBLOCK configuration:
         memory size = 0x00000001fff75c00 reserved size = 0x000000000300c000
         memory.cnt  = 0x4
         memory[0x0]     [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
         memory[0x1]     [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
         memory[0x2]     [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x0
         memory[0x3]     [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
         ...
      
      If you give memmap=1G!4G (so it just covers memory[0x2]),
      the range [0x100000000-0x13fffffff] is gone:
      
        MEMBLOCK configuration:
         memory size = 0x00000001bff75c00 reserved size = 0x000000000300c000
         memory.cnt  = 0x3
         memory[0x0]     [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x0
         memory[0x1]     [0x0000000000100000-0x00000000bffd6fff], 0x00000000bfed7000 bytes on node 0 flags: 0x0
         memory[0x2]     [0x0000000140000000-0x000000023fffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
         ...
      
      This causes shrinking node 0's pfn range because it is calculated by the
      address range of memblock.memory.  So some of struct pages in the gap
      range are left uninitialized.
      
      We have a function zero_resv_unavail() which does zeroing the struct pages
      within the reserved unavailable range (i.e.  memblock.memory &&
      !memblock.reserved).  This patch utilizes it to cover all unavailable
      ranges by putting them into memblock.reserved.
      
      Link: http://lkml.kernel.org/r/20180615072947.GB23273@hori1.linux.bs1.fc.nec.co.jp
      Fixes: f7f99100 ("mm: stop zeroing memory during allocation in vmemmap")
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Tested-by: NOscar Salvador <osalvador@suse.de>
      Tested-by: N"Herton R. Krzesinski" <herton@redhat.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Reviewed-by: NPavel Tatashin <pasha.tatashin@oracle.com>
      Cc: Steven Sistare <steven.sistare@oracle.com>
      Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      124049de
    • O
      arm64: dts: hikey960: Define wl1837 power capabilities · a30449eb
      oscardagrach 提交于
      These properties are required for compatibility with runtime PM.
      Without these properties, MMC host controller will not be aware
      of power capabilities. When the wlcore driver attempts to power
      on the device, it will erroneously fail with -EACCES. This fixes
      a regression found here: https://lkml.org/lkml/2018/6/12/930
      
      Fixes: 60f36637 ("wlcore: sdio: allow pm to handle sdio power")
      Signed-off-by: NRyan Grachek <ryan@edited.us>
      Tested-by: NJohn Stultz <john.stultz@linaro.org>
      Acked-by: NJohn Stultz <john.stultz@linaro.org>
      Tested-by: NValentin Schneider <valentin.schneider@arm.com>
      Signed-off-by: NWei Xu <xuwei5@hisilicon.com>
      a30449eb
    • O
      arm64: dts: hikey: Define wl1835 power capabilities · f904390a
      oscardagrach 提交于
      These properties are required for compatibility with runtime PM.
      Without these properties, MMC host controller will not be aware
      of power capabilities. When the wlcore driver attempts to power
      on the device, it will erroneously fail with -EACCES.
      
      Fixes: 60f36637 ("wlcore: sdio: allow pm to handle sdio power")
      Signed-off-by: NRyan Grachek <ryan@edited.us>
      Tested-by: NJohn Stultz <john.stultz@linaro.org>
      Acked-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NWei Xu <xuwei5@hisilicon.com>
      f904390a
  4. 28 6月, 2018 13 次提交
  5. 27 6月, 2018 10 次提交
  6. 26 6月, 2018 5 次提交
  7. 25 6月, 2018 2 次提交
    • P
      powerpc: Remove -Wattribute-alias pragmas · ac851744
      Paul Burton 提交于
      With SYSCALL_DEFINEx() disabling -Wattribute-alias generically, there's
      no need to duplicate that for PowerPC syscalls.
      
      This reverts commit 41552037 ("powerpc: fix build failure by
      disabling attribute-alias warning in pci_32") and commit 2479bfc9
      ("powerpc: Fix build by disabling attribute-alias warning for
      SYSCALL_DEFINEx").
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      ac851744
    • P
      MIPS: Add ksig argument to rseq_{signal_deliver,handle_notify_resume} · 662d855c
      Paul Burton 提交于
      Commit 784e0300 ("rseq: Avoid infinite recursion when delivering
      SIGSEGV") added a new ksig argument to the rseq_signal_deliver() &
      rseq_handle_notify_resume() functions, and was merged in v4.18-rc2.
      Meanwhile MIPS support for restartable sequences was also merged in
      v4.18-rc2 with commit 9ea141ad ("MIPS: Add support for restartable
      sequences"), and therefore didn't get updated for the API change.
      
      This results in build failures like the following:
      
          CC      arch/mips/kernel/signal.o
        arch/mips/kernel/signal.c: In function 'handle_signal':
        arch/mips/kernel/signal.c:804:22: error: passing argument 1 of
          'rseq_signal_deliver' from incompatible pointer type
          [-Werror=incompatible-pointer-types]
          rseq_signal_deliver(regs);
                              ^~~~
        In file included from ./include/linux/context_tracking.h:5,
                         from arch/mips/kernel/signal.c:12:
        ./include/linux/sched.h:1811:56: note: expected 'struct ksignal *' but
          argument is of type 'struct pt_regs *'
          static inline void rseq_signal_deliver(struct ksignal *ksig,
                                                 ~~~~~~~~~~~~~~~~^~~~
        arch/mips/kernel/signal.c:804:2: error: too few arguments to function
          'rseq_signal_deliver'
          rseq_signal_deliver(regs);
          ^~~~~~~~~~~~~~~~~~~
      
      Fix this by adding the ksig argument as was done for other architectures
      in commit 784e0300 ("rseq: Avoid infinite recursion when delivering
      SIGSEGV").
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19603/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      662d855c
  8. 24 6月, 2018 2 次提交
    • A
      efi/x86: Fix incorrect invocation of PciIo->Attributes() · 2e6eb40c
      Ard Biesheuvel 提交于
      The following commit:
      
        2c3625cb ("efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() into one function")
      
      ... merged the two versions of __setup_efi_pciXX(), without taking into
      account that the 32-bit version used a rather dodgy trick to pass an
      immediate 0 constant as argument for a uint64_t parameter.
      
      The issue is caused by the fact that on x86, UEFI protocol method calls
      are redirected via struct efi_config::call(), which is a variadic function,
      and so the compiler has to infer the types of the parameters from the
      arguments rather than from the prototype.
      
      As the 32-bit x86 calling convention passes arguments via the stack,
      passing the unqualified constant 0 twice is the same as passing 0ULL,
      which is why the 32-bit code in __setup_efi_pci32() contained the
      following call:
      
        status = efi_early->call(pci->attributes, pci,
                                 EfiPciIoAttributeOperationGet, 0, 0,
                                 &attributes);
      
      to invoke this UEFI protocol method:
      
        typedef
        EFI_STATUS
        (EFIAPI *EFI_PCI_IO_PROTOCOL_ATTRIBUTES) (
          IN  EFI_PCI_IO_PROTOCOL                     *This,
          IN  EFI_PCI_IO_PROTOCOL_ATTRIBUTE_OPERATION Operation,
          IN  UINT64                                  Attributes,
          OUT UINT64                                  *Result OPTIONAL
          );
      
      After the merge, we inadvertently ended up with this version for both
      32-bit and 64-bit builds, breaking the latter.
      
      So replace the two zeroes with the explicitly typed constant 0ULL,
      which works as expected on both 32-bit and 64-bit builds.
      
      Wilfried tested the 64-bit build, and I checked the generated assembly
      of a 32-bit build with and without this patch, and they are identical.
      Reported-by: NWilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
      Tested-by: NWilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: hdegoede@redhat.com
      Cc: linux-efi@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      2e6eb40c
    • G
      ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build · 0fff9001
      Geert Uytterhoeven 提交于
      If CONFIG_SMP=n, building a kernel for R-Car Gen2 fails with:
      
          arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init':
          setup-rcar-gen2.c:(.init.text+0x30): undefined reference to `secure_cntvoff_init'
      
      Indeed, on R-Car Gen2 SoCs, secure_cntvoff_init() is not only needed for
      secondary CPUs, but also for the boot CPU.  This is most visible on SoCs
      with Cortex A7 cores (e.g. R-Car E2, cfr. commit 9ce3fa68 ("ARM:
      shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794")),
      but Cortex A15 is affected, too.
      
      Fix this by always providing secure_cntvoff_init() when building for ARM
      V7.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 7c607944 ("ARM: smp: Add initialization of CNTVOFF")
      Fixes: cad160ed ("ARM: shmobile: Convert file to use cntvoff")
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      0fff9001