1. 12 10月, 2016 1 次提交
  2. 08 10月, 2016 3 次提交
    • C
      nmi_backtrace: generate one-line reports for idle cpus · 6727ad9e
      Chris Metcalf 提交于
      When doing an nmi backtrace of many cores, most of which are idle, the
      output is a little overwhelming and very uninformative.  Suppress
      messages for cpus that are idling when they are interrupted and just
      emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
      
      We do this by grouping all the cpuidle code together into a new
      .cpuidle.text section, and then checking the address of the interrupted
      PC to see if it lies within that section.
      
      This commit suitably tags x86 and tile idle routines, and only adds in
      the minimal framework for other architectures.
      
      Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.comSigned-off-by: NChris Metcalf <cmetcalf@mellanox.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Tested-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm]
      Tested-by: NPetr Mladek <pmladek@suse.com>
      Cc: Aaron Tomlin <atomlin@redhat.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6727ad9e
    • C
      nmi_backtrace: do a local dump_stack() instead of a self-NMI · 67766489
      Chris Metcalf 提交于
      Currently on arm there is code that checks whether it should call
      dump_stack() explicitly, to avoid trying to raise an NMI when the
      current context is not preemptible by the backtrace IPI.  Similarly, the
      forthcoming arch/tile support uses an IPI mechanism that does not
      support generating an NMI to self.
      
      Accordingly, move the code that guards this case into the generic
      mechanism, and invoke it unconditionally whenever we want a backtrace of
      the current cpu.  It seems plausible that in all cases, dump_stack()
      will generate better information than generating a stack from the NMI
      handler.  The register state will be missing, but that state is likely
      not particularly helpful in any case.
      
      Or, if we think it is helpful, we should be capturing and emitting the
      current register state in all cases when regs == NULL is passed to
      nmi_cpu_backtrace().
      
      Link: http://lkml.kernel.org/r/1472487169-14923-3-git-send-email-cmetcalf@mellanox.comSigned-off-by: NChris Metcalf <cmetcalf@mellanox.com>
      Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm]
      Reviewed-by: NPetr Mladek <pmladek@suse.com>
      Acked-by: NAaron Tomlin <atomlin@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      67766489
    • C
      nmi_backtrace: add more trigger_*_cpu_backtrace() methods · 9a01c3ed
      Chris Metcalf 提交于
      Patch series "improvements to the nmi_backtrace code" v9.
      
      This patch series modifies the trigger_xxx_backtrace() NMI-based remote
      backtracing code to make it more flexible, and makes a few small
      improvements along the way.
      
      The motivation comes from the task isolation code, where there are
      scenarios where we want to be able to diagnose a case where some cpu is
      about to interrupt a task-isolated cpu.  It can be helpful to see both
      where the interrupting cpu is, and also an approximation of where the
      cpu that is being interrupted is.  The nmi_backtrace framework allows us
      to discover the stack of the interrupted cpu.
      
      I've tested that the change works as desired on tile, and build-tested
      x86, arm, mips, and sparc64.  For x86 I confirmed that the generic
      cpuidle stuff as well as the architecture-specific routines are in the
      new cpuidle section.  For arm, mips, and sparc I just build-tested it
      and made sure the generic cpuidle routines were in the new cpuidle
      section, but I didn't attempt to figure out which the platform-specific
      idle routines might be.  That might be more usefully done by someone
      with platform experience in follow-up patches.
      
      This patch (of 4):
      
      Currently you can only request a backtrace of either all cpus, or all
      cpus but yourself.  It can also be helpful to request a remote backtrace
      of a single cpu, and since we want that, the logical extension is to
      support a cpumask as the underlying primitive.
      
      This change modifies the existing lib/nmi_backtrace.c code to take a
      cpumask as its basic primitive, and modifies the linux/nmi.h code to use
      the new "cpumask" method instead.
      
      The existing clients of nmi_backtrace (arm and x86) are converted to
      using the new cpumask approach in this change.
      
      The other users of the backtracing API (sparc64 and mips) are converted
      to use the cpumask approach rather than the all/allbutself approach.
      The mips code ignored the "include_self" boolean but with this change it
      will now also dump a local backtrace if requested.
      
      Link: http://lkml.kernel.org/r/1472487169-14923-2-git-send-email-cmetcalf@mellanox.comSigned-off-by: NChris Metcalf <cmetcalf@mellanox.com>
      Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm]
      Reviewed-by: NAaron Tomlin <atomlin@redhat.com>
      Reviewed-by: NPetr Mladek <pmladek@suse.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a01c3ed
  3. 29 9月, 2016 1 次提交
    • R
      ARM: 8616/1: dt: Respect property size when parsing CPUs · ba6dea4f
      Robin Murphy 提交于
      Whilst MPIDR values themselves are less than 32 bits, it is still
      perfectly valid for a DT to have #address-cells > 1 in the CPUs node,
      resulting in the "reg" property having leading zero cell(s). In that
      situation, the big-endian nature of the data conspires with the current
      behaviour of only reading the first cell to cause the kernel to think
      all CPUs have ID 0, and become resoundingly unhappy as a consequence.
      
      Take the full property length into account when parsing CPUs so as to
      be correct under any circumstances.
      
      Cc: Russell King <linux@armlinux.org.uk>
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ba6dea4f
  4. 24 9月, 2016 1 次提交
  5. 09 9月, 2016 1 次提交
  6. 06 9月, 2016 3 次提交
  7. 31 8月, 2016 4 次提交
    • A
      ARM: kernel: avoid brute force search on PLT generation · 66e94ba3
      Ard Biesheuvel 提交于
      Given that we now sort the relocation sections in a way that guarantees
      that entries that can share a single PLT entry end up adjacently, there
      is no a longer a need to go over the entire list to look for an existing
      entry that matches our jump target. If such a match exists, it was the
      last one to be emitted, so we can simply check the preceding slot.
      
      Note that this will still work correctly in the [theoretical] presence of
      call/jump relocations against SHN_UNDEF symbols with non-zero addends,
      although not optimally. Since the relocations are presented in the same
      order that we checked them for duplicates, any duplicates that we failed
      to spot the first time around will be accounted for in the PLT allocation
      so there is guaranteed to be sufficient space for them when actually
      emitting the PLT.
      
      For instance, the following sequence of relocations:
      
        000004d8  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        000004fc  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        0000050e  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        00000520  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        00000532  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        00000544  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        00000556  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        00000568  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        0000057a  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        0000058c  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        0000059e  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        000005b0  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        000005c2  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
        000005d4  00058b0a R_ARM_THM_CALL    00000000   warn_slowpath_null
      
      may result in several PLT entries to be allocated, and also emitted, if
      any of the entries in the middle refer to a Place that contains a non-zero
      addend (i.e., one for all the preceding zero-addend relocations, one for
      all the following zero-addend relocations, and one for the non-zero addend
      relocation itself)
      Tested-by: NJongsung Kim <neidhard.kim@lge.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      66e94ba3
    • A
      ARM: kernel: sort relocation sections before allocating PLTs · 1031a7e6
      Ard Biesheuvel 提交于
      The PLT allocation routines try to establish an upper bound on the
      number of PLT entries that will be required at relocation time, and
      optimize this by disregarding duplicates (i.e., PLT entries that will
      end up pointing to the same function). This is currently a O(n^2)
      algorithm, but we can greatly simplify this by
      - sorting the relocation section so that relocations that can use the
        same PLT entry will be listed adjacently,
      - disregard jump/call relocations with addends; these are highly unusual,
        for relocations against SHN_UNDEF symbols, and so we can simply allocate
        a PLT entry for each one we encounter, without trying to optimize away
        duplicates.
      Tested-by: NJongsung Kim <neidhard.kim@lge.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      1031a7e6
    • A
      ARM: kernel: allocate PLT entries only for external symbols · 05123fef
      Ard Biesheuvel 提交于
      When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
      modules no longer need to be within 16 MB (8 MB for Thumb2) of their
      targets. If they are further away, a PLT entry will be generated on the
      fly for each of them, which extends the range to the entire 32-bit
      address space.
      
      However, since these PLT entries will become the branch targets of the
      original jump and call instructions, the PLT itself needs to be in
      range, or we end up in the same situation we started in. Since the PLT
      is in a separate section, this essentially means that all jumps and calls
      inside the same module must be resolvable without PLT entries.
      
      The PLT allocation code executes before the module itself is loaded in
      its final location, and so it has to use a worst-case estimate for
      which jumps and calls will require an entry in the PLT at relocation
      time. As an optimization, this code deduplicates entries pointing to
      the same symbol, using a O(n^2) algorithm. However, it does not take
      the above into account, i.e., that PLT entries will only be needed for
      jump and call relocations against symbols that are not defined in the
      module.
      
      So disregard relocations against symbols that are defined in the module
      itself.
      
      As an additional minor optimization, ignore input sections that lack
      the SHF_EXECINSTR flag. Since jump and call relocations operate on
      executable instructions only, there is no need to look in sections that
      do not contain executable code.
      Tested-by: NJongsung Kim <neidhard.kim@lge.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      05123fef
    • A
      ARM: kernel: merge core and init PLTs · 35fa91ee
      Ard Biesheuvel 提交于
      The PLT code uses a separate .init.plt section to allocate PLT entries
      for jump and call instructions in __init code. However, even for fairly
      sizable modules like mac80211.ko, we only end up with a couple of PLT
      entries in the .init section, and so we can simplify the code
      significantly by emitting all PLT entries into the same section.
      Tested-by: NJongsung Kim <neidhard.kim@lge.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      35fa91ee
  8. 24 8月, 2016 1 次提交
    • J
      ftrace: Add return address pointer to ftrace_ret_stack · 9a7c348b
      Josh Poimboeuf 提交于
      Storing this value will help prevent unwinders from getting out of sync
      with the function graph tracer ret_stack.  Now instead of needing a
      stateful iterator, they can compare the return address pointer to find
      the right ret_stack entry.
      
      Note that an array of 50 ftrace_ret_stack structs is allocated for every
      task.  So when an arch implements this, it will add either 200 or 400
      bytes of memory usage per task (depending on whether it's a 32-bit or
      64-bit platform).
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nilay Vaish <nilayvaish@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/a95cfcc39e8f26b89a430c56926af0bb217bc0a1.1471607358.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9a7c348b
  9. 23 8月, 2016 1 次提交
  10. 16 8月, 2016 1 次提交
  11. 12 8月, 2016 1 次提交
  12. 11 8月, 2016 1 次提交
  13. 10 8月, 2016 1 次提交
  14. 04 8月, 2016 1 次提交
  15. 03 8月, 2016 3 次提交
  16. 15 7月, 2016 1 次提交
  17. 14 7月, 2016 2 次提交
  18. 07 7月, 2016 1 次提交
  19. 06 7月, 2016 1 次提交
  20. 02 7月, 2016 2 次提交
    • M
      ARM: 8577/1: Fix Cortex-A15 798181 errata initialization · f6492164
      Matija Glavinic Pecotic 提交于
      Current errata initialization doesn't take properly revision and REVIDR
      into account. Depending on the core revision, revidr bits should not be
      taken into account. Errata misleadingly declares r3p3 to be error-free,
      but this is not the case. Include rp3p3 in errata initialization.
      
      Here are possible fixes defined in revidr register for r2 and r3 [1,2]:
      
      r0p0-r2p1: No fixes applied
      
      r2p2,r2p3:
      
      REVIDR[4]: 798181 Moving a virtual page that is being accessed by
          an active process can lead to unexpected behavior
      REVIDR[9]: Not defined
      
      r2p4,r3p0,r3p1,r3p2:
      
      REVIDR[4]: 798181 Moving a virtual page that is being accessed by
         an active process can lead to unexpected behavior
      REVIDR[9]: 798181 Moving a virtual page that is being accessed by
         an active process can lead to unexpected behavior
         - This is an update to a previously released ECO.
      
      r3p3:
      
      REVIDR[4]: Reserved
      REVIDR[9]: 798181 Moving a virtual page that is being accessed by
         an active process can lead to unexpected behavior
         - This is an update to a previously released ECO.
      
      And here is proposed handling from the same document:
      
      * In r3p2 and earlier versions with REVIDR[4]= 0,the full workaround is
        required.
      * In r3p2 and earlier versions with REVIDR[4]=1, REVIDR[9]=0, only the
        portion of the workaround up to the end of step 6 is required.
      * In r3p2 and earlier versions with REVIDR[4]=1, REVIDR[9]=1, no
        workaround is required.
      * In r3p3, if REVIDR[9]=0, only the portion of the workaround up
        to the end of step 6 is required.
      * In r3p3, if REVIDR[9]=1, no workaround is required.
      
      These imply following:
      
      REVIDR[9] set -> No WA
      REVIDR[4] set, REVIDR[9] cleared -> Partial WA
      Both cleared -> Full WA
      
      Where certain bits should and should not be taken into account
      depending on whether they are defined for the revision.
      
      Although not explicitly mentioned in the errata note, REVIDR[9] set,
      with REVIDR[4] cleared is valid combination which requires no WA. This
      is confirmed by ARM support and errata will be updated.
      
      [1] ARM CortexTM-A15 MPCore - NEON
          Product revision r3
          Software Developers Errata Notice
          ARM-EPM-028093 v20.0 Released
      
      [2] ARM CortexTM-A15 MPCore - NEON
          Product Revision r2
          Software Developers Errata Notice
          ARM-EPM-028090 v19.3 Released
      Signed-off-by: NMatija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
      Reviewed-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f6492164
    • K
      ARM: 8583/1: mm: fix location of _etext · 14c4a533
      Kees Cook 提交于
      The _etext position is defined to be the end of the kernel text code,
      and should not include any part of the data segments. This interferes
      with things that might check memory ranges and expect executable code
      up to _etext. Just to be conservative, leave the kernel resource as
      it was, using __init_begin instead of _etext as the end mark.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      14c4a533
  21. 28 6月, 2016 2 次提交
  22. 24 6月, 2016 4 次提交
    • L
      ARM/PCI: Remove arch-specific pcibios_enable_device() · 313cb902
      Lorenzo Pieralisi 提交于
      On systems with PCI_PROBE_ONLY set, we rely on BAR assignments from
      firmware.  Previously we did not insert those resources into the resource
      tree, so we had to skip pci_enable_resources() because it fails if
      resources are not in the resource tree.
      
      Now that we *do* insert resources even when PCI_PROBE_ONLY is set, we no
      longer need the ARM-specific pcibios_enable_device().  Remove it so we
      use the generic version.
      
      [bhelgaas: changelog]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Russell King <linux@arm.linux.org.uk>
      313cb902
    • L
      ARM/PCI: Claim bus resources on PCI_PROBE_ONLY set-ups · b30742aa
      Lorenzo Pieralisi 提交于
      We claim PCI BAR and bridge window resources in pci_bus_assign_resources(),
      but when PCI_PROBE_ONLY is set, we treat those resources as immutable and
      don't call pci_bus_assign_resources(), so the resources aren't put in the
      resource tree.
      
      When the resources aren't in the tree, they don't show up in /proc/iomem,
      we can't detect conflicts, and we need special cases elsewhere for
      PCI_PROBE_ONLY or resources without a parent pointer.
      
      Claim all PCI BAR and window resources in the PCI_PROBE_ONLY case.
      
      If a PCI_PROBE_ONLY platform assigns conflicting resources, Linux can't fix
      the conflicts.  Previously we didn't notice the conflicts, but now we will,
      which may expose new failures.
      
      [bhelgaas: changelog, add resource comment, remove size/assign comments]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Russell King <linux@armlinux.org.uk>
      b30742aa
    • K
      arm: Remove unnecessary of_platform_populate with default match table · 850bea23
      Kefeng Wang 提交于
      After patch "of/platform: Add common method to populate default bus",
      it is possible for arch code to remove unnecessary callers of
      of_platform_populate with default match table.
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Ray Jui <rjui@broadcom.com>
      Cc: Lee Jones <lee@kernel.org>
      Cc: Krzysztof Halasa <khalasa@piap.pl>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Santosh Shilimkar <ssantosh@kernel.org>
      Cc: Roland Stigge <stigge@antcom.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: Viresh Kumar <vireshk@kernel.org>
      Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
      Cc: Tony Prisk <linux@prisktech.co.nz>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      850bea23
    • K
      of: iommu: make of_iommu_init() postcore_initcall_sync · bb8e15d6
      Kefeng Wang 提交于
      The of_iommu_init() is called multiple times by arch code,
      make it postcore_initcall_sync, then we can drop relevant
      calls fully.
      
      Note, the IOMMUs should have a chance to perform some basic
      initialisation before we start adding masters to them. So
      postcore_initcall_sync is good choice, it ensures of_iommu_init()
      called before of_platform_populate.
      Acked-by: NRich Felker <dalias@libc.org>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Acked-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NRob Herring <robh@kernel.org>
      bb8e15d6
  23. 23 6月, 2016 3 次提交