All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Max Boone <mboone@akamai.com>, Andrew Morton <akpm@linux-foundation.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Alex Williamson <alex@shazbot.org>,
	linux-mm@kvack.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Max Tottenham <mtottenh@akamai.com>,
	Josh Hunt <johunt@akamai.com>, Matt Pelland <mpelland@akamai.com>
Subject: Re: [RFC 1/1] mm/pagewalk: don't split device-backed huge pfnmaps
Date: Mon, 9 Mar 2026 21:19:27 +0100	[thread overview]
Message-ID: <51eeb09d-d3f4-412f-85da-690fdc0f8e6a@kernel.org> (raw)
In-Reply-To: <20260309174949.2514565-2-mboone@akamai.com>

On 3/9/26 18:49, Max Boone wrote:
> Don't split and descend on special PMD/PUDs, which are generally
> device-backed huge pfnmaps as used by vfio for BAR mapping. These
> can be faulted back in after splitting and before descending, which
> can race to an illegal read.
> 
> Signed-off-by: Max Boone <mboone@akamai.com>
> Signed-off-by: Max Tottenham <mtottenh@akamai.com>
> 
> ---
>  mm/pagewalk.c | 24 ++++++++++++++++++++----
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
> index a94c401ab..d1460dd84 100644
> --- a/mm/pagewalk.c
> +++ b/mm/pagewalk.c
> @@ -147,10 +147,18 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>  				continue;
>  		}
>  
> -		if (walk->vma)
> +		if (walk->vma) {
> +			/*
> +			 * Don't descend into device-backed pfnmaps,
> +			 * they might refault the PMD entry.
> +			 */
> +			if (unlikely(pmd_special(*pmd)))
> +				continue;

In general, if you're using pmd_special()/pud_split() and friends in
ordinary page table walking code, you are doing something wrong. We
don't want to leak these details in such page table walkers.

We do have vm_normal_page_pmd() to identify special mappings, but I
first have to understand what exactly you are trying to solve here.

(You would also be affecting the remapping of the huge zero folio.)

A lot more details from the cover letter belong into the patch
description. In fact, you don't even need a cover letter :)

IIUC, this is rather serious and would require a Fixes: and even Cc: stable?

I'll spend some time tomorrow trying to understand what the real problem
here is.

But for now: can this only be reproduces with PUDs (which you mention in
the cover letter) or also PMDs?

For the PMD case I would assume that pte_offset_map_lock() performs
proper checks And for the PUD case we are missing a re-check under PTL.

-- 
Cheers,

David

  reply	other threads:[~2026-03-09 20:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 17:49 [RFC 0/1] Avoid pagewalk hugepage-split race with VFIO DMA set Max Boone
2026-03-09 17:49 ` [RFC 1/1] mm/pagewalk: don't split device-backed huge pfnmaps Max Boone
2026-03-09 20:19   ` David Hildenbrand (Arm) [this message]
2026-03-09 22:47     ` Boone, Max
2026-03-09 23:02     ` Boone, Max
2026-03-10  9:11       ` David Hildenbrand (Arm)
2026-03-10 11:38         ` Boone, Max
2026-03-10 15:19           ` David Hildenbrand (Arm)
2026-03-11  9:42             ` Boone, Max
2026-03-11  9:59               ` David Hildenbrand (Arm)
2026-03-11 10:34                 ` Boone, Max
2026-03-11 10:45                   ` David Hildenbrand (Arm)
2026-03-11 11:14                     ` Boone, Max
2026-03-11 11:59                       ` David Hildenbrand (Arm)

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=51eeb09d-d3f4-412f-85da-690fdc0f8e6a@kernel.org \
    --to=david@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@shazbot.org \
    --cc=johunt@akamai.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mboone@akamai.com \
    --cc=mhocko@suse.com \
    --cc=mpelland@akamai.com \
    --cc=mtottenh@akamai.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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.