Hi, Mike, On Thu, Sep 29, 2022 at 04:33:53PM -0700, Mike Kravetz wrote: > I added some TLB flushing to hugetlb_mcopy_atomic_pte, but it did not make > any difference. Suggestions would be appreciated as cache/tlb/??? flushing > issues take me a while to figure out. It seems the UFFDIO_COPY for hugetlb is the major issue here, in that for private mappings we don't inject the page cache. I think it makes sense in that e.g. we don't want to allow a private mapping to be able to write to the page cache. But afaict that's not correct because UFFDIO_COPY resolves exactly page faults in page cache layer for file backed memories. So what we should do is inject page cache but mark the page RO, waiting for a coming CoW if needed. I'll attach one patch fix that will start to inject the page into page cache for UFFDIO_COPY+hugetlb even if mapping is private. Another test patch is also added because otherwise the private hugetlb selftest won't work after the fix applied - in the selftest we used to use DONTNEED to drop the private mapping, but IMHO that's not enough, we need to drop the page cache too (after the fix). I've also have the test patch attached. Feel free to try out with the two patches applied. It started to work for me for current issue. I didn't yet post them out yet because after I applied the two patches I found other issues - the reserved pages are messed up and leaked. I'll keep looking tomorrow on the leak issue, but please also let me know if you figured anything suspecious as I know you're definitely must more fluent on the reservation code. And that's not the only issue I found - shmem can have other issues regarding private mappings; shmem does it right on the page cache insertion but not the rest I think.. I'll look into them one by one. It's quite interesting to dig multiple things out of the write check symptons.. -- Peter Xu
