Wouldn't this break the existing semantics of mmap, which is after the mmap call returns, other threads in the same process will fault if the they access the mapping?

Sure, avoiding re-use prevents some types of bugs but not others.

Id be interested to know if any program relies on freeing memory in one thread, then (with some lock for synchronization) deliberately accessing it from another thread causing a segfault.

Sure, it's possible, but if no programs do it, it might be worth breaking the behaviour for the performance increase.

If the program is just using mmap/munmap for memory allocation, then I agree with you.

But some programs do crazier things. Imagine a program that implements mmap of a file entirely in userspace. For example, say I have a file that's stored on a distributed filesystem that dosen't have kernel drivers. So I catch SIGSEGV in userspace and populate pages on-demand by fetching them from the remote server. Later on, the page hasn't been used in a while, so I munmap() it to reclaim memory. I expect that any further uses after this point (especially writes, which maybe I need to sync back?) will raise a new SIGSEGV which I can handle.

I think something like that, unfortunately, could be broken by changing all munmaps to be lazy...

I was wondering how this scheme might break applications that do clever things with a SIGBUS/SIGSEGV handler. Do you happen to know of any OSS that actually does something like this?

FUSE?