1. 12 7月, 2018 19 次提交
  2. 11 7月, 2018 1 次提交
  3. 10 7月, 2018 1 次提交
    • L
      arm64: numa: rework ACPI NUMA initialization · e1896249
      Lorenzo Pieralisi 提交于
      Current ACPI ARM64 NUMA initialization code in
      
      acpi_numa_gicc_affinity_init()
      
      carries out NUMA nodes creation and cpu<->node mappings at the same time
      in the arch backend so that a single SRAT walk is needed to parse both
      pieces of information.  This implies that the cpu<->node mappings must
      be stashed in an array (sized NR_CPUS) so that SMP code can later use
      the stashed values to avoid another SRAT table walk to set-up the early
      cpu<->node mappings.
      
      If the kernel is configured with a NR_CPUS value less than the actual
      processor entries in the SRAT (and MADT), the logic in
      acpi_numa_gicc_affinity_init() is broken in that the cpu<->node mapping
      is only carried out (and stashed for future use) only for a number of
      SRAT entries up to NR_CPUS, which do not necessarily correspond to the
      possible cpus detected at SMP initialization in
      acpi_map_gic_cpu_interface() (ie MADT and SRAT processor entries order
      is not enforced), which leaves the kernel with broken cpu<->node
      mappings.
      
      Furthermore, given the current ACPI NUMA code parsing logic in
      acpi_numa_gicc_affinity_init(), PXM domains for CPUs that are not parsed
      because they exceed NR_CPUS entries are not mapped to NUMA nodes (ie the
      PXM corresponding node is not created in the kernel) leaving the system
      with a broken NUMA topology.
      
      Rework the ACPI ARM64 NUMA initialization process so that the NUMA
      nodes creation and cpu<->node mappings are decoupled. cpu<->node
      mappings are moved to SMP initialization code (where they are needed),
      at the cost of an extra SRAT walk so that ACPI NUMA mappings can be
      batched before being applied, fixing current parsing pitfalls.
      Acked-by: NHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: NJohn Garry <john.garry@huawei.com>
      Fixes: d8b47fca ("arm64, ACPI, NUMA: NUMA support based on SRAT and
      SLIT")
      Link: http://lkml.kernel.org/r/1527768879-88161-2-git-send-email-xiexiuqi@huawei.comReported-by: NXie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Punit Agrawal <punit.agrawal@arm.com>
      Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Xie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      e1896249
  4. 06 7月, 2018 14 次提交
  5. 05 7月, 2018 4 次提交
    • S
      arm64: Handle mismatched cache type · 314d53d2
      Suzuki K Poulose 提交于
      Track mismatches in the cache type register (CTR_EL0), other
      than the D/I min line sizes and trap user accesses if there are any.
      
      Fixes: be68a8aa ("arm64: cpufeature: Fix CTR_EL0 field definitions")
      Cc: <stable@vger.kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      314d53d2
    • S
      arm64: Fix mismatched cache line size detection · 4c4a39dd
      Suzuki K Poulose 提交于
      If there is a mismatch in the I/D min line size, we must
      always use the system wide safe value both in applications
      and in the kernel, while performing cache operations. However,
      we have been checking more bits than just the min line sizes,
      which triggers false negatives. We may need to trap the user
      accesses in such cases, but not necessarily patch the kernel.
      
      This patch fixes the check to do the right thing as advertised.
      A new capability will be added to check mismatches in other
      fields and ensure we trap the CTR accesses.
      
      Fixes: be68a8aa ("arm64: cpufeature: Fix CTR_EL0 field definitions")
      Cc: <stable@vger.kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      4c4a39dd
    • M
      arm64: kexec: always reset to EL2 if present · 76f4e2da
      Mark Rutland 提交于
      Currently machine_kexec() doesn't reset to EL2 in the case of a
      crashdump kernel. This leaves potentially dodgy state active at EL2, and
      means that if the crashdump kernel attempts to online secondary CPUs,
      these will be booted as mismatched ELs.
      
      Let's reset to EL2, as we do in all other cases, and simplify things. If
      EL2 state is corrupt, things are already sufficiently bad that kdump is
      unlikely to work, and it's best-effort regardless.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      76f4e2da
    • M
      arm64: fix infinite stacktrace · 7e7df71f
      Mikulas Patocka 提交于
      I've got this infinite stacktrace when debugging another problem:
      [  908.795225] INFO: rcu_preempt detected stalls on CPUs/tasks:
      [  908.796176]  1-...!: (1 GPs behind) idle=952/1/4611686018427387904 softirq=1462/1462 fqs=355
      [  908.797692]  2-...!: (1 GPs behind) idle=f42/1/4611686018427387904 softirq=1550/1551 fqs=355
      [  908.799189]  (detected by 0, t=2109 jiffies, g=130, c=129, q=235)
      [  908.800284] Task dump for CPU 1:
      [  908.800871] kworker/1:1     R  running task        0    32      2 0x00000022
      [  908.802127] Workqueue: writecache-writeabck writecache_writeback [dm_writecache]
      [  908.820285] Call trace:
      [  908.824785]  __switch_to+0x68/0x90
      [  908.837661]  0xfffffe00603afd90
      [  908.844119]  0xfffffe00603afd90
      [  908.850091]  0xfffffe00603afd90
      [  908.854285]  0xfffffe00603afd90
      [  908.863538]  0xfffffe00603afd90
      [  908.865523]  0xfffffe00603afd90
      
      The machine just locked up and kept on printing the same line over and
      over again. This patch fixes it.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      7e7df71f
  6. 28 6月, 2018 1 次提交