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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Sep 2021 09:47:42 -0700 From: Axel Rasmussen <axelrasmussen@...gle.com> To: Peter Xu <peterx@...hat.com> Cc: Hugh Dickins <hughd@...gle.com>, LKML <linux-kernel@...r.kernel.org>, Linux MM <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>, Andrea Arcangeli <aarcange@...hat.com>, Nadav Amit <nadav.amit@...il.com> Subject: Re: [PATCH] mm/khugepaged: Detecting uffd-wp vma more efficiently On Wed, Sep 22, 2021 at 7:18 PM Peter Xu <peterx@...hat.com> 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