1. 27 12月, 2019 16 次提交
  2. 31 8月, 2018 1 次提交
    • J
      arm64: mm: always enable CONFIG_HOLES_IN_ZONE · f52bb98f
      James Morse 提交于
      Commit 6d526ee2 ("arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA")
      only enabled HOLES_IN_ZONE for NUMA systems because the NUMA code was
      choking on the missing zone for nomap pages. This problem doesn't just
      apply to NUMA systems.
      
      If the architecture doesn't set HAVE_ARCH_PFN_VALID, pfn_valid() will
      return true if the pfn is part of a valid sparsemem section.
      
      When working with multiple pages, the mm code uses pfn_valid_within()
      to test each page it uses within the sparsemem section is valid. On
      most systems memory comes in MAX_ORDER_NR_PAGES chunks which all
      have valid/initialised struct pages. In this case pfn_valid_within()
      is optimised out.
      
      Systems where this isn't true (e.g. due to nomap) should set
      HOLES_IN_ZONE and provide HAVE_ARCH_PFN_VALID so that mm tests each
      page as it works with it.
      
      Currently non-NUMA arm64 systems can't enable HOLES_IN_ZONE, leading to
      a VM_BUG_ON():
      
      | page:fffffdff802e1780 is uninitialized and poisoned
      | raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
      | raw: ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff
      | page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
      | ------------[ cut here ]------------
      | kernel BUG at include/linux/mm.h:978!
      | Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [...]
      | CPU: 1 PID: 25236 Comm: dd Not tainted 4.18.0 #7
      | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      | pstate: 40000085 (nZcv daIf -PAN -UAO)
      | pc : move_freepages_block+0x144/0x248
      | lr : move_freepages_block+0x144/0x248
      | sp : fffffe0071177680
      [...]
      | Process dd (pid: 25236, stack limit = 0x0000000094cc07fb)
      | Call trace:
      |  move_freepages_block+0x144/0x248
      |  steal_suitable_fallback+0x100/0x16c
      |  get_page_from_freelist+0x440/0xb20
      |  __alloc_pages_nodemask+0xe8/0x838
      |  new_slab+0xd4/0x418
      |  ___slab_alloc.constprop.27+0x380/0x4a8
      |  __slab_alloc.isra.21.constprop.26+0x24/0x34
      |  kmem_cache_alloc+0xa8/0x180
      |  alloc_buffer_head+0x1c/0x90
      |  alloc_page_buffers+0x68/0xb0
      |  create_empty_buffers+0x20/0x1ec
      |  create_page_buffers+0xb0/0xf0
      |  __block_write_begin_int+0xc4/0x564
      |  __block_write_begin+0x10/0x18
      |  block_write_begin+0x48/0xd0
      |  blkdev_write_begin+0x28/0x30
      |  generic_perform_write+0x98/0x16c
      |  __generic_file_write_iter+0x138/0x168
      |  blkdev_write_iter+0x80/0xf0
      |  __vfs_write+0xe4/0x10c
      |  vfs_write+0xb4/0x168
      |  ksys_write+0x44/0x88
      |  sys_write+0xc/0x14
      |  el0_svc_naked+0x30/0x34
      | Code: aa1303e0 90001a01 91296421 94008902 (d4210000)
      | ---[ end trace 1601ba47f6e883fe ]---
      
      Remove the NUMA dependency.
      
      Link: https://www.spinics.net/lists/arm-kernel/msg671851.html
      Cc: <stable@vger.kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Reported-by: NMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: NPavel Tatashin <pavel.tatashin@microsoft.com>
      Tested-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      f52bb98f
  3. 23 8月, 2018 1 次提交
    • A
      arch: enable relative relocations for arm64, power and x86 · 271ca788
      Ard Biesheuvel 提交于
      Patch series "add support for relative references in special sections", v10.
      
      This adds support for emitting special sections such as initcall arrays,
      PCI fixups and tracepoints as relative references rather than absolute
      references.  This reduces the size by 50% on 64-bit architectures, but
      more importantly, it removes the need for carrying relocation metadata for
      these sections in relocatable kernels (e.g., for KASLR) that needs to be
      fixed up at boot time.  On arm64, this reduces the vmlinux footprint of
      such a reference by 8x (8 byte absolute reference + 24 byte RELA entry vs
      4 byte relative reference)
      
      Patch #3 was sent out before as a single patch.  This series supersedes
      the previous submission.  This version makes relative ksymtab entries
      dependent on the new Kconfig symbol HAVE_ARCH_PREL32_RELOCATIONS rather
      than trying to infer from kbuild test robot replies for which
      architectures it should be blacklisted.
      
      Patch #1 introduces the new Kconfig symbol HAVE_ARCH_PREL32_RELOCATIONS,
      and sets it for the main architectures that are expected to benefit the
      most from this feature, i.e., 64-bit architectures or ones that use
      runtime relocations.
      
      Patch #2 add support for #define'ing __DISABLE_EXPORTS to get rid of
      ksymtab/kcrctab sections in decompressor and EFI stub objects when
      rebuilding existing C files to run in a different context.
      
      Patches #4 - #6 implement relative references for initcalls, PCI fixups
      and tracepoints, respectively, all of which produce sections with order
      ~1000 entries on an arm64 defconfig kernel with tracing enabled.  This
      means we save about 28 KB of vmlinux space for each of these patches.
      
      [From the v7 series blurb, which included the jump_label patches as well]:
      
        For the arm64 kernel, all patches combined reduce the memory footprint
        of vmlinux by about 1.3 MB (using a config copied from Ubuntu that has
        KASLR enabled), of which ~1 MB is the size reduction of the RELA section
        in .init, and the remaining 300 KB is reduction of .text/.data.
      
      This patch (of 6):
      
      Before updating certain subsystems to use place relative 32-bit
      relocations in special sections, to save space and reduce the number of
      absolute relocations that need to be processed at runtime by relocatable
      kernels, introduce the Kconfig symbol and define it for some architectures
      that should be able to support and benefit from it.
      
      Link: http://lkml.kernel.org/r/20180704083651.24360-2-ard.biesheuvel@linaro.orgSigned-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
      Cc: James Morris <james.morris@microsoft.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      271ca788
  4. 03 8月, 2018 1 次提交
    • P
      arm64: Use the new GENERIC_IRQ_MULTI_HANDLER · 78ae2e1c
      Palmer Dabbelt 提交于
      It appears arm64 copied arm's GENERIC_IRQ_MULTI_HANDLER code, but made
      it unconditional.
      
      Converts the arm64 code to use the new generic code, which simply consists
      of deleting the arm64 code and setting MULTI_IRQ_HANDLER instead.
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: linux@armlinux.org.uk
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: jonas@southpole.se
      Cc: stefan.kristiansson@saunalahti.fi
      Cc: shorne@gmail.com
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: nicolas.pitre@linaro.org
      Cc: vladimir.murzin@arm.com
      Cc: keescook@chromium.org
      Cc: jinb.park7@gmail.com
      Cc: yamada.masahiro@socionext.com
      Cc: alexandre.belloni@bootlin.com
      Cc: pombredanne@nexb.com
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: kstewart@linuxfoundation.org
      Cc: jhogan@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ard.biesheuvel@linaro.org
      Cc: james.morse@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: openrisc@lists.librecores.org
      Link: https://lkml.kernel.org/r/20180622170126.6308-4-palmer@sifive.com
      78ae2e1c
  5. 02 8月, 2018 3 次提交
  6. 26 7月, 2018 1 次提交
  7. 24 7月, 2018 1 次提交
    • A
      arm64: fix ACPI dependencies · 2c870e61
      Arnd Bergmann 提交于
      Kconfig reports a warning on x86 builds after the ARM64 dependency
      was added.
      
      drivers/acpi/Kconfig:6:error: recursive dependency detected!
      drivers/acpi/Kconfig:6:       symbol ACPI depends on EFI
      
      This rephrases the dependency to keep the ARM64 details out of the
      shared Kconfig file, so Kconfig no longer gets confused by it.
      
      For consistency, all three architectures that support ACPI now
      select ARCH_SUPPORTS_ACPI in exactly the configuration in which
      they allow it. We still need the 'default x86', as each one
      wants a different default: default-y on x86, default-n on arm64,
      and always-y on ia64.
      
      Fixes: 5bcd4408 ("drivers: acpi: add dependency of EFI for arm64")
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      2c870e61
  8. 12 7月, 2018 1 次提交
    • M
      arm64: implement syscall wrappers · 4378a7d4
      Mark Rutland 提交于
      To minimize the risk of userspace-controlled values being used under
      speculation, this patch adds pt_regs based syscall wrappers for arm64,
      which pass the minimum set of required userspace values to syscall
      implementations. For each syscall, a wrapper which takes a pt_regs
      argument is automatically generated, and this extracts the arguments
      before calling the "real" syscall implementation.
      
      Each syscall has three functions generated:
      
      * __do_<compat_>sys_<name> is the "real" syscall implementation, with
        the expected prototype.
      
      * __se_<compat_>sys_<name> is the sign-extension/narrowing wrapper,
        inherited from common code. This takes a series of long parameters,
        casting each to the requisite types required by the "real" syscall
        implementation in __do_<compat_>sys_<name>.
      
        This wrapper *may* not be necessary on arm64 given the AAPCS rules on
        unused register bits, but it seemed safer to keep the wrapper for now.
      
      * __arm64_<compat_>_sys_<name> takes a struct pt_regs pointer, and
        extracts *only* the relevant register values, passing these on to the
        __se_<compat_>sys_<name> wrapper.
      
      The syscall invocation code is updated to handle the calling convention
      required by __arm64_<compat_>_sys_<name>, and passes a single struct
      pt_regs pointer.
      
      The compiler can fold the syscall implementation and its wrappers, such
      that the overhead of this approach is minimized.
      
      Note that we play games with sys_ni_syscall(). It can't be defined with
      SYSCALL_DEFINE0() because we must avoid the possibility of error
      injection. Additionally, there are a couple of locations where we need
      to call it from C code, and we don't (currently) have a
      ksys_ni_syscall().  While it has no wrapper, passing in a redundant
      pt_regs pointer is benign per the AAPCS.
      
      When ARCH_HAS_SYSCALL_WRAPPER is selected, no prototype is defines for
      sys_ni_syscall(). Since we need to treat it differently for in-kernel
      calls and the syscall tables, the prototype is defined as-required.
      
      The wrappers are largely the same as their x86 counterparts, but
      simplified as we don't have a variety of compat calling conventions that
      require separate stubs. Unlike x86, we have some zero-argument compat
      syscalls, and must define COMPAT_SYSCALL_DEFINE0() to ensure that these
      are also given an __arm64_compat_sys_ prefix.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      4378a7d4
  9. 11 7月, 2018 2 次提交
  10. 09 7月, 2018 1 次提交
  11. 05 7月, 2018 2 次提交
  12. 15 6月, 2018 1 次提交
  13. 08 6月, 2018 2 次提交
    • M
      arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig · f3a53f7b
      Masahiro Yamada 提交于
      This becomes much neater in Kconfig.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      f3a53f7b
    • L
      mm: introduce ARCH_HAS_PTE_SPECIAL · 3010a5ea
      Laurent Dufour 提交于
      Currently the PTE special supports is turned on in per architecture
      header files.  Most of the time, it is defined in
      arch/*/include/asm/pgtable.h depending or not on some other per
      architecture static definition.
      
      This patch introduce a new configuration variable to manage this
      directly in the Kconfig files.  It would later replace
      __HAVE_ARCH_PTE_SPECIAL.
      
      Here notes for some architecture where the definition of
      __HAVE_ARCH_PTE_SPECIAL is not obvious:
      
      arm
       __HAVE_ARCH_PTE_SPECIAL which is currently defined in
      arch/arm/include/asm/pgtable-3level.h which is included by
      arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set.
      So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE.
      
      powerpc
      __HAVE_ARCH_PTE_SPECIAL is defined in 2 files:
       - arch/powerpc/include/asm/book3s/64/pgtable.h
       - arch/powerpc/include/asm/pte-common.h
      The first one is included if (PPC_BOOK3S & PPC64) while the second is
      included in all the other cases.
      So select ARCH_HAS_PTE_SPECIAL all the time.
      
      sparc:
      __HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) &&
      defined(__arch64__) which are defined through the compiler in
      sparc/Makefile if !SPARC32 which I assume to be if SPARC64.
      So select ARCH_HAS_PTE_SPECIAL if SPARC64
      
      There is no functional change introduced by this patch.
      
      Link: http://lkml.kernel.org/r/1523433816-14460-2-git-send-email-ldufour@linux.vnet.ibm.comSigned-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Suggested-by: NJerome Glisse <jglisse@redhat.com>
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Albert Ou <albert@sifive.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Christophe LEROY <christophe.leroy@c-s.fr>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3010a5ea
  14. 01 6月, 2018 1 次提交
  15. 25 5月, 2018 1 次提交
  16. 23 5月, 2018 1 次提交
  17. 18 5月, 2018 1 次提交
  18. 16 5月, 2018 1 次提交
  19. 09 5月, 2018 2 次提交
    • C
      swiotlb: move the SWIOTLB config symbol to lib/Kconfig · 09230cbc
      Christoph Hellwig 提交于
      This way we have one central definition of it, and user can select it as
      needed.  The new option is not user visible, which is the behavior
      it had in most architectures, with a few notable exceptions:
      
       - On x86_64 and mips/loongson3 it used to be user selectable, but
         defaulted to y.  It now is unconditional, which seems like the right
         thing for 64-bit architectures without guaranteed availablity of
         IOMMUs.
       - on powerpc the symbol is user selectable and defaults to n, but
         many boards select it.  This change assumes no working setup
         required a manual selection, but if that turned out to be wrong
         we'll have to add another select statement or two for the respective
         boards.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      09230cbc
    • C
      arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig · 4965a687
      Christoph Hellwig 提交于
      Define this symbol if the architecture either uses 64-bit pointers or the
      PHYS_ADDR_T_64BIT is set.  This covers 95% of the old arch magic.  We only
      need an additional select for Xen on ARM (why anyway?), and we now always
      set ARCH_DMA_ADDR_T_64BIT on mips boards with 64-bit physical addressing
      instead of only doing it when highmem is set.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NJames Hogan <jhogan@kernel.org>
      4965a687