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  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]
Date:   Thu, 23 Sep 2021 09:47:42 -0700
From:   Axel Rasmussen <>
To:     Peter Xu <>
Cc:     Hugh Dickins <>,
        LKML <>,
        Linux MM <>,
        Andrew Morton <>,
        Andrea Arcangeli <>,
        Nadav Amit <>
Subject: Re: [PATCH] mm/khugepaged: Detecting uffd-wp vma more efficiently

On Wed, Sep 22, 2021 at 7:18 PM Peter Xu <> wrote:
> On Wed, Sep 22, 2021 at 06:22:45PM -0700, Hugh Dickins wrote:
> > No, I think I misunderstood you before: thanks for re-explaining.
> > (And Axel's !userfaultfd_minor() check before calling do_fault_around()
> > plays an important part in making sure that it does reach shmem_fault().)
> Still thanks for confirming this, Hugh.
> Said that, Axel, I didn't mean I'm against doing something similar like
> uffd-wp; it's just a heads-up that maybe you won't find a reproducer with real
> issues with minor mode.
> Even if I think minor mode should be fine with current code, we could still
> choose to disable khugepaged from removing the pmd for VM_UFFD_MINOR vmas, just
> like what we'll do with VM_UFFD_WP.  At least it can still reduce false
> positives.
> So far in my local branch I queued the patch which I attached, that's required
> for uffd-wp shmem afaict.  If you think minor mode would like that too, I can
> post it separately with minor mode added in.

No worries, you can leave the minor fault case to me.

My thinking there was a THP collapse bug was really just based on
speculation, not a real reproducer, so it's very possible my
speculation was wrong. It will take some more thinking and reading to
convince myself one way or the other. :) Thanks to you and Hugh for
all the details.

I'd prefer not to add this fix "just in case", if it isn't a real
problem, as it seems like it may confuse future readers of the code.

I'll send out a patch for it if / when I manage to build a real
reproducer. Or, in the meantime, some of my Google colleagues are
testing this code via their live migration implementation, so if there
is a bug here there's a good chance we'll find it that way too.

> Note that it's slightly different from what I pasted in reply to Yang Shi - I
> made it slightly more complicated just to make sure there's no race.  I
> mentioned the possible race (I think) in the commit log.
> Let me know your preference.
> Thanks,
> --
> Peter Xu

Powered by blists - more mailing lists