http://bugs.winehq.org/show_bug.cgi?id=29384 mikey9220@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikey9220@gmail.com --- Comment #93 from mikey9220@gmail.com --- I've been working on this for the Battle.net / CEF case (bug 53835) and have a working implementation that takes a different route than userfaultfd, so I'd like to check the direction here before opening an MR. The observation: Windows semantics for this are "the page is a private copy". The tests in kernel32/tests/virtual.c (the map_prot_written() loop) show that once a page has been copied on write, every later VirtualProtect reports the written protection, no matter what sequence of protections is applied. And the kernel already knows which pages are private copies: on Linux a written page of a MAP_PRIVATE file mapping shows up in /proc/self/pagemap as an exclusively mapped anonymous page, on macOS mach_vm_page_range_query reports it as copied. So the protection can be reported correctly by asking the kernel at NtProtectVirtualMemory / NtQueryVirtualMemory time, with no signal handlers, no EFAULT problems with syscalls writing into read-only pages, and no extra faults at runtime. The missing piece is that Wine itself writes to image pages while mapping them (ImageBase in the headers, relocations, the zeroed tail of sections), which makes them private copies before the application ever runs. Windows does that work in the kernel and shares the result. The patch moves those pages into an anonymous file after mapping and maps them back MAP_PRIVATE, so they read as clean copy-on-write pages again and only application writes show up as copies. Status: Battle.net's renderer passes its CHECK_EQ(PAGE_READWRITE) and the client works with no other hacks. ntdll:virtual passes, kernel32:loader and psapi are at their baseline, and the WRITECOPY todos in kernel32:virtual now pass (tested on macOS; the remaining failures there are pre-existing macOS issues and 16k page granularity artifacts). Views that are mapped shared still write through to the file, that part is untouched and stays todo. Zhiyi, does this conflict with your userfaultfd branch? As far as I can tell they solve different layers: pagemap/page query answers "has this page been copied", which is enough for the protection reporting, while uffd-wp would additionally catch writes that don't create a copy. If the read-back approach is acceptable I'll split it into an MR (three parts: image mapping, reporting, tests). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.