From: Peter Collingbourne <hidden> Date: 2021-07-13 23:50:12
On some CPUs the performance of MTE in synchronous mode is similar
to that of asynchronous mode. This makes it worthwhile to enable
synchronous mode on those CPUs when asynchronous mode is requested,
in order to gain the error detection benefits of synchronous mode
without the performance downsides. Therefore, make it possible for
user programs to opt into upgrading to synchronous mode on those CPUs.
This is done by introducing a notion of a preferred TCF mode, which is
controlled on a per-CPU basis by a sysfs node. The existing SYNC and
ASYNC TCF settings are repurposed as bitfields that specify a set of
possible modes. If the preferred TCF mode for a particular CPU is in
the user-provided mode set (this will always be the case for mode sets
containing more than one mode because the kernel only supports two tag
checking modes, but future kernels may support more modes) then that
mode is used when running on that CPU, otherwise one of the modes in
the task's mode set will be selected in a currently unspecified manner.
v8:
- split into multiple patches
- remove MTE_CTRL_TCF_NONE
- improve documentation
- disable preemption and add comment to mte_update_sctlr_user
- bring back PR_MTE_TCF_SHIFT for source compatibility
- address formatting nit
v7:
- switch to new API proposed on list
v6:
- switch to strings in sysfs nodes instead of TCF values
v5:
- updated documentation
- address some nits in mte.c
v4:
- switch to new mte_ctrl field
- make register_mte_upgrade_async_sysctl return an int
- change the sysctl to take 0 or 1 instead of raw TCF values
- "same as" -> "similar to"
v3:
- drop the device tree support
- add documentation
- add static_assert to ensure no overlap with real HW bits
- move per-CPU variable initialization to mte.c
- use smp_call_function_single instead of stop_machine
v2:
- make it an opt-in behavior
- change the format of the device tree node
- also allow controlling the feature via sysfs
Peter Collingbourne (5):
arm64: mte: rename gcr_user_excl to mte_ctrl
arm64: mte: change ASYNC and SYNC TCF settings into bitfields
arm64: move preemption disablement to prctl handlers
arm64: mte: introduce a per-CPU tag checking mode preference
Documentation: document the preferred tag checking mode feature
.../ABI/testing/sysfs-devices-system-cpu | 18 +++
.../arm64/memory-tagging-extension.rst | 48 +++++-
arch/arm64/include/asm/pointer_auth.h | 12 +-
arch/arm64/include/asm/processor.h | 10 +-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 4 +-
arch/arm64/kernel/mte.c | 139 ++++++++++++------
arch/arm64/kernel/pointer_auth.c | 10 +-
arch/arm64/kernel/process.c | 21 +--
include/uapi/linux/prctl.h | 11 +-
10 files changed, 189 insertions(+), 86 deletions(-)
--
2.32.0.93.g670b81a890-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Peter Collingbourne <hidden> Date: 2021-07-13 23:50:13
We are going to use this field to store more data. To prepare for
that, rename it and change the users to rely on the bit position of
gcr_user_excl in mte_ctrl.
Link: https://linux-review.googlesource.com/id/Ie1fd18e480100655f5d22137f5b22f4f3a9f9e2e
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/processor.h | 5 ++++-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 4 ++--
arch/arm64/kernel/mte.c | 14 ++++++++------
4 files changed, 15 insertions(+), 10 deletions(-)
From: Peter Collingbourne <hidden> Date: 2021-07-13 23:50:28
Allow the user program to specify both ASYNC and SYNC TCF modes by
repurposing the existing constants as bitfields. This will allow the
kernel to select one of the modes on behalf of the user program. With
this patch the kernel will always select async mode, but a subsequent
patch will make this configurable.
Link: https://linux-review.googlesource.com/id/Icc5923c85a8ea284588cc399ae74fd19ec291230
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
v9:
- make mte_update_sctlr_user static
arch/arm64/include/asm/processor.h | 3 ++
arch/arm64/kernel/mte.c | 70 ++++++++++++------------------
include/uapi/linux/prctl.h | 11 ++---
3 files changed, 37 insertions(+), 47 deletions(-)
@@ -216,15 +221,16 @@ void mte_thread_init_user(void)dsb(ish);write_sysreg_s(0,SYS_TFSRE0_EL1);clear_thread_flag(TIF_MTE_ASYNC_FAULT);-/* disable tag checking */-set_task_sctlr_el1((current->thread.sctlr_user&~SCTLR_EL1_TCF0_MASK)|-SCTLR_EL1_TCF0_NONE);-/* reset tag generation mask */-set_gcr_el1_excl(SYS_GCR_EL1_EXCL_MASK);+/* disable tag checking and reset tag generation mask */+current->thread.mte_ctrl=MTE_CTRL_GCR_USER_EXCL_MASK;+mte_update_sctlr_user(current);+set_task_sctlr_el1(current->thread.sctlr_user);}voidmte_thread_switch(structtask_struct*next){+mte_update_sctlr_user(next);+/**CheckifanasynctagexceptionoccurredatEL1.*
From: Peter Collingbourne <hidden> Date: 2021-07-13 23:50:30
In the next patch, we will start reading sctlr_user from
mte_update_sctlr_user and subsequently writing a new value based on the
task's TCF setting and potentially the per-CPU TCF preference. This
means that we need to be careful to disable preemption around any
code sequences that read from sctlr_user and subsequently write to
sctlr_user and/or SCTLR_EL1, so that we don't end up writing a stale
value (based on the previous CPU's TCF preference) to either of them.
We currently have four such sequences, in the prctl handlers for
PR_SET_TAGGED_ADDR_CTRL and PR_PAC_SET_ENABLED_KEYS, as well as in
the task initialization code that resets the prctl settings. Change
the prctl handlers to disable preemption in the handlers themselves
rather than the functions that they call, and change the task
initialization code to call the respective prctl handlers instead of
setting sctlr_user directly.
As a result of this change, we no longer need the helper function
set_task_sctlr_el1, nor does its behavior make sense any more, so
remove it.
Signed-off-by: Peter Collingbourne <redacted>
Link: https://linux-review.googlesource.com/id/Ic0e8a0c00bb47d786c1e8011df0b7fe99bee4bb5
---
arch/arm64/include/asm/pointer_auth.h | 12 ++++++------
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/kernel/mte.c | 8 ++++----
arch/arm64/kernel/pointer_auth.c | 10 ++++++----
arch/arm64/kernel/process.c | 21 +++++++--------------
5 files changed, 24 insertions(+), 29 deletions(-)
@@ -222,9 +222,7 @@ void mte_thread_init_user(void)write_sysreg_s(0,SYS_TFSRE0_EL1);clear_thread_flag(TIF_MTE_ASYNC_FAULT);/* disable tag checking and reset tag generation mask */-current->thread.mte_ctrl=MTE_CTRL_GCR_USER_EXCL_MASK;-mte_update_sctlr_user(current);-set_task_sctlr_el1(current->thread.sctlr_user);+set_mte_ctrl(current,0);}voidmte_thread_switch(structtask_struct*next)
@@ -281,8 +279,10 @@ long set_mte_ctrl(struct task_struct *task, unsigned long arg)task->thread.mte_ctrl=mte_ctrl;if(task==current){+preempt_disable();mte_update_sctlr_user(task);-set_task_sctlr_el1(task->thread.sctlr_user);+update_sctlr_el1(task->thread.sctlr_user);+preempt_enable();}return0;
From: Peter Collingbourne <hidden> Date: 2021-07-13 23:50:43
Add a per-CPU sysfs node, mte_tcf_preferred, that allows the preferred
tag checking mode to be configured. The current possible values are
async and sync.
Link: https://linux-review.googlesource.com/id/I7493dcd533a2785a1437b16c3f6b50919f840854
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
v10:
- stop calling smp_call_function_single
arch/arm64/kernel/mte.c | 65 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 63 insertions(+), 2 deletions(-)
@@ -441,3 +451,54 @@ int mte_ptrace_copy_tags(struct task_struct *child, long request,returnret;}++staticssize_tmte_tcf_preferred_show(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+switch(per_cpu(mte_tcf_preferred,dev->id)){+caseMTE_CTRL_TCF_ASYNC:+returnsysfs_emit(buf,"async\n");+caseMTE_CTRL_TCF_SYNC:+returnsysfs_emit(buf,"sync\n");+default:+returnsysfs_emit(buf,"???\n");+}+}++staticssize_tmte_tcf_preferred_store(structdevice*dev,+structdevice_attribute*attr,+constchar*buf,size_tcount)+{+u64tcf;++if(sysfs_streq(buf,"async"))+tcf=MTE_CTRL_TCF_ASYNC;+elseif(sysfs_streq(buf,"sync"))+tcf=MTE_CTRL_TCF_SYNC;+else+return-EINVAL;++device_lock(dev);+per_cpu(mte_tcf_preferred,dev->id)=tcf;+device_unlock(dev);++returncount;+}+staticDEVICE_ATTR_RW(mte_tcf_preferred);++staticintregister_mte_tcf_preferred_sysctl(void)+{+unsignedintcpu;++if(!system_supports_mte())+return0;++for_each_possible_cpu(cpu){+per_cpu(mte_tcf_preferred,cpu)=MTE_CTRL_TCF_ASYNC;+device_create_file(get_cpu_device(cpu),+&dev_attr_mte_tcf_preferred);+}++return0;+}+subsys_initcall(register_mte_tcf_preferred_sysctl);
--
2.32.0.93.g670b81a890-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Peter Collingbourne <hidden> Date: 2021-07-13 23:51:03
Document the functionality added in the previous patches.
Link: https://linux-review.googlesource.com/id/I48217cc3e8b8da33abc08cbaddc11cf4360a1b86
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Will Deacon <will@kernel.org>
---
v10:
- document that setting the sysfs node may not take effect
immediately
- unabbreviate month name
v9:
- add documentation for sysfs node under Documentation/ABI
.../ABI/testing/sysfs-devices-system-cpu | 18 +++++++
.../arm64/memory-tagging-extension.rst | 48 ++++++++++++++++---
2 files changed, 59 insertions(+), 7 deletions(-)
@@ -640,3 +640,21 @@ Description: SPURR ticks for cpuX when it was idle. This sysfs interface exposes the number of SPURR ticks for cpuX when it was idle.++What: /sys/devices/system/cpu/cpuX/mte_tcf_preferred+Date: July 2021+Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>+Description: Preferred MTE tag checking mode++ When a user program specifies more than one MTE tag checking+ mode, this sysfs node is used to specify which mode should+ be preferred when running on that CPU. Possible values:++ ================ ==============================================+ "sync" Prefer synchronous mode+ "async" Prefer asynchronous mode+ ================ ==============================================++ Changes to this sysfs node may not take effect immediately.++ See also: Documentation/arm64/memory-tagging-extension.rst
@@ -77,14 +77,20 @@ configurable behaviours: address is unknown). The user can select the above modes, per thread, using the-``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where-``flags`` contain one of the following values in the ``PR_MTE_TCF_MASK``+``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags``+contains any number of the following values in the ``PR_MTE_TCF_MASK`` bit-field:--``PR_MTE_TCF_NONE`` - *Ignore* tag check faults+-``PR_MTE_TCF_NONE`` - *Ignore* tag check faults+ (ignored if combined with other options)-``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode-``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode+If no modes are specified, tag check faults are ignored. If a single+mode is specified, the program will run in that mode. If multiple+modes are specified, the mode is selected as described in the "Per-CPU+preferred tag checking modes" section below.+ The current tag check fault mode can be read using the``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call.
@@ -120,13 +126,39 @@ in the ``PR_MTE_TAG_MASK`` bit-field. interface provides an include mask. An include mask of ``0`` (exclusion mask ``0xffff``) results in the CPU always generating tag ``0``.+Per-CPU preferred tag checking mode+-----------------------------------++On some CPUs the performance of MTE in stricter tag checking modes+is similar to that of less strict tag checking modes. This makes it+worthwhile to enable stricter checks on those CPUs when a less strict+checking mode is requested, in order to gain the error detection+benefits of the stricter checks without the performance downsides. To+support this scenario, a privileged user may configure a stricter+tag checking mode as the CPU's preferred tag checking mode.++The preferred tag checking mode for each CPU is controlled by+``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a+privileged user may write the value ``async`` or ``sync``. The default+preferred mode for each CPU is ``async``.++To allow a program to potentially run in the CPU's preferred tag+checking mode, the user program may set multiple tag check fault mode+bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL,+flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking+mode is in the task's set of provided tag checking modes (this will+always be the case at present because the kernel only supports two+tag checking modes, but future kernels may support more modes), that+mode will be selected. Otherwise, one of the modes in the task's mode+set will be selected in a currently unspecified manner.+ Initial process state --------------------- On ``execve()``, the new process has the following configuration:-``PR_TAGGED_ADDR_ENABLE`` set to 0 (disabled)-- Tag checking mode set to ``PR_MTE_TCF_NONE``+- No tag checking modes are selected (tag check faults ignored)-``PR_MTE_TAG_MASK`` set to 0 (all tags excluded)-``PSTATE.TCO`` set to 0-``PROT_MTE`` not set on any of the initial memory maps
@@ -251,11 +283,13 @@ Example of correct usage return EXIT_FAILURE; /*-* Enable the tagged address ABI, synchronous MTE tag check faults and-* allow all non-zero tags in the randomly generated set.+* Enable the tagged address ABI, synchronous or asynchronous MTE+* tag check faults (based on per-CPU preference) and allow all+* non-zero tags in the randomly generated set. */ if (prctl(PR_SET_TAGGED_ADDR_CTRL,- PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | (0xfffe << PR_MTE_TAG_SHIFT),+ PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC |+ (0xfffe << PR_MTE_TAG_SHIFT), 0, 0, 0)) { perror("prctl() failed"); return EXIT_FAILURE;
--
2.32.0.93.g670b81a890-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-07-14 11:03:16
On Tue, Jul 13, 2021 at 04:47:57PM -0700, Peter Collingbourne wrote:
We are going to use this field to store more data. To prepare for
that, rename it and change the users to rely on the bit position of
gcr_user_excl in mte_ctrl.
Link: https://linux-review.googlesource.com/id/Ie1fd18e480100655f5d22137f5b22f4f3a9f9e2e
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/processor.h | 5 ++++-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 4 ++--
arch/arm64/kernel/mte.c | 14 ++++++++------
4 files changed, 15 insertions(+), 10 deletions(-)
I acked this one already, but here it is again:
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-07-14 11:03:50
On Tue, Jul 13, 2021 at 04:47:58PM -0700, Peter Collingbourne wrote:
Allow the user program to specify both ASYNC and SYNC TCF modes by
repurposing the existing constants as bitfields. This will allow the
kernel to select one of the modes on behalf of the user program. With
this patch the kernel will always select async mode, but a subsequent
patch will make this configurable.
Link: https://linux-review.googlesource.com/id/Icc5923c85a8ea284588cc399ae74fd19ec291230
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
v9:
- make mte_update_sctlr_user static
arch/arm64/include/asm/processor.h | 3 ++
arch/arm64/kernel/mte.c | 70 ++++++++++++------------------
include/uapi/linux/prctl.h | 11 ++---
3 files changed, 37 insertions(+), 47 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2021-07-14 11:45:27
On Tue, Jul 13, 2021 at 04:47:59PM -0700, Peter Collingbourne wrote:
quoted hunk
In the next patch, we will start reading sctlr_user from
mte_update_sctlr_user and subsequently writing a new value based on the
task's TCF setting and potentially the per-CPU TCF preference. This
means that we need to be careful to disable preemption around any
code sequences that read from sctlr_user and subsequently write to
sctlr_user and/or SCTLR_EL1, so that we don't end up writing a stale
value (based on the previous CPU's TCF preference) to either of them.
We currently have four such sequences, in the prctl handlers for
PR_SET_TAGGED_ADDR_CTRL and PR_PAC_SET_ENABLED_KEYS, as well as in
the task initialization code that resets the prctl settings. Change
the prctl handlers to disable preemption in the handlers themselves
rather than the functions that they call, and change the task
initialization code to call the respective prctl handlers instead of
setting sctlr_user directly.
As a result of this change, we no longer need the helper function
set_task_sctlr_el1, nor does its behavior make sense any more, so
remove it.
Signed-off-by: Peter Collingbourne <redacted>
Link: https://linux-review.googlesource.com/id/Ic0e8a0c00bb47d786c1e8011df0b7fe99bee4bb5
---
arch/arm64/include/asm/pointer_auth.h | 12 ++++++------
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/kernel/mte.c | 8 ++++----
arch/arm64/kernel/pointer_auth.c | 10 ++++++----
arch/arm64/kernel/process.c | 21 +++++++--------------
5 files changed, 24 insertions(+), 29 deletions(-)
@@ -222,9 +222,7 @@ void mte_thread_init_user(void)write_sysreg_s(0,SYS_TFSRE0_EL1);clear_thread_flag(TIF_MTE_ASYNC_FAULT);/* disable tag checking and reset tag generation mask */-current->thread.mte_ctrl=MTE_CTRL_GCR_USER_EXCL_MASK;-mte_update_sctlr_user(current);-set_task_sctlr_el1(current->thread.sctlr_user);+set_mte_ctrl(current,0);}voidmte_thread_switch(structtask_struct*next)
@@ -281,8 +279,10 @@ long set_mte_ctrl(struct task_struct *task, unsigned long arg)task->thread.mte_ctrl=mte_ctrl;if(task==current){+preempt_disable();mte_update_sctlr_user(task);-set_task_sctlr_el1(task->thread.sctlr_user);+update_sctlr_el1(task->thread.sctlr_user);+preempt_enable();}return0;
@@ -67,7 +67,7 @@ static u64 arg_to_enxx_mask(unsigned long arg)intptrauth_set_enabled_keys(structtask_struct*tsk,unsignedlongkeys,unsignedlongenabled){-u64sctlr=tsk->thread.sctlr_user;+u64sctlr;if(!system_supports_address_auth())return-EINVAL;
@@ -78,12 +78,14 @@ int ptrauth_set_enabled_keys(struct task_struct *tsk, unsigned long keys,if((keys&~PR_PAC_ENABLED_KEYS_MASK)||(enabled&~keys))return-EINVAL;+preempt_disable();+sctlr=tsk->thread.sctlr_user;sctlr&=~arg_to_enxx_mask(keys);sctlr|=arg_to_enxx_mask(enabled);+tsk->thread.sctlr_user=sctlr;if(tsk==current)-set_task_sctlr_el1(sctlr);-else-tsk->thread.sctlr_user=sctlr;+update_sctlr_el1(sctlr);+preempt_enable();
This should work, as long as tsk is stopped if tsk != current, otherwise I
think there are a bunch of existing races between
ptrauth_set_enabled_keys(), set_mte_ctrl() and ptrauth_get_enabled_keys().
That's (probably?) true for the ptrace case, which is the only scenario
where tsk != current afaict.
I can't help but feel we should add _something_ (as a separate patch) to
avoid tripping over this in future. Maybe a WARN_ON(!task_is_stopped(tsk))
if tsk != current? Failing that, we could handle the concurrency by adding a
helper to update sctlr_user, which takes a clear and a set mask and does a
cmpxchg_relaxed() under the hood? That might also eliminate the need for
some of these preempt_disable() sections.
Anyway, that's a pre-existing issue, so for this patch:
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-07-14 11:47:24
On Tue, Jul 13, 2021 at 04:48:00PM -0700, Peter Collingbourne wrote:
Add a per-CPU sysfs node, mte_tcf_preferred, that allows the preferred
tag checking mode to be configured. The current possible values are
async and sync.
Link: https://linux-review.googlesource.com/id/I7493dcd533a2785a1437b16c3f6b50919f840854
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
v10:
- stop calling smp_call_function_single
arch/arm64/kernel/mte.c | 65 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 63 insertions(+), 2 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2021-07-14 11:52:03
On Tue, Jul 13, 2021 at 04:48:01PM -0700, Peter Collingbourne wrote:
quoted hunk
Document the functionality added in the previous patches.
Link: https://linux-review.googlesource.com/id/I48217cc3e8b8da33abc08cbaddc11cf4360a1b86
Signed-off-by: Peter Collingbourne <redacted>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Will Deacon <will@kernel.org>
---
v10:
- document that setting the sysfs node may not take effect
immediately
- unabbreviate month name
v9:
- add documentation for sysfs node under Documentation/ABI
.../ABI/testing/sysfs-devices-system-cpu | 18 +++++++
.../arm64/memory-tagging-extension.rst | 48 ++++++++++++++++---
2 files changed, 59 insertions(+), 7 deletions(-)
@@ -640,3 +640,21 @@ Description: SPURR ticks for cpuX when it was idle. This sysfs interface exposes the number of SPURR ticks for cpuX when it was idle.++What: /sys/devices/system/cpu/cpuX/mte_tcf_preferred+Date: July 2021+Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>+Description: Preferred MTE tag checking mode++ When a user program specifies more than one MTE tag checking+ mode, this sysfs node is used to specify which mode should+ be preferred when running on that CPU. Possible values:
So I suppose we could replace "running" with "scheduling a task" and then
remove:
+ Changes to this sysfs node may not take effect immediately.
altogether, as it makes it sounds as though the change might just be
ignored.
But I don't want to bikeshed this, so:
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Peter,
On Tue, Jul 13, 2021 at 04:47:56PM -0700, Peter Collingbourne wrote:
Peter Collingbourne (5):
arm64: mte: rename gcr_user_excl to mte_ctrl
arm64: mte: change ASYNC and SYNC TCF settings into bitfields
arm64: move preemption disablement to prctl handlers
arm64: mte: introduce a per-CPU tag checking mode preference
Documentation: document the preferred tag checking mode feature
Could you please rebase these patches on top of arm64 for-next/mte
(based on 5.14-rc3)? They don't apply cleanly. You may want to update
the other GCR_EL1 and double ISB patches as well in case there's a
specific order in which they need to be applied.
Thanks.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Peter Collingbourne <hidden> Date: 2021-07-27 20:57:46
On Tue, Jul 27, 2021 at 11:20 AM Catalin Marinas
[off-list ref] wrote:
Hi Peter,
On Tue, Jul 13, 2021 at 04:47:56PM -0700, Peter Collingbourne wrote:
quoted
Peter Collingbourne (5):
arm64: mte: rename gcr_user_excl to mte_ctrl
arm64: mte: change ASYNC and SYNC TCF settings into bitfields
arm64: move preemption disablement to prctl handlers
arm64: mte: introduce a per-CPU tag checking mode preference
Documentation: document the preferred tag checking mode feature
Could you please rebase these patches on top of arm64 for-next/mte
(based on 5.14-rc3)? They don't apply cleanly. You may want to update
the other GCR_EL1 and double ISB patches as well in case there's a
specific order in which they need to be applied.
Okay, I rebased this series and the double ISB patch to 5.14-rc3 (the
GCR_EL1 patch didn't need to be rebased). I also double checked that
there aren't any conflicts with the TFSR patch that you've already
taken. The GCR_EL1 patch needs to be applied after this series, and
the double ISB patch doesn't need to be applied in any particular
order.
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel