Zack Weinberg wrote: > On Wed, Jul 31, 2024, at 7:56 AM, Yury V. Zaytsev wrote: >> So it appears to be not as trivial as “mmap on AIX has been broken for >> ages”, but rather it seems that up to some version of AIX (4-5?), it >> used to require unmapping the address first. After that IBM still kept >> it as the default behavior, but added spec-compliant behavior to the >> set of behavioral changes invoked by the XPG_SUS_ENV variable, most >> likely out of backwards compatibility concerns… > > Thanks for digging into this, Yury. I have access to AIX machines via > the GCC compile farm but I would not have been able to find this. > >> So, the bottom line, I guess, is still that the autoconf test is >> correct in terms of checking for spec compliant behavior. It’s of no >> help to developers who want mmap on AIX, but at least it prevents >> the worst. >> >> Probably breaking the macro down as Zack has suggested would be >> helpful so that MAP_FIXED behavior could be examined separately if >> needed, but still, for my use case, it’s better to just get rid of >> mmap altogether. > > Independently, I have written a new test program that probes for a > superset of the things that the existing AC_FUNC_MMAP test probes for. > My goal for this program is to determine which problems are still > present on current-generation operating systems, and how far back in > time we have to go to encounter the problems that no longer show up > today. It's attached to this email, and also posted for convenient > download at > <https://paste.sr.ht/~zackw/69f6fe801335583216de012b2d2f86c7d43afd76>. > > I ran this program on all the operating systems conveniently > available to me, all of which are reasonably up to date. A fully > correct implementation of mmap (as far as the test goes) will print > something like > > note: using 4096 bytes as page size. > note: define MMAP_PROBE_PAGESIZE if this is incorrect. > test: zero-fill after EOF (shared mapping)... ok > test: zero-fill after EOF (private mapping)... ok > test: writes visible via shared map... ok > test: shared map alterations visible via read... ok > test: shared map alterations visible via second map... ok > test: private read-write map of file opened read-only... ok > test: alter private map of file opened read-only... ok > test: alter private map of file opened read-write... ok > test: replace existing mapping... ok > > I get this result on: > x86_64-pc-linux-gnu > x86_64-unknown-freebsd13.3 > aarch64c-unknown-freebsd14.0 > x86_64-unknown-netbsd10.0 > sparc-sun-solaris2.10 > sparc-sun-solaris2.11 > powerpc-ibm-aix7.1.5.0 (with XPG_SUS_ENV=ON) > powerpc-ibm-aix7.3.1.0 (with XPG_SUS_ENV=ON) > > I get the previously discussed MAP_FIXED failure on both powerpc-ibm-aix7 > machines if I don't set XPG_SUS_ENV=ON. > > 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
