Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Xueyuan Chen <xueyuan.chen21@gmail.com>, akpm@linux-foundation.org
Cc: david@kernel.org, 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:18:01 -0700	[thread overview]
Message-ID: <2931f8a6-3780-4d6a-b19d-61cbbdad1a3a@intel.com> (raw)
In-Reply-To: <20260730090647.2401252-4-xueyuan.chen21@gmail.com>

On 7/30/26 02:06, Xueyuan Chen wrote:
> +int set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages)
> +{
> +	unsigned long tempaddr = (unsigned long)addr;
> +	struct cpa_data cpa = {
> +		.vaddr = &tempaddr,
> +		.pgd = NULL,
> +		.numpages = nr_pages,
> +		.mask_set = __pgprot(0),
> +		.mask_clr = __pgprot(_PAGE_RW | _PAGE_DIRTY),
> +		.flags = CPA_NO_CHECK_ALIAS,
> +	};
> +
> +	return __change_page_attr_set_clr(&cpa, 1);
> +}

A couple of concerns here.

First, why the "_noflush"? Sure, the "this is a best effort hardening"
function argument can be made, so it doesn't need to be correct. But the
result is a function that's called once and also has some sharp corners
and relatively high potential for misuse. Let's just do the flush.

Second, I see that the other set_direct_map*() callers use
CPA_NO_CHECK_ALIAS. The reasoning behind it dates back to 2008 and I'm
not 100% sure what it is referring to. On one hand, it would be nice to
have all the set_direct_map*() callers be consistent. On the other hand,
there shouldn't *be* any aliases of a 2M page that came out of the page
allocator. We almost want a CPA_ASSERT_NO_ALIASES that goes out and
checks for aliases more than we want to ignore them. (Note: I don't
expect you to fix this, but a simple comment saying that no aliases are
expected would be nice)

Third, what's with the 'tempaddr'? Are you working around the 'const'?
Honestly, I'd rather have no const than have it and subvert it with
casting trickery.

Last:

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?

Imagine the fun if someone did:

	set_direct_map_ro_noflush(page, 1);
and
	set_direct_map_default_noflush(page)




  parent reply	other threads:[~2026-08-25 16:18 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 [this message]
2026-08-25 16:43     ` David Hildenbrand (Arm)
2026-08-25 16:57       ` Dave Hansen
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=2931f8a6-3780-4d6a-b19d-61cbbdad1a3a@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