1. 08 Nov, 2018 1 commit
    • John Garry's avatar
      of, numa: Validate some distance map rules · 89c38422
      John Garry authored
      Currently the NUMA distance map parsing does not validate the distance
      table for the distance-matrix rules 1-2 in [1].
      However the arch NUMA code may enforce some of these rules, but not all.
      Such is the case for the arm64 port, which does not enforce the rule that
      the distance between separates nodes cannot equal LOCAL_DISTANCE.
      The patch adds the following rules validation:
      - distance of node to self equals LOCAL_DISTANCE
      - distance of separate nodes > LOCAL_DISTANCE
      This change avoids a yet-unresolved crash reported in [2].
      A note on dealing with symmetrical distances between nodes:
      Validating symmetrical distances between nodes is difficult. If it were
      mandated in the bindings that every distance must be recorded in the
      table, then it would be easy. However, it isn't.
      In addition to this, it is also possible to record [b, a] distance only
      (and not [a, b]). So, when processing the table for [b, a], we cannot
      assert that current distance of [a, b] != [b, a] as invalid, as [a, b]
      distance may not be present in the table and current distance would be
      default at REMOTE_DISTANCE.
      As such, we maintain the policy that we overwrite distance [a, b] = [b, a]
      for b > a. This policy is different to kernel ACPI SLIT validation, which
      allows non-symmetrical distances (ACPI spec SLIT rules allow it). However,
      the distance debug message is dropped as it may be misleading (for a distance
      which is later overwritten).
      Some final notes on semantics:
      - It is implied that it is the responsibility of the arch NUMA code to
        reset the NUMA distance map for an error in distance map parsing.
      - It is the responsibility of the FW NUMA topology parsing (whether OF or
        ACPI) to enforce NUMA distance rules, and not arch NUMA code.
      [1] Documents/devicetree/bindings/numa.txt
      [2] https://www.spinics.net/lists/arm-kernel/msg683304.html
      Cc: stable@vger.kernel.org # 4.7
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  2. 28 Sep, 2018 1 commit
  3. 07 Sep, 2018 1 commit
  4. 18 Apr, 2018 1 commit
    • Rob Herring's avatar
      of/numa: drop export of of_node_to_nid · 9cf7c9cb
      Rob Herring authored
      The "generic" implementation of of_node_to_nid is only used by
      arm64 and only in built-in code, so remove its export. Any
      device with a struct device should be able to use dev_to_node()
      instead. Also, exporting of_node_to_nid doesn't actually work if
      we build a module on an arch that doesn't select OF_NUMA nor provide its
      own of_node_to_nid implementation.
      Cc: Frank Rowand <frowand.list@gmail.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  5. 08 Jan, 2018 1 commit
  6. 18 Apr, 2017 1 commit
  7. 15 Nov, 2016 1 commit
    • David Daney's avatar
      of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible. · b6cc9474
      David Daney authored
      On arm64 NUMA kernels we can pass "numa=off" on the command line to
      disable NUMA.  A side effect of this is that kmalloc_node() calls to
      non-zero nodes will crash the system with an OOPS:
      [    0.000000] ITS@0x0000901000020000: allocated 2097152 Devices @10002000000 (flat, esz 8, psz 64K, shr 1)
      [    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00001680
      [    0.000000] pgd = fffffc0009470000
      [    0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003, *pmd=0000010ffff90003, *pte=0000000000000000
      [    0.000000] Internal error: Oops: 96000006 [#1] SMP
      [    0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68
      [    0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564
      [    0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514
      [    0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58
      [    0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc
      [    0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164
      [    0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c
      [    0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0
      [    0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360
      [    0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc
      [    0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298
      [    0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38
      [    0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30
      [    0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8
      [    0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c
      [    0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300)
      This is caused by code like this in kernel/irq/irqdomain.c
          domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
                        GFP_KERNEL, of_node_to_nid(of_node));
      When NUMA is disabled, the concept of a node is really undefined, so
      of_node_to_nid() should unconditionally return NUMA_NO_NODE.
      Fix by returning NUMA_NO_NODE when the nid is not in the set of
      possible nodes.
      Reported-by: default avatarGilbert Netzer <noname@pdc.kth.se>
      Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
      Cc: stable@vger.kernel.org # 4.7+
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  8. 09 Sep, 2016 6 commits
  9. 30 May, 2016 1 commit
  10. 15 Apr, 2016 1 commit