https://bugs.winehq.org/show_bug.cgi?id=37669
--- Comment #14 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Sebastian Lackner from comment #13)
You should also keep in mind that there must be a reason why .NET / Silverlight uses write-watch protected pages for network buffers. I guess it is used as a fast method to determine when the async operation has been executed and new data is available.
I'd guess that's a part of a GC (garbage collector). dotnet uses overlapped completion events to track down the end of a read/write operation.
To make that fully compatible with Windows we should ideally get rid of the write watch check at the beginning of WSARecv, and only execute it when recvmsg returns EFAULT (see comments in my patch subject) - otherwise the application will check for completion multiple times.
If there is a reliable way to test whether recvmsg had failed because of a write watch (and not somebody else) has invalidated the buffer and check that not only linux kernel but at least osx don't corrupt data in a subsequent call then I'd prefer that way as well.