From: Rob Herring <robh@kernel.org>
To: John Garry <john.garry@huawei.com>
Cc: frowand.list@gmail.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxarm@huawei.com,
will.deacon@arm.com, anshuman.khandual@arm.com,
peterz@infradead.org
Subject: Re: [PATCH v2] of, numa: Validate some distance map rules
Date: Thu, 8 Nov 2018 07:08:26 -0600 [thread overview]
Message-ID: <20181108130826.GA18544@bogus> (raw)
In-Reply-To: <1541672223-131326-1-git-send-email-john.garry@huawei.com>
On Thu, Nov 08, 2018 at 06:17:03PM +0800, John Garry wrote:
> 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: John Garry <john.garry@huawei.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
Applied, thanks.
Rob
next prev parent reply other threads:[~2018-11-08 13:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 10:17 [PATCH v2] of, numa: Validate some distance map rules John Garry
2018-11-08 10:17 ` John Garry
2018-11-08 13:08 ` Rob Herring [this message]
2018-11-08 13:41 ` Anshuman Khandual
2018-11-08 15:01 ` John Garry
2018-11-08 15:01 ` John Garry
-- strict thread matches above, loose matches on Subject: below --
2018-11-08 10:16 John Garry
2018-11-08 10:16 ` John Garry
2018-11-08 10:05 John Garry
2018-11-08 10:10 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181108130826.GA18544@bogus \
--to=robh@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.