From: Andrew Morton <akpm@linux-foundation.org>
To: "Petr Vaněk" <arkamar@atlas.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>,
xen-devel@lists.xenproject.org, x86@kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV
Date: Sat, 3 May 2025 18:28:58 -0700 [thread overview]
Message-ID: <20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org> (raw)
In-Reply-To: <20250502215019.822-2-arkamar@atlas.cz>
On Fri, 2 May 2025 23:50:19 +0200 Petr Vaněk <arkamar@atlas.cz> wrote:
> On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a
> folio due to a corner case in pte_advance_pfn(). Specifically, when the
> PFN following the folio maps to an invalidated MFN,
>
> expected_pte = pte_advance_pfn(expected_pte, nr);
>
> produces a pte_none(). If the actual next PTE in memory is also
> pte_none(), the pte_same() succeeds,
>
> if (!pte_same(pte, expected_pte))
> break;
>
> the loop is not broken, and batching continues into unrelated memory.
>
> ...
Looks OK for now I guess but it looks like we should pay some attention
to what types we're using.
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -248,11 +248,9 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr,
> pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags,
> bool *any_writable, bool *any_young, bool *any_dirty)
> {
> - unsigned long folio_end_pfn = folio_pfn(folio) + folio_nr_pages(folio);
> - const pte_t *end_ptep = start_ptep + max_nr;
> pte_t expected_pte, *ptep;
> bool writable, young, dirty;
> - int nr;
> + int nr, cur_nr;
>
> if (any_writable)
> *any_writable = false;
> @@ -265,11 +263,15 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr,
> VM_WARN_ON_FOLIO(!folio_test_large(folio) || max_nr < 1, folio);
> VM_WARN_ON_FOLIO(page_folio(pfn_to_page(pte_pfn(pte))) != folio, folio);
>
> + /* Limit max_nr to the actual remaining PFNs in the folio we could batch. */
> + max_nr = min_t(unsigned long, max_nr,
> + folio_pfn(folio) + folio_nr_pages(folio) - pte_pfn(pte));
> +
Methinks max_nr really wants to be unsigned long. That will permit the
cleanup of quite a bit of truncation, extension, signedness conversion
and general type chaos in folio_pte_batch()'s various callers.
And...
Why does folio_nr_pages() return a signed quantity? It's a count.
And why the heck is folio_pte_batch() inlined? It's larger then my
first hard disk and it has five callsites!
next prev parent reply other threads:[~2025-05-04 1:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 21:50 [PATCH v2 0/1] mm: Xen PV regression after THP PTE optimization Petr Vaněk
2025-05-02 21:50 ` [PATCH v2 1/1] mm: fix folio_pte_batch() on XEN PV Petr Vaněk
2025-05-04 1:28 ` Andrew Morton [this message]
2025-05-04 6:47 ` David Hildenbrand
2025-05-04 7:15 ` Andrew Morton
2025-05-04 8:58 ` David Hildenbrand
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=20250503182858.5a02729fcffd6d4723afcfc2@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=arkamar@atlas.cz \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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