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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/UcorZlyHC44/T5@monkey>
Date:   Tue, 21 Feb 2023 11:33:54 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     James Houghton <jthoughton@...gle.com>
Cc:     Mina Almasry <almasrymina@...gle.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 02/21/23 07:59, James Houghton wrote:
> 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.

Agree!

> 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."

Perhaps a better way of saying is that hugetlb pages are marked uptodate
shortly after allocation when their contents are initialized.  Initialized
data could be zero, or it could be contents copied from another location
(such as in the UFFDIO_COPY case also handled in this routine).

Saying "PageUptodate indicates that the page has been zeroed" as in the
commit message is technically not correct.

Ack to the patch.
-- 
Mike Kravetz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ