All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Yang Shi <yang@os.amperecomputing.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: Fri, 31 Oct 2025 18:48:51 +0000	[thread overview]
Message-ID: <aQUEk6a_3OWapRbE@arm.com> (raw)
In-Reply-To: <04ea9978-e6aa-4498-b899-76d56e19b084@os.amperecomputing.com>

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 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).

-- 
Catalin


  reply	other threads:[~2025-10-31 18:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 22:41 [Question] mprotect() can't clear PROT_MTE Yang Shi
2025-10-31 18:48 ` Catalin Marinas [this message]
2025-11-03 18:22   ` Yang Shi

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=aQUEk6a_3OWapRbE@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yang@os.amperecomputing.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.