On Wed, Jul 31, 2024, at 5:39 PM, Howard Chu wrote: > Zack Weinberg wrote: >> Finally, I got two failures I wasn't expecting to see at all: >> >> test: writes visible via shared map... FAIL: data mismatch >> test: shared map alterations visible via read... FAIL: data mismatch >> amd64-unknown-openbsd7.5 >> mips64-unknown-openbsd7.5 > > As I said in an earlier email, OpenBSD is known to not have a unified > buffer cache, so this type of failure is expected there. Regrettably, I didn't understand that that was what you meant when you said OpenBSD doesn't have a unified buffer cache. Thanks for the clarification. It is not clear to me from https://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html whether POSIX declares OpenBSD to be out of spec in this regard. There is clear language in the specification of write() requiring write() operations to be visible to all subsequent read() operations ("After a write() to a regular file has successfully returned, any successful read() from each byte position in the file that was modified by that write shall return the data specified by the write() for that position until such byte positions are again modified") but the closest thing I can find to any such requirement for mmap() is "If MAP_SHARED is specified, write references shall change the underlying object". If there's relevant text anywhere else in POSIX I haven't found it. For Autoconf's purposes, what we really need to know is: on OpenBSD, what does an application need to do after it modifies a MAP_SHARED mapping using memory writes to make those writes visible to read()? And conversely, what does it need to do after it modifies a file using write() to make those writes visible to existing MAP_SHARED mappings? The answers to those questions will get written into our "Portable C Programming" manual section for mmap, and will also clarify whether we ought to provide a macro that checks for this, er, let's call it a behavioral variation for now. zw
