All of lore.kernel.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Peter Collingbourne <pcc@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Tejas Belagod <Tejas.Belagod@arm.com>
Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis
Date: Tue, 29 Jun 2021 14:58:32 +0100	[thread overview]
Message-ID: <20210629135831.GC14854@arm.com> (raw)
In-Reply-To: <20210629104625.GA7168@willie-the-truck>

The 06/29/2021 11:46, Will Deacon wrote:
> On Mon, Jun 28, 2021 at 04:20:24PM +0100, Catalin Marinas wrote:
> > Another option is a mapping table where async can be remapped to sync
> > and sync to async (or even to "none" for both). That's not far from one
> > of Peter's mte-upgrade-async proposal, we just add mte-map-async and
> > mte-map-sync options. Most likely we'll just use mte-map-async for now
> > to map it to sync on some CPUs but it wouldn't exclude other forced
> > settings.
> 
> Catalin and I discussed this offline and ended up with another option:
> retrospectively change the prctl() ABI so that the 'flags' argument
> accepts a bitmask of modes that the application is willing to accept. This
> doesn't break any existing users, as we currently enforce that only one
> mode is specified, but it would allow things like:
> 
> 	prctl(PR_SET_TAGGED_ADDR_CTRL,
> 	      PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC,
> 	      0, 0, 0);
> 
> which is actually very similar to Peter's PR_MTE_DYNAMIC_TCF proposal, with
> the difference that I think this extends more naturally as new PR_MTR_TCF_*
> flags are introduced.
> 
> Then we expose a per-cpu file in sysfs (say "cpuX/mte_tcf_preferred")
> which initially reads as "async". If the root user does, e.g.
> 
> 	# echo "sync" > cpu1/mte_tcf_preferred
> 
> then a task which has successfully issued a PR_SET_TAGGED_ADDR_CTRL prctl()
> request for PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC will run in sync mode on
> CPU1, but async mode on other CPUs (assuming they retain the default value).
> 
> We'll need to special-case PR_MTE_TCF_NONE, as that's just a shorthand for
> "no flags" so doing PR_MTE_TCF_NONE | PR_MTE_TCF_SYNC is just the same as
> doing PR_MTE_TCF_SYNC (which I think is already the behaviour today). The
> only values which the sysfs files would accept today are "sync" and "async".
> 
> When faced with a situation where the prctl() flags for a task do not
> intersect with the preferred mode for a CPU on which the task is going
> to run, the lowest bit number flag is chosen from the mask set by the
> prctl().
> 
> Thoughts?

i'm happy with this.

"lowest bit number" flag may not be optimal if there
are many flags, but i don't expect many more tag check
modes.

no separate TCF_NONE bit means if we later want to
turn tag check off per cpu there is no opt-out.
but i guess this is fine.

will armv8.7-a style asymmetric check use separate
flag or TCF_SYNC | TCF_ASYNC may enable it?
i see arguments either way.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-29 14:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15 20:38 [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis Peter Collingbourne
2021-06-17 21:58 ` Will Deacon
2021-06-17 22:13   ` Peter Collingbourne
2021-06-18 15:09   ` Catalin Marinas
2021-06-19  0:45     ` Peter Collingbourne
2021-06-21 12:39     ` Will Deacon
2021-06-21 15:18       ` Catalin Marinas
2021-06-21 17:39         ` Will Deacon
2021-06-21 18:50           ` Catalin Marinas
2021-06-22 18:37             ` Peter Collingbourne
2021-06-23  8:55               ` Szabolcs Nagy
2021-06-23 17:15                 ` Peter Collingbourne
2021-06-24 16:52                 ` Catalin Marinas
2021-06-25  9:22                   ` Szabolcs Nagy
2021-06-25 12:01                     ` Catalin Marinas
2021-06-25 12:39                       ` Will Deacon
2021-06-25 13:53                         ` Catalin Marinas
2021-06-28 10:14                           ` Will Deacon
2021-06-28 15:20                             ` Catalin Marinas
2021-06-29 10:46                               ` Will Deacon
2021-06-29 13:58                                 ` Szabolcs Nagy [this message]
2021-06-29 14:31                                   ` Tejas Belagod
2021-06-29 15:54                                     ` Catalin Marinas
2021-06-29 19:11                                 ` Peter Collingbourne
2021-06-30 15:19                                   ` Catalin Marinas
2021-06-30 23:39                                     ` Peter Collingbourne
2021-07-07 10:30                                       ` Will Deacon
2021-07-07 12:55                                         ` Catalin Marinas
2021-07-07 14:11                                           ` Will Deacon
2021-06-25 14:14                         ` Szabolcs Nagy
2021-06-25 16:21                           ` Tejas Belagod
2021-06-28 10:17                           ` Will Deacon
2021-06-28 17:21                             ` Szabolcs Nagy
2021-06-25 16:52                       ` Peter Collingbourne

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=20210629135831.GC14854@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=Tejas.Belagod@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=eugenis@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=pcc@google.com \
    --cc=vincenzo.frascino@arm.com \
    --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.