Re: [PATCH v4 2/9] riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code

[Alexandre Ghiti <alexghiti@rivosinc.com>]

Hi Matthew,

On Fri, Feb 14, 2025 at 1:39 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
>
> Hi Matthew,
>
> Sorry for the very late reply, the flu hit me!
>
> On Mon, Jan 27, 2025 at 2:51 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Mon, Jan 27, 2025 at 10:35:23AM +0100, Alexandre Ghiti wrote:
> > > +#ifdef CONFIG_RISCV_ISA_SVNAPOT
> > > +static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
> > > +                         pte_t *ptep, pte_t pteval, unsigned int nr)
> > > +{
> > > +     if (unlikely(pte_valid_napot(pteval))) {
> > > +             unsigned int order = ilog2(nr);
> > > +
> > > +             if (!is_napot_order(order)) {
> > > +                     /*
> > > +                      * Something's weird, we are given a NAPOT pte but the
> >
> > No, nothing is weird.  This can happen under a lot of different
> > circumstances.  For example, one might mmap() part of a file and the
> > folio containing the data is only partially mapped.
>
> I don't see how/when we would mark a PTE as napot if we try to mmap an
> address that is not aligned on the size of a napot mapping or does not
> have a napot mapping size.
>
> > The filesystem /
> > page cache might choose to use a folio order that isn't one of your
> > magic hardware orders.
> >
> > > +                      * size of the mapping is not a known NAPOT mapping
> > > +                      * size, so clear the NAPOT bit and map this without
> > > +                      * NAPOT support: core mm only manipulates pte with the
> > > +                      * real pfn so we know the pte is valid without the N
> > > +                      * bit.
> > > +                      */
> > > +                     pr_err("Incorrect NAPOT mapping, resetting.\n");
> > > +                     pteval = pte_clear_napot(pteval);
> > > +             } else {
> > > +                     /*
> > > +                      * NAPOT ptes that arrive here only have the N bit set
> > > +                      * and their pfn does not contain the mapping size, so
> > > +                      * set that here.
> > > +                      */
> > > +                     pteval = pte_mknapot(pteval, order);
> >
> > You're assuming that pteval is aligned to the order that you've
> > calculated, and again that's not true.  For example, the user may have
> > called mmap() on range 0x21000-0x40000 of a file which is covered by
> > a 128kB folio.  You'll be called with a pteval pointing to 0x21000 and
> > calculate that you can put a 64kB entry there ... no.
>
> Yes, I agree with this, then we have to go through the list of ptes
> and check if inside the region we are currently setting, some
> subregions correspond to a napot mapping.

So I looked at that and I think we are safe with the implementation in
this patch because:

- this patchset only deals with hugetlb, which cannot be partially
mapped (right?)
- when we'll add support for THP (upcoming series), we'll use arm64
set_ptes() implementation which splits the region to map using the
contpte mapping size
(https://elixir.bootlin.com/linux/v6.13.4/source/arch/arm64/mm/contpte.c#L268),
so we can't mark an unaligned region with the contpte bit.

Let me know if I missed something,

Thanks again,

Alex

>
> Thanks for your feedback,
>
> Alex
>
>
> >
> > I'd suggest you do some testing with fstests and xfs as your underlying
> > filesystem.  It should catch these kinds of mistakes.