From: Catalin Marinas <catalin.marinas@arm.com>
To: Reda CHERKAOUI <redacherkaoui67@gmail.com>
Cc: will@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] arm64/mm: harden ASID allocator against empty bitmap after rollover
Date: Tue, 10 Mar 2026 17:24:42 +0000 [thread overview]
Message-ID: <abBT2gV84-9uaHkJ@arm.com> (raw)
In-Reply-To: <20260219113715.8001-1-redacherkaoui67@gmail.com>
On Thu, Feb 19, 2026 at 11:37:14AM +0000, Reda CHERKAOUI wrote:
> new_context() assumes that after incrementing asid_generation and calling
> flush_context(), find_next_zero_bit() will always find a free ASID.
>
> If that invariant is ever violated, __set_bit(NUM_USER_ASIDS, asid_map)
> would write past the end of the bitmap. Add a defensive check so the
> kernel fails loudly instead of silently corrupting memory.
> Cc: stable@vger.kernel.org
>
> Signed-off-by: Reda CHERKAOUI <redacherkaoui67@gmail.com>
> ---
> arch/arm64/mm/context.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> index b2ac06246327..74c1ece7db78 100644
> --- a/arch/arm64/mm/context.c
> +++ b/arch/arm64/mm/context.c
> @@ -160,6 +160,7 @@ static u64 new_context(struct mm_struct *mm)
> static u32 cur_idx = 1;
> u64 asid = atomic64_read(&mm->context.id);
> u64 generation = atomic64_read(&asid_generation);
> + unsigned long idx;
>
> if (asid != 0) {
> u64 newasid = asid2ctxid(ctxid2asid(asid), generation);
> @@ -194,9 +195,11 @@ static u64 new_context(struct mm_struct *mm)
> * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
> * pairs.
> */
> - asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, cur_idx);
> - if (asid != NUM_USER_ASIDS)
> + idx = find_next_zero_bit(asid_map, NUM_USER_ASIDS, cur_idx);
> + if (idx != NUM_USER_ASIDS) {
> + asid = idx;
> goto set_asid;
> + }
>
> /* We're out of ASIDs, so increment the global generation count */
> generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION,
> @@ -204,7 +207,10 @@ static u64 new_context(struct mm_struct *mm)
> flush_context();
>
> /* We have more ASIDs than CPUs, so this will always succeed */
> - asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, 1);
> + idx = find_next_zero_bit(asid_map, NUM_USER_ASIDS, 1);
> + if (unlikely(idx == NUM_USER_ASIDS))
> + panic("ASID allocator: no free ASIDs after rollover\n");
> + asid = idx;
How do you even hit this? Is it if you have less ASIDs than the number
of CPUs? The kernel complains about this in asids_update_limit.
Anyway, given how you are not following up on maintainer's comments, I
assume these patches are automatically generated.
--
Catalin
prev parent reply other threads:[~2026-03-10 17:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 11:37 [PATCH] arm64/mm: harden ASID allocator against empty bitmap after rollover Reda CHERKAOUI
2026-03-10 17:24 ` Catalin Marinas [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=abBT2gV84-9uaHkJ@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=redacherkaoui67@gmail.com \
--cc=stable@vger.kernel.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