From: Qian Cai <cai@lca.pw>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] arm64/sve: Eliminate data races on sve_default_vl
Date: Tue, 16 Jun 2020 09:18:08 -0400 [thread overview]
Message-ID: <20200616131808.GA1040@lca.pw> (raw)
In-Reply-To: <1591808590-20210-3-git-send-email-Dave.Martin@arm.com>
On Wed, Jun 10, 2020 at 06:03:10PM +0100, Dave Martin wrote:
> sve_default_vl can be modified via the /proc/sys/abi/sve_default_vl
> sysctl concurrently with use, and modified concurrently by multiple
> threads.
>
> Adding a lock for this seems overkill, and I don't want to think any
> more than necessary, so just define wrappers using READ_ONCE()/
> WRITE_ONCE().
>
> This will avoid the possibility of torn accesses and repeated loads
> and stores.
>
> There's no evidence yet that this is going wrong in practice: this
> is just hygiene. For generic sysctl users, it would be better to
> build this kind of thing into the sysctl common code somehow.
>
> Reported-by: Will Deacon <will@kernel.org>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
While this original patch looks correct, linux-next has this,
[will: move set_sve_default_vl() inside #ifdef to squash allnoconfig warning]
1e570f512cbd ("arm64/sve: Eliminate data races on sve_default_vl")
which causes an error with CONFIG_ARM64_SVE=n,
This .config,
https://raw.githubusercontent.com/cailca/linux-mm/master/arm64.config
arch/arm64/kernel/fpsimd.c: In function ‘sve_proc_do_default_vl’:
arch/arm64/kernel/fpsimd.c:375:2: error: implicit declaration of
function ‘set_sve_default_vl’; did you mean ‘get_sve_default_vl’?
[-Werror=implicit-function-declaration]
set_sve_default_vl(find_supported_vector_length(vl));
^~~~~~~~~~~~~~~~~~
get_sve_default_vl
> ---
>
> Build-tested only, but it seems pretty straightforward.
>
> arch/arm64/kernel/fpsimd.c | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 94289d1..19865c9 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -12,6 +12,7 @@
> #include <linux/bug.h>
> #include <linux/cache.h>
> #include <linux/compat.h>
> +#include <linux/compiler.h>
> #include <linux/cpu.h>
> #include <linux/cpu_pm.h>
> #include <linux/kernel.h>
> @@ -119,7 +120,17 @@ struct fpsimd_last_state_struct {
> static DEFINE_PER_CPU(struct fpsimd_last_state_struct, fpsimd_last_state);
>
> /* Default VL for tasks that don't set it explicitly: */
> -static int sve_default_vl = -1;
> +static int __sve_default_vl = -1;
> +
> +static int get_sve_default_vl(void)
> +{
> + return READ_ONCE(__sve_default_vl);
> +}
> +
> +static void set_sve_default_vl(int val)
> +{
> + WRITE_ONCE(__sve_default_vl, val);
> +}
>
> #ifdef CONFIG_ARM64_SVE
>
> @@ -345,7 +356,7 @@ static int sve_proc_do_default_vl(struct ctl_table *table, int write,
> loff_t *ppos)
> {
> int ret;
> - int vl = sve_default_vl;
> + int vl = get_sve_default_vl();
> struct ctl_table tmp_table = {
> .data = &vl,
> .maxlen = sizeof(vl),
> @@ -362,7 +373,7 @@ static int sve_proc_do_default_vl(struct ctl_table *table, int write,
> if (!sve_vl_valid(vl))
> return -EINVAL;
>
> - sve_default_vl = find_supported_vector_length(vl);
> + set_sve_default_vl(find_supported_vector_length(vl));
> return 0;
> }
>
> @@ -869,7 +880,7 @@ void __init sve_setup(void)
> * For the default VL, pick the maximum supported value <= 64.
> * VL == 64 is guaranteed not to grow the signal frame.
> */
> - sve_default_vl = find_supported_vector_length(64);
> + set_sve_default_vl(find_supported_vector_length(64));
>
> bitmap_andnot(tmp_map, sve_vq_partial_map, sve_vq_map,
> SVE_VQ_MAX);
> @@ -890,7 +901,7 @@ void __init sve_setup(void)
> pr_info("SVE: maximum available vector length %u bytes per vector\n",
> sve_max_vl);
> pr_info("SVE: default vector length %u bytes per vector\n",
> - sve_default_vl);
> + get_sve_default_vl());
>
> /* KVM decides whether to support mismatched systems. Just warn here: */
> if (sve_max_virtualisable_vl < sve_max_vl)
> @@ -1030,13 +1041,13 @@ void fpsimd_flush_thread(void)
> * vector length configured: no kernel task can become a user
> * task without an exec and hence a call to this function.
> * By the time the first call to this function is made, all
> - * early hardware probing is complete, so sve_default_vl
> + * early hardware probing is complete, so __sve_default_vl
> * should be valid.
> * If a bug causes this to go wrong, we make some noise and
> * try to fudge thread.sve_vl to a safe value here.
> */
> vl = current->thread.sve_vl_onexec ?
> - current->thread.sve_vl_onexec : sve_default_vl;
> + current->thread.sve_vl_onexec : get_sve_default_vl();
>
> if (WARN_ON(!sve_vl_valid(vl)))
> vl = SVE_VL_MIN;
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-16 13:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 17:03 [PATCH 0/2] arm64/sve: Misc fixes Dave Martin
2020-06-10 17:03 ` [PATCH 1/2] docs/arm64: Fix typo'd #define in sve.rst Dave Martin
2020-06-10 17:03 ` [PATCH 2/2] arm64/sve: Eliminate data races on sve_default_vl Dave Martin
2020-06-16 13:18 ` Qian Cai [this message]
2020-06-16 15:04 ` Will Deacon
2020-06-16 16:17 ` Dave Martin
2020-06-16 17:19 ` Will Deacon
2020-06-17 9:40 ` Dave Martin
2020-06-17 10:08 ` Will Deacon
2020-06-17 11:06 ` Dave Martin
2020-06-15 16:34 ` [PATCH 0/2] arm64/sve: Misc fixes Will Deacon
2020-06-16 9:56 ` Dave Martin
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=20200616131808.GA1040@lca.pw \
--to=cai@lca.pw \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.org \
/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.