From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
Aishwarya.TCV@arm.com
Subject: Re: [PATCH] mm/huge_memory: Initialise the tags of the huge zero folio
Date: Mon, 3 Nov 2025 13:32:42 +0000 [thread overview]
Message-ID: <aQiu-hU3x5V5drHF@finisterre.sirena.org.uk> (raw)
In-Reply-To: <20251031170133.280742-1-catalin.marinas@arm.com>
[-- Attachment #1: Type: text/plain, Size: 4883 bytes --]
On Fri, Oct 31, 2025 at 04:57:50PM +0000, Catalin Marinas wrote:
> On arm64 with MTE enabled, a page mapped as Normal Tagged (PROT_MTE) in
> user space will need to have its allocation tags initialised. This is
> normally done in the arm64 set_pte_at() after checking the memory
> attributes. Such page is also marked with the PG_mte_tagged flag to
> avoid subsequent clearing. Since this relies on having a struct page,
> pte_special() mappings are ignored.
We are seeing breakage in userspace on a range of arm64 platforms which
bisects to this commit in -next. We see traces like:
[ 59.746701] Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
...
[ 59.819007] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 59.826055] pc : mte_zero_clear_page_tags+0x1c/0x40
[ 59.830980] lr : tag_clear_highpage+0x68/0x118
...
[ 59.911874] Call trace:
[ 59.914333] mte_zero_clear_page_tags+0x1c/0x40 (P)
[ 59.919278] get_page_from_freelist+0x1a60/0x1c80
[ 59.924042] __alloc_frozen_pages_noprof+0x178/0xd20
[ 59.929068] alloc_pages_mpol+0xb4/0x1a4
[ 59.933022] alloc_frozen_pages_noprof+0x48/0xc0
[ 59.937683] folio_alloc_noprof+0x14/0x68
[ 59.941718] mm_get_huge_zero_folio+0xf4/0x30c
[ 59.946200] do_huge_pmd_anonymous_page+0x278/0x6a0
[ 59.951119] __handle_mm_fault+0x700/0x1834
[ 59.955332] handle_mm_fault+0x8c/0x2a0
[ 59.959190] do_page_fault+0x108/0x75c
[ 59.962964] do_translation_fault+0x5c/0x6c
[ 59.967181] do_mem_abort+0x40/0x90
Looking at the codes:
> - zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO) & ~__GFP_MOVABLE,
> + zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO | __GFP_ZEROTAGS) &
> + ~__GFP_MOVABLE,
> HPAGE_PMD_ORDER);
This adds an unonditional __GFP_ZEROTAGS - from a quick scan it looks
like this was previously only enabled by vma_alloc_zeroed_movable_folio()
when the VMA has VM_MTE, I think we need a similar test here.
Full log:
https://lava.sirena.org.uk/scheduler/job/2036941#L1423
Sample bisect log (with links to further runtime logs:
# bad: [3575af345aa2424636e69ac101a568bda249abe6] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
# good: [6146a0f1dfae5d37442a9ddcba012add260bceb0] Linux 6.18-rc4
git bisect start '3575af345aa2424636e69ac101a568bda249abe6' '6146a0f1dfae5d37442a9ddcba012add260bceb0'
# test job: [3575af345aa2424636e69ac101a568bda249abe6] https://lava.sirena.org.uk/scheduler/job/2036941
# bad: [3575af345aa2424636e69ac101a568bda249abe6] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
git bisect bad 3575af345aa2424636e69ac101a568bda249abe6
# test job: [81f07f151b0759666fee3184651aab90ef1c5ed5] https://lava.sirena.org.uk/scheduler/job/2037418
# bad: [81f07f151b0759666fee3184651aab90ef1c5ed5] Merge branch 'usb-linus' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
git bisect bad 81f07f151b0759666fee3184651aab90ef1c5ed5
# test job: [661821dc41b20c505d5adad10bb71fe5746c57fb] https://lava.sirena.org.uk/scheduler/job/2037588
# bad: [661821dc41b20c505d5adad10bb71fe5746c57fb] Merge branch 'fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git
git bisect bad 661821dc41b20c505d5adad10bb71fe5746c57fb
# test job: [972cbfc499182c200bd3d2fb8fe4173df0d4d3e7] https://lava.sirena.org.uk/scheduler/job/2037773
# bad: [972cbfc499182c200bd3d2fb8fe4173df0d4d3e7] mm/huge_memory: initialise the tags of the huge zero folio
git bisect bad 972cbfc499182c200bd3d2fb8fe4173df0d4d3e7
# test job: [6923ff319e1b0d3541cd240b6ed494e1cb6287d1] https://lava.sirena.org.uk/scheduler/job/2037885
# good: [6923ff319e1b0d3541cd240b6ed494e1cb6287d1] fs/proc: fix uaf in proc_readdir_de()
git bisect good 6923ff319e1b0d3541cd240b6ed494e1cb6287d1
# test job: [e356021a7589f6dd1c946b86c933462dca0bc1ec] https://lava.sirena.org.uk/scheduler/job/2037973
# good: [e356021a7589f6dd1c946b86c933462dca0bc1ec] codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
git bisect good e356021a7589f6dd1c946b86c933462dca0bc1ec
# test job: [decb83d6239894a14b07c8f5ebf9feb5c87ec651] https://lava.sirena.org.uk/scheduler/job/2038008
# good: [decb83d6239894a14b07c8f5ebf9feb5c87ec651] mm/damon/sysfs: change next_update_jiffies to a global variable
git bisect good decb83d6239894a14b07c8f5ebf9feb5c87ec651
# test job: [53cf2716958490997b8ce11cc4665256905b23dd] https://lava.sirena.org.uk/scheduler/job/2038076
# good: [53cf2716958490997b8ce11cc4665256905b23dd] nilfs2: avoid having an active sc_timer before freeing sci
git bisect good 53cf2716958490997b8ce11cc4665256905b23dd
# first bad commit: [972cbfc499182c200bd3d2fb8fe4173df0d4d3e7] mm/huge_memory: initialise the tags of the huge zero folio
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-11-03 13:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 16:57 Catalin Marinas
2025-10-31 17:15 ` David Hildenbrand
2025-11-03 13:32 ` Mark Brown [this message]
2025-11-03 14:30 ` Catalin Marinas
2025-11-03 14:41 ` David Hildenbrand (Red Hat)
2025-11-03 15:59 ` Catalin Marinas
2025-11-03 19:29 ` Beleswar Prasad Padhi
2025-11-04 1:05 ` Andrew Morton
2025-11-04 8:52 ` Catalin Marinas
2025-11-04 11:53 ` [PATCH] mm/huge_memory: Initialise the tags of the huge zero Lance Yang
2025-11-08 19:19 ` [PATCH] mm/huge_memory: initialise the tags of the huge zero folio Jan Polensky
2025-11-09 0:42 ` [PATCH] Clarification: please ignore earlier submission Jan Polensky
2025-11-09 0:36 ` [PATCH] mm/huge_memory: restrict __GFP_ZEROTAGS to HW tagging architectures Jan Polensky
2025-11-10 9:09 ` David Hildenbrand (Red Hat)
2025-11-10 9:48 ` Jan Polensky
2025-11-10 9:53 ` David Hildenbrand (Red Hat)
2025-11-10 15:28 ` Catalin Marinas
2025-11-10 15:55 ` Catalin Marinas
2025-11-22 12:04 ` Balbir Singh
2025-11-24 10:57 ` David Hildenbrand (Red Hat)
2025-11-24 18:08 ` Andrew Morton
2025-11-11 10:44 ` Jan Polensky
2025-11-11 12:27 ` David Hildenbrand (Red Hat)
2025-11-11 12:28 ` David Hildenbrand (Red Hat)
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=aQiu-hU3x5V5drHF@finisterre.sirena.org.uk \
--to=broonie@kernel.org \
--cc=Aishwarya.TCV@arm.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--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