linux-kernel - Re: [PATCH v2 01/46] hugetlb: don't set PageUptodate for UFFDIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADrL8HWTe1b2UK4Ha6e=F_i+YSK_M4wXCQ-sxvYMkgR1EgaHpA@mail.gmail.com>
Date:   Tue, 21 Feb 2023 07:59:56 -0800
From:   James Houghton <jthoughton@...gle.com>
To:     Mina Almasry <almasrymina@...gle.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <songmuchun@...edance.com>,
        Peter Xu <peterx@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        "Zach O'Keefe" <zokeefe@...gle.com>,
        Manish Mishra <manish.mishra@...anix.com>,
        Naoya Horiguchi <naoya.horiguchi@....com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        Yang Shi <shy828301@...il.com>,
        Frank van der Linden <fvdl@...gle.com>,
        Jiaqi Yan <jiaqiyan@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 01/46] hugetlb: don't set PageUptodate for UFFDIO_CONTINUE

On Fri, Feb 17, 2023 at 4:42 PM Mina Almasry <almasrymina@...gle.com> wrote:
>
> On Fri, Feb 17, 2023 at 4:28 PM James Houghton <jthoughton@...gle.com> wrote:
> >
> > If would be bad if we actually set PageUptodate with UFFDIO_CONTINUE;
> > PageUptodate indicates that the page has been zeroed, and we don't want
> > to give a non-zeroed page to the user.
> >
> > The reason this change is being made now is because UFFDIO_CONTINUEs on
> > subpages definitely shouldn't set this page flag on the head page.
> >
> > Signed-off-by: James Houghton <jthoughton@...gle.com>
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 07abcb6eb203..792cb2e67ce5 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -6256,7 +6256,16 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
> >          * preceding stores to the page contents become visible before
> >          * the set_pte_at() write.
> >          */
> > -       __folio_mark_uptodate(folio);
> > +       if (!is_continue)
> > +               __folio_mark_uptodate(folio);
> > +       else if (!folio_test_uptodate(folio)) {
> > +               /*
> > +                * This should never happen; HugeTLB pages are always Uptodate
> > +                * as soon as they are allocated.
> > +                */
>
> if (is_continue) then we grab a page from the page cache, no? Are
> pages in page caches always uptodate? Why? I guess that means they're
> mapped hence uptodate?
>
> Also this comment should explain why pages in the page cache are
> always uptodate, no? Because this error branch is hit if (is_continue
> && !folio_test_uptodate()), not when pages are freshly allocated.

There was some discussion about it here[1].

Without even thinking about how the pages become uptodate, I think
this patch is justified like this: UFFDIO_CONTINUE => we aren't
actually changing the contents of the page, so we shouldn't be
changing the uptodate-ness of the page.

HugeTLB pages in the page cache are always uptodate:
1. fallocate -- the page is allocated, zeroed, marked as uptodate, and
then placed in the page cache.
2. hugetlb_no_page -- same as above.

So uptodate <=> "the page has been zeroed", so it would be very bad if
we gave a !uptodate page to userspace via UFFDIO_CONTINUE.

I'll update the comment to something like:

"HugeTLB pages are always Uptodate as soon as they are added to the
page cache. Given that we aren't changing the contents of the page, we
shouldn't be updating the Uptodate-ness of the page."

[1]: https://lore.kernel.org/linux-mm/Y5JrS4o5Detzid9V@monkey/

Thanks, Mina. :)

- James