From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: David Hildenbrand <david@redhat.com>,
Yeoreum Yun <yeoreum.yun@arm.com>,
will@kernel.org, broonie@kernel.org, anshuman.khandual@arm.com,
joey.gouly@arm.com, maz@kernel.org, oliver.upton@linux.dev,
frederic@kernel.org, james.morse@arm.com,
hardevsinh.palaniya@siliconsignals.io,
shameerali.kolothum.thodi@huawei.com, huangxiaojia2@huawei.com,
mark.rutland@arm.com, samuel.holland@sifive.com,
palmer@rivosinc.com, charlie@rivosinc.com,
thiago.bauermann@linaro.org, bgray@linux.ibm.com,
tglx@linutronix.de, puranjay@kernel.org,
yang@os.amperecomputing.com, mbenes@suse.cz,
joel.granados@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, nd@arm.com
Subject: Re: [PATCH v3 2/4] prtcl: introduce PR_MTE_STORE_ONLY
Date: Fri, 2 May 2025 21:19:11 +0100 [thread overview]
Message-ID: <aBUovySaQN8m8L0w@arm.com> (raw)
In-Reply-To: <CAMn1gO7ai3EvHhepJJQXOvjc8_Mp6DEAZg0J1gMKSJTECnU0VA@mail.gmail.com>
On Fri, May 02, 2025 at 11:03:02AM -0700, Peter Collingbourne wrote:
> On Fri, May 2, 2025 at 10:37 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Thu, Apr 24, 2025 at 10:34:57PM +0200, David Hildenbrand wrote:
> > > On 10.04.25 10:07, Yeoreum Yun wrote:
> > > > PR_MTE_STORE_ONLY is used to restrict the MTE tag check for store
> > > > opeartion only.
> > > >
> > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > ---
> > > > include/uapi/linux/prctl.h | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
> > > > index 15c18ef4eb11..83ac566251d8 100644
> > > > --- a/include/uapi/linux/prctl.h
> > > > +++ b/include/uapi/linux/prctl.h
> > > > @@ -244,6 +244,8 @@ struct prctl_mm_map {
> > > > # define PR_MTE_TAG_MASK (0xffffUL << PR_MTE_TAG_SHIFT)
> > > > /* Unused; kept only for source compatibility */
> > > > # define PR_MTE_TCF_SHIFT 1
> > > > +/* MTE tag check store only */
> > > > +# define PR_MTE_STORE_ONLY (1UL << 19)
> > >
> > > That is the next available bit after PR_MTE_TAG_MASK, correct?
> > >
> > > Would we want to leave some space to grow PR_MTE_TAG_MASK in the future
> > > (could that happen?)?
> >
> > The current mask covers 16 tags (bits 59:56 of a pointer) and given the
> > reluctance to have a tag storage of 4 bits per 16 bytes (3% of RAM), I
> > doubt we'd ever grow this.
> >
> > However, you have a good point, we could indeed leave 32 bits for the
> > tag mask, just in case MTE gets so much traction that someone wants 8
> > bits per tag (and likely a bigger granule than 16 bytes). It doesn't
> > cost us anything to add additional bits from (PR_MTE_TAG_SHIFT + 32).
>
> If it's 8 bits per tag wouldn't the exclusion mask need to be 256
> bits? I probably wouldn't try to anticipate this case since it would
> likely require a different API anyway.
Yep, not sure what I was thinking. So all good with the original patch.
--
Catalin
next prev parent reply other threads:[~2025-05-02 20:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 8:07 [PATCH v3 0/4] support FEAT_MTE_STORE_ONLY feature Yeoreum Yun
2025-04-10 8:07 ` [PATCH v3 1/4] arm64/feature: add MTE_STORE_ONLY feature Yeoreum Yun
2025-05-02 17:24 ` Catalin Marinas
2025-05-07 10:48 ` Yeoreum Yun
2025-04-10 8:07 ` [PATCH v3 2/4] prtcl: introduce PR_MTE_STORE_ONLY Yeoreum Yun
2025-04-24 20:34 ` David Hildenbrand
2025-04-28 15:46 ` Yeo Reum Yun
2025-05-02 17:37 ` Catalin Marinas
2025-05-02 18:03 ` Peter Collingbourne
2025-05-02 20:19 ` Catalin Marinas [this message]
2025-04-10 8:07 ` [PATCH v3 3/4] arm64/kernel: support store-only mte tag check Yeoreum Yun
2025-05-02 17:50 ` Catalin Marinas
2025-05-07 10:47 ` Yeoreum Yun
2025-04-10 8:07 ` [PATCH v3 4/4] tools/kselftest: add MTE_STORE_ONLY feature hwcap test Yeoreum Yun
2025-05-02 17:51 ` Catalin Marinas
2025-05-07 10:49 ` Yeoreum Yun
2025-04-24 13:50 ` [PATCH v3 0/4] support FEAT_MTE_STORE_ONLY feature Yeoreum Yun
2025-04-24 20:29 ` David Hildenbrand
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=aBUovySaQN8m8L0w@arm.com \
--to=catalin.marinas@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=bgray@linux.ibm.com \
--cc=broonie@kernel.org \
--cc=charlie@rivosinc.com \
--cc=david@redhat.com \
--cc=frederic@kernel.org \
--cc=hardevsinh.palaniya@siliconsignals.io \
--cc=huangxiaojia2@huawei.com \
--cc=james.morse@arm.com \
--cc=joel.granados@kernel.org \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mbenes@suse.cz \
--cc=nd@arm.com \
--cc=oliver.upton@linux.dev \
--cc=palmer@rivosinc.com \
--cc=pcc@google.com \
--cc=puranjay@kernel.org \
--cc=samuel.holland@sifive.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tglx@linutronix.de \
--cc=thiago.bauermann@linaro.org \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=yeoreum.yun@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.