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.
Sure, avoiding re-use prevents some types of bugs but not others.
Sure, it's possible, but if no programs do it, it might be worth breaking the behaviour for the performance increase.
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...