Hi Peter, On 08/08/2024 12:25, Ryan Roberts wrote: > On 07/08/2024 19:59, Peter Xu wrote: >> On Wed, Aug 07, 2024 at 12:18:18PM +0200, David Hildenbrand wrote: >>> On 07.08.24 10:58, David Hildenbrand wrote: >>>> On 06.08.24 22:29, Peter Xu wrote: >>>>> On Tue, Aug 06, 2024 at 06:37:55PM +0200, David Hildenbrand wrote: >>>>>> On 06.08.24 17:15, Ryan Roberts wrote: >>>>>>> Hi Peter, David, >>>>> >>>>> Hi, Ryan, >>>>> >>>>>>> >>>>>>> syzkaller has found an issue (at least on arm64, but I suspect it will be >>>>>>> visible on x86_64 too) that triggers the following warning: >>>>> >>>>> This is true. I can easily reproduce.. >>>>> [...] >> When I'm looking at this specific issue again, it's more than ptes that >> should need to remove the uffd-wp bit. We have: >> >> - pmd/pud/hugetlb in other paths that will need similar care.. >> >> - move_page_tables() smartness on HAVE_MOVE_PUD.. where we may need to >> walk the pmd page removing the bits when necessary.. >> >> - more importantly, mremap_userfaultfd_prep() might be too late if it's >> after moving pgtables.. >> >> - [not yet started looking] the mlock issue Ryan mentioned.. >> >> Looks like we'll need more things to fix and test.. >> >> I wished if I can simply disable UFFD_WP + EVENT_REMAP, but I think even >> with that, by default when mremap() we should still logically tear down all >> those uffd-wp bits which is the same as !EVENT_REMAP now.. >> >> Let me know if anyone would like to beat me to it on fixing the whole >> thing, I'd be more than happy.. > > Afraid I won't be able to sign up to doing that work. > > Otherwise, I'll probably need to postpone >> the fix of this issue for 1-2 weeks but finish some other things first.. I'm not sure if there was any progress on this? We are still seeing the problem on v6.12-rc1. Thanks, Ryan
