1. 09 8月, 2014 2 次提交
    • A
      arm64,ia64,ppc,s390,sh,tile,um,x86,mm: remove default gate area · a6c19dfe
      Andy Lutomirski 提交于
      The core mm code will provide a default gate area based on
      FIXADDR_USER_START and FIXADDR_USER_END if
      !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
      
      This default is only useful for ia64.  arm64, ppc, s390, sh, tile, 64-bit
      UML, and x86_32 have their own code just to disable it.  arm, 32-bit UML,
      and x86_64 have gate areas, but they have their own implementations.
      
      This gets rid of the default and moves the code into ia64.
      
      This should save some code on architectures without a gate area: it's now
      possible to inline the gate_area functions in the default case.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Acked-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [in principle]
      Acked-by: Richard Weinberger <richard@nod.at> [for um]
      Acked-by: Will Deacon <will.deacon@arm.com> [for arm64]
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nathan Lynch <Nathan_Lynch@mentor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6c19dfe
    • L
      lib/scatterlist: make ARCH_HAS_SG_CHAIN an actual Kconfig · 308c09f1
      Laura Abbott 提交于
      Rather than have architectures #define ARCH_HAS_SG_CHAIN in an
      architecture specific scatterlist.h, make it a proper Kconfig option and
      use that instead.  At same time, remove the header files are are now
      mostly useless and just include asm-generic/scatterlist.h.
      
      [sfr@canb.auug.org.au: powerpc files now need asm/dma.h]
      Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
      Acked-by: Thomas Gleixner <tglx@linutronix.de>			[x86]
      Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>	[powerpc]
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      308c09f1
  2. 01 8月, 2014 1 次提交
    • M
      arm64: add newline to I-cache policy string · ea171967
      Mark Rutland 提交于
      Due to a missing newline in the I-cache policy detection log output,
      it's possible to get some ratehr unfortunate output at boot time:
      
      CPU1: Booted secondary processor
      Detected VIPT I-cache on CPU1CPU2: Booted secondary processor
      Detected VIPT I-cache on CPU2CPU3: Booted secondary processor
      Detected VIPT I-cache on CPU3CPU4: Booted secondary processor
      Detected PIPT I-cache on CPU4CPU5: Booted secondary processor
      Detected PIPT I-cache on CPU5Brought up 6 CPUs
      SMP: Total of 6 processors activated.
      
      This patch adds the missing newline to the format string, cleaning up
      the output.
      
      Fixes: 59ccc0d4 ("arm64: cachetype: report weakest cache policy")
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      ea171967
  3. 31 7月, 2014 3 次提交
  4. 30 7月, 2014 2 次提交
  5. 29 7月, 2014 1 次提交
  6. 28 7月, 2014 1 次提交
  7. 25 7月, 2014 3 次提交
    • C
      arm64: gicv3: Allow GICv3 compilation with older binutils · 72c58395
      Catalin Marinas 提交于
      GICv3 introduces new system registers accessible with the full msr/mrs
      syntax (e.g. mrs x0, Sop0_op1_CRm_CRn_op2). However, only recent
      binutils understand the new syntax. This patch introduces msr_s/mrs_s
      assembly macros which generate the equivalent instructions above and
      converts the existing GICv3 code (both drivers/irqchip/ and
      arch/arm64/kernel/).
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NOlof Johansson <olof@lixom.net>
      Tested-by: NOlof Johansson <olof@lixom.net>
      Suggested-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NJason Cooper <jason@lakedaemon.net>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      72c58395
    • M
      arm64: fix soft lockup due to large tlb flush range · 05ac6530
      Mark Salter 提交于
      Under certain loads, this soft lockup has been observed:
      
         BUG: soft lockup - CPU#2 stuck for 22s! [ip6tables:1016]
         Modules linked in: ip6t_rpfilter ip6t_REJECT cfg80211 rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vfat fat efivarfs xfs libcrc32c
      
         CPU: 2 PID: 1016 Comm: ip6tables Not tainted 3.13.0-0.rc7.30.sa2.aarch64 #1
         task: fffffe03e81d1400 ti: fffffe03f01f8000 task.ti: fffffe03f01f8000
         PC is at __cpu_flush_kern_tlb_range+0xc/0x40
         LR is at __purge_vmap_area_lazy+0x28c/0x3ac
         pc : [<fffffe000009c5cc>] lr : [<fffffe0000182710>] pstate: 80000145
         sp : fffffe03f01fbb70
         x29: fffffe03f01fbb70 x28: fffffe03f01f8000
         x27: fffffe0000b19000 x26: 00000000000000d0
         x25: 000000000000001c x24: fffffe03f01fbc50
         x23: fffffe03f01fbc58 x22: fffffe03f01fbc10
         x21: fffffe0000b2a3f8 x20: 0000000000000802
         x19: fffffe0000b2a3c8 x18: 000003fffdf52710
         x17: 000003ff9d8bb910 x16: fffffe000050fbfc
         x15: 0000000000005735 x14: 000003ff9d7e1a5c
         x13: 0000000000000000 x12: 000003ff9d7e1a5c
         x11: 0000000000000007 x10: fffffe0000c09af0
         x9 : fffffe0000ad1000 x8 : 000000000000005c
         x7 : fffffe03e8624000 x6 : 0000000000000000
         x5 : 0000000000000000 x4 : 0000000000000000
         x3 : fffffe0000c09cc8 x2 : 0000000000000000
         x1 : 000fffffdfffca80 x0 : 000fffffcd742150
      
      The __cpu_flush_kern_tlb_range() function looks like:
      
        ENTRY(__cpu_flush_kern_tlb_range)
      	dsb	sy
      	lsr	x0, x0, #12
      	lsr	x1, x1, #12
        1:	tlbi	vaae1is, x0
      	add	x0, x0, #1
      	cmp	x0, x1
      	b.lo	1b
      	dsb	sy
      	isb
      	ret
        ENDPROC(__cpu_flush_kern_tlb_range)
      
      The above soft lockup shows the PC at tlbi insn with:
      
        x0 = 0x000fffffcd742150
        x1 = 0x000fffffdfffca80
      
      So __cpu_flush_kern_tlb_range has 0x128ba930 tlbi flushes left
      after it has already been looping for 23 seconds!.
      
      Looking up one frame at __purge_vmap_area_lazy(), there is:
      
      	...
      	list_for_each_entry_rcu(va, &vmap_area_list, list) {
      		if (va->flags & VM_LAZY_FREE) {
      			if (va->va_start < *start)
      				*start = va->va_start;
      			if (va->va_end > *end)
      				*end = va->va_end;
      			nr += (va->va_end - va->va_start) >> PAGE_SHIFT;
      			list_add_tail(&va->purge_list, &valist);
      			va->flags |= VM_LAZY_FREEING;
      			va->flags &= ~VM_LAZY_FREE;
      		}
      	}
      	...
      	if (nr || force_flush)
      		flush_tlb_kernel_range(*start, *end);
      
      So if two areas are being freed, the range passed to
      flush_tlb_kernel_range() may be as large as the vmalloc
      space. For arm64, this is ~240GB for 4k pagesize and ~2TB
      for 64kpage size.
      
      This patch works around this problem by adding a loop limit.
      If the range is larger than the limit, use flush_tlb_all()
      rather than flushing based on individual pages. The limit
      chosen is arbitrary as the TLB size is implementation
      specific and not accessible in an architected way. The aim
      of the arbitrary limit is to avoid soft lockup.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      [catalin.marinas@arm.com: commit log update]
      [catalin.marinas@arm.com: marginal optimisation]
      [catalin.marinas@arm.com: changed to MAX_TLB_RANGE and added comment]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      05ac6530
    • A
      arm64/crypto: fix makefile rule for aes-glue-%.o · 7c2105fb
      Andreas Schwab 提交于
      This fixes the following build failure when building with CONFIG_MODVERSIONS
      enabled:
      
        CC [M]  arch/arm64/crypto/aes-glue-ce.o
      ld: cannot find arch/arm64/crypto/aes-glue-ce.o: No such file or directory
      make[1]: *** [arch/arm64/crypto/aes-ce-blk.o] Error 1
      make: *** [arch/arm64/crypto] Error 2
      
      The $(obj)/aes-glue-%.o rule only creates $(obj)/.tmp_aes-glue-ce.o, it
      should use if_changed_rule instead of if_changed_dep.
      Signed-off-by: NAndreas Schwab <schwab@suse.de>
      [ardb: mention CONFIG_MODVERSIONS in commit log]
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      7c2105fb
  8. 24 7月, 2014 4 次提交
  9. 23 7月, 2014 13 次提交
  10. 21 7月, 2014 1 次提交
  11. 19 7月, 2014 4 次提交
    • A
      efi/arm64: Handle missing virtual mapping for UEFI System Table · 99a5603e
      Ard Biesheuvel 提交于
      If we cannot resolve the virtual address of the UEFI System Table, its
      physical offset must be missing from the virtual memory map, and there
      is really no point in proceeding with installing the virtual memory map
      and the runtime services dispatch table. So back out gracefully.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NMark Salter <msalter@redhat.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      99a5603e
    • A
      efi: efistub: Convert into static library · f4f75ad5
      Ard Biesheuvel 提交于
      This patch changes both x86 and arm64 efistub implementations
      from #including shared .c files under drivers/firmware/efi to
      building shared code as a static library.
      
      The x86 code uses a stub built into the boot executable which
      uncompresses the kernel at boot time. In this case, the library is
      linked into the decompressor.
      
      In the arm64 case, the stub is part of the kernel proper so the library
      is linked into the kernel proper as well.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f4f75ad5
    • S
      arm64, ftrace: Remove check of obsolete variable function_trace_stop · ac694fda
      Steven Rostedt (Red Hat) 提交于
      Nothing sets function_trace_stop to disable function tracing anymore.
      Remove the check for it in the arch code.
      
      arm64 was broken anyway, as it had an ifdef testing
       CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST which is only set if
      the arch supports the code (which it obviously did not), and
      it was testing a non existent ftrace_trace_stop instead of
      function_trace_stop.
      
      Link: http://lkml.kernel.org/r/20140627124421.GP26276@arm.com
      
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      ac694fda
    • M
      arm64: cpuinfo: print info for all CPUs · d7a49086
      Mark Rutland 提交于
      Currently reading /proc/cpuinfo will result in information being read
      out of the MIDR_EL1 of the current CPU, and the information is not
      associated with any particular logical CPU number.
      
      This is problematic for systems with heterogeneous CPUs (i.e.
      big.LITTLE) where MIDR fields will vary across CPUs, and the output will
      differ depending on the executing CPU.
      
      This patch reorganises the code responsible for /proc/cpuinfo to print
      information per-cpu. In the process, we perform several cleanups:
      
      * Property names are coerced to lower-case (to match "processor" as per
        glibc's expectations).
      * Property names are simplified and made to match the MIDR field names.
      * Revision is changed to hex as with every other field.
      * The meaningless Architecture property is removed.
      * The ripe-for-abuse Machine field is removed.
      
      The features field (a human-readable representation of the hwcaps)
      remains printed once, as this is expected to remain in use as the
      globally support CPU features. To enable the possibility of the addition
      of per-cpu HW feature information later, this is printed before any
      CPU-specific information.
      
      Comments are added to guide userspace developers in the right direction
      (using the hwcaps provided in auxval). Hopefully where userspace
      applications parse /proc/cpuinfo rather than using the readily available
      hwcaps, they limit themselves to reading said first line.
      
      If CPU features differ from each other, the previously installed sanity
      checks will give us some advance notice with warnings and
      TAINT_CPU_OUT_OF_SPEC. If we are lucky, we will never see such systems.
      Rework will be required in many places to support such systems anyway.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marcus Shawcroft <marcus.shawcroft@arm.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      [catalin.marinas@arm.com: remove machine_name as it is no longer reported]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      d7a49086
  12. 18 7月, 2014 5 次提交