On Mon, Jul 12, 2021 at 9:58 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 7/12/21 7:48 AM, Matthew Wilcox wrote: > > On Wed, Jun 30, 2021 at 06:48:19PM -0700, Andrew Morton wrote: > >> From: Mina Almasry <almasrymina@xxxxxxxxxx> > >> Subject: mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY > >> > >> On UFFDIO_COPY, if we fail to copy the page contents while holding the > >> hugetlb_fault_mutex, we will drop the mutex and return to the caller after > >> allocating a page that consumed a reservation. In this case there may be > >> a fault that double consumes the reservation. To handle this, we free the > >> allocated page, fix the reservations, and allocate a temporary hugetlb > >> page and return that to the caller. When the caller does the copy outside > >> of the lock, we again check the cache, and allocate a page consuming the > >> reservation, and copy over the contents. > > > > But you only copy over the contents *IF* CONFIG_MIGRATION is enabled! > > Now, maybe there aren't many configs out there that enable HUGETLBFS > > and disable MIGRATION, but this is sloppy. > > > > Thanks Matthew! > > Not copying the contents is also a security exposure. We rely on copying > the contents to clear the page's previous contents. > > I suggested using copy_huge_page here as a previous version of the patch > replicated the code. The NULL function slipped by me when reviewing. > Perhaps it would be best to move those copy_huge_page routines to > huge_memory.c as it is used by both THP and hugetlbfs. > > Mina, can you look into fixing this? Gah, sorry, I missed that the function is a no-op if CONFIG_MIGRATION is not set. I'll send a follow up fix to this. Thanks for catching! > -- > Mike Kravetz
