From: Yang Shi <yang@os.amperecomputing.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: LAK <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Question] mprotect() can't clear PROT_MTE
Date: Mon, 3 Nov 2025 10:22:12 -0800 [thread overview]
Message-ID: <3fe7e501-b319-4b9b-b129-dce5e945bf9a@os.amperecomputing.com> (raw)
In-Reply-To: <aQUEk6a_3OWapRbE@arm.com>
On 10/31/25 11:48 AM, Catalin Marinas wrote:
> Hi Yang,
>
> On Wed, Oct 29, 2025 at 03:41:17PM -0700, Yang Shi wrote:
>> Our customers have usecase to untag memory w/o unmapping it, but mprotect
>> can't do it. It seems like an intended behavior because I saw MTE doc
>> explicitly says PROT_MTE flags can't be cleared by mprotect().
>> But I don't see why mprotect() can't do it if I don't miss anything. So I'd
>> like to know why it behaves in this way.
> It would be interesting to know more about the use-case. At the time,
> clearing PROT_MTE got in the way. The theory was that an allocator
> controls the tags and the PROT_MTE property but if that range is used by
> something like a JIT, toggling between PROT_WRITE and PROT_EXEC would
> inadvertently clear PROT_MTE. I'm not sure whether this would happen in
> practice though but it's ABI already, so we can't change it.
I'm not quite sure about their usecase yet.
Yeah, understand. It has been an established behavior.
>
> I'm happy to add support for this if there's a concrete use-case but it
> will need to be gated by a prctl() flag to keep the current ABI. A
> weirder approach would be to add a PROT_MTE_CLEAR flag (I think I prefer
> the prctl).
I agree we should not change the current ABI, some applications may
already rely on it. prctl sounds fine to me. Anyway we can discuss more
about how to implement it once we have more solid usecase.
Thanks for educating me about the context.
Yang
>
prev parent reply other threads:[~2025-11-03 18:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 22:41 Yang Shi
2025-10-31 18:48 ` Catalin Marinas
2025-11-03 18:22 ` Yang Shi [this message]
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=3fe7e501-b319-4b9b-b129-dce5e945bf9a@os.amperecomputing.com \
--to=yang@os.amperecomputing.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®