Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: linux-kselftest@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, shuah@kernel.org,
	broonie@kernel.org, usama.anjum@arm.com, mark.rutland@arm.com,
	will@kernel.org, catalin.marinas@arm.com
Subject: [PATCH 0/2] kselftest: Make MTE memory access robust
Date: Tue, 22 Sep 2026 11:59:57 +0100	[thread overview]
Message-ID: <20260922105959.129380-1-vladimir.murzin@arm.com> (raw)

Currently MTE selftests assume that they can skip (expected) MTE
faults by advancing the PC by 4 in mte_default_handler(), but this is
not generally safe, as the faults are triggered from arbitrary library
functions (e.g. memset() and memcpy()). For instance, memset() could
be implemented as simple as:

      mov   x3, x0       // copy pointer
      add   x4, x0, x2   // calculate end
    loop:
      strb  w1, [x3], #1 // faulting access
      cmp   x3, x4
      b.ne  loop
      ret

which leads to an infinite loop since X3 could not be updated.

Or, it could be having advanced implementation (FEAT_MOPS):

      mov   x3, x0         // copy pointer
      setp  [x3]!, x2!, x1 // prologue
      setm  [x3]!, x2!, x1 // main
      sete  [x3]!, x2!, x1 // epilogue
      ret

with faulting access at prologue advancing PC to main could lead to
infinite loop due to main could be triggering unaligned access fault
which kernel fixing up by advancing PC back to prologue.

Address this by introducing memory access helpers with predictable
behavior, allowing faults to be safely handled, and switch the MTE
selftests over to them.

Vladimir Murzin (2):
  kselftest/arm64/mte: Introduce MTE safe memory accessors
  kselftest/arm64/mte: Use MTE safe memory accessors

 .../selftests/arm64/mte/check_buffer_fill.c   | 10 ++---
 .../selftests/arm64/mte/check_child_memory.c  |  6 +--
 .../arm64/mte/check_hugetlb_options.c         |  4 +-
 .../selftests/arm64/mte/check_mmap_options.c  | 10 ++---
 .../arm64/mte/check_tags_inclusion.c          |  4 +-
 .../selftests/arm64/mte/mte_common_util.h     |  4 ++
 .../testing/selftests/arm64/mte/mte_helper.S  | 44 +++++++++++++++++++
 7 files changed, 65 insertions(+), 17 deletions(-)

-- 
2.34.1



             reply	other threads:[~2026-09-22 11:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 10:59 Vladimir Murzin [this message]
2026-09-22 10:59 ` [PATCH 1/2] kselftest/arm64/mte: Introduce MTE safe memory accessors Vladimir Murzin
2026-09-22 10:59 ` [PATCH 2/2] kselftest/arm64/mte: Use " Vladimir Murzin
2026-09-22 17:10 ` [PATCH 0/2] kselftest: Make MTE memory access robust Muhammad Usama Anjum
2026-10-06 22:56 ` Catalin Marinas

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=20260922105959.129380-1-vladimir.murzin@arm.com \
    --to=vladimir.murzin@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=shuah@kernel.org \
    --cc=usama.anjum@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox