From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Yang Shi <yang@os.amperecomputing.com>,
Christoph Lameter <cl@gentwo.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 2/2] arm64/mm: Reject memory removal that splits a kernel leaf mapping
Date: Wed, 4 Mar 2026 09:59:48 +0100 [thread overview]
Message-ID: <71f1f82b-0768-400e-b63b-cc872345338f@kernel.org> (raw)
In-Reply-To: <e73c1597-9a98-402c-9665-e67c1270cde7@arm.com>
On 3/4/26 09:53, Anshuman Khandual wrote:
>
>
> On 03/03/26 2:30 PM, David Hildenbrand (Arm) wrote:
>>>
>>> Probably nothing is broken now I guess but the original memory hot remove
>>> patch should have taken care of this scenario. Although don't have strong
>>> opinions either way. We could drop both "Fixes" and "Closes" tags here if
>>> that is preferred.
>>>
>>
>> We tend to only tag actual fixes. If we consider this a possible fix, we
>> should ask ourselves whether this would be stable material.
>
> Ryan had earlier asked for the Cc: stable to be dropped
> as this was not an actual fix. But seems like we should
> drop these Fixes/Closes tags as well.
If there are no know problems (no bugs), then I would just use
Link: instead of Closes:
And the Suggested-by:.
>
>>
>> ...
>>
>>>
>>> We might not in reality but in order to be sure just an additional protection.
>>
>> I'm rather wondering if this would indicate a real bug somewhere else
>> that we would silently swallow.
>>
>> Anyhow, no real preference from my side, just something I considered weird.
>>
>> [...]
>>
>>
>> Just to clarify:
>>
>> What I meant here is: with CONFIG_SPARSEMEM but without
>> CONFIG_SPARSEMEM_VMEMMAP.
>
> Alright but does the commit message or pfn_to_page() code
> block here needs a comment about this ? OR it is apparent
> enough ?
You could add a
BUILD_BUG_ON(!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP));
to check and document in a single statement.
--
Cheers,
David
next prev parent reply other threads:[~2026-03-04 9:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 6:24 [PATCH V3 0/2] arm64/mm: Enable batched TLB flush in unmap_hotplug_range() Anshuman Khandual
2026-02-24 6:24 ` [PATCH V3 1/2] " Anshuman Khandual
2026-03-02 15:28 ` David Hildenbrand (Arm)
2026-03-03 5:55 ` Anshuman Khandual
2026-02-24 6:24 ` [PATCH V3 2/2] arm64/mm: Reject memory removal that splits a kernel leaf mapping Anshuman Khandual
2026-03-02 15:51 ` David Hildenbrand (Arm)
2026-03-03 4:01 ` Anshuman Khandual
2026-03-03 9:00 ` David Hildenbrand (Arm)
2026-03-04 8:53 ` Anshuman Khandual
2026-03-04 8:59 ` David Hildenbrand (Arm) [this message]
2026-03-02 7:34 ` [PATCH V3 0/2] arm64/mm: Enable batched TLB flush in unmap_hotplug_range() Anshuman Khandual
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=71f1f82b-0768-400e-b63b-cc872345338f@kernel.org \
--to=david@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@arm.com \
--cc=will@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.