From: Dave Hansen <dave.hansen@intel.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
Xueyuan Chen <xueyuan.chen21@gmail.com>,
akpm@linux-foundation.org
Cc: ljs@kernel.org, usama.arif@linux.dev, catalin.marinas@arm.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
rppt@kernel.org, ryan.roberts@arm.com, ziy@nvidia.com,
baohua@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Lance Yang <lance.yang@linux.dev>
Subject: Re: [PATCH v6 3/3] x86/mm: add set_direct_map_ro_noflush()
Date: Tue, 25 Aug 2026 09:57:01 -0700 [thread overview]
Message-ID: <687afc72-5b6a-4138-8d33-fe5b6b7aef00@intel.com> (raw)
In-Reply-To: <1e04196a-7079-4a8d-a1b7-844e60d08728@kernel.org>
On 8/25/26 09:43, David Hildenbrand (Arm) wrote:
>> int set_direct_map_invalid_noflush(struct page *page)
>> int set_direct_map_default_noflush(struct page *page)
>> int set_direct_map_valid_noflush(struct page *page, unsigned nr, ...
>> int set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages)
>>
>> Which one of these things is not like the other, despite being named
>> just like them?
>>
> That's called out in the cover letter:
>
> "
> This series adds set_direct_map_ro_noflush() so mm code can make a
> direct-map range read-only, then uses it for the persistent huge zero
> folio. The helper is direct-map specific, takes an address-based range as
> discussed for set_direct_map* helpers[2], and leaves TLB invalidation to
> the caller.
> "
My concern is not so much what the function is doing or whether or how
the specific function is documented. It's more about whether the new
function is consistent across all functions with a similar purpose and
name. Also, if it is _not_ consistent there needs to be reasoning behind
the inconsistency. I think that is missing here.
In this case, look at the call site:
addr = (unsigned long)folio_address(huge_zero_folio);
set_direct_map_ro_noflush((void *)addr, HPAGE_PMD_NR);
It *has* a folio. But it does a folio_address() and two casts to massage
it into the type for set_direct_map_ro_noflush().
If set_direct_map_ro_noflush() just took a 'struct page *', there would
be one folio=>page conversion, no casting, and complete consistency with
the other set_direct_map*() functions.
I'd also be OK with set_direct_map_ro_noflush() taking a folio, with the
implication being that it might eventually make sense to convert the
other set_direct_map*() functions to folios. But page vs. folio
confusion is much less likely to cause bugs than a void* versus another
pointer.
IOW, what I think I want is:
int set_direct_map_ro_noflush(struct page *page, unsigned long nr_pages)
Or _maybe_:
int set_direct_map_ro_noflush(struct folio *folio)
next prev parent reply other threads:[~2026-08-25 16:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 9:06 [PATCH v6 0/3] mm: make persistent huge zero folio read-only Xueyuan Chen
2026-07-30 9:06 ` [PATCH v6 1/3] " Xueyuan Chen
2026-08-25 15:51 ` David Hildenbrand (Arm)
2026-08-25 16:29 ` Dave Hansen
2026-07-30 9:06 ` [PATCH v6 2/3] arm64/mm: add set_direct_map_ro_noflush() Xueyuan Chen
2026-08-25 15:52 ` David Hildenbrand (Arm)
2026-08-25 16:44 ` Will Deacon
2026-08-25 16:46 ` David Hildenbrand (Arm)
2026-08-26 7:53 ` Xueyuan Chen
2026-07-30 9:06 ` [PATCH v6 3/3] x86/mm: " Xueyuan Chen
2026-08-25 15:52 ` David Hildenbrand (Arm)
2026-08-25 16:18 ` Dave Hansen
2026-08-25 16:43 ` David Hildenbrand (Arm)
2026-08-25 16:57 ` Dave Hansen [this message]
2026-08-25 17:30 ` David Hildenbrand (Arm)
2026-08-26 12:19 ` Xueyuan Chen
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=687afc72-5b6a-4138-8d33-fe5b6b7aef00@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=lance.yang@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=tglx@kernel.org \
--cc=usama.arif@linux.dev \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xueyuan.chen21@gmail.com \
--cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox