Suppressing SIGBUS signals

Posted Jun 26, 2021 18:02 UTC (Sat) by izbyshev (guest, #107996)
In reply to: Suppressing SIGBUS signals by roc
Parent article: Suppressing SIGBUS signals

> Rust safety only requires that &[u8] reference a range of memory that doesn't change and doesn't cause a crash if you access it.

Consider the following sequence of events:
1. Program A maps the file with MAP_PRIVATE | MAP_NOSIGBUS.
2. Program A accesses page P from that file.
3. Program B truncates the file to zero.
4. Page P is evicted from RAM due to memory pressure.
5. Program A accesses page P again.

How is the resulting page fault handled? If a zero-filled page is mapped, then the contents of the range of memory does change silently.

Suppressing SIGBUS signals

Posted Jun 27, 2021 14:24 UTC (Sun) by ocrete (subscriber, #107180) [Link] (1 responses)

Isn't the content of a memory range chaning silently always possible if another program is modifying the file?

Suppressing SIGBUS signals

Posted Jun 28, 2021 0:07 UTC (Mon) by izbyshev (guest, #107996) [Link]

Yes (the man page says that behavior of MAP_PRIVATE is unspecified if the underlying file changes, but this is what happens on Linux in practice). The ftruncate()-based scenario is only somewhat interesting because it might seem like it only changes the file metadata, but in fact the data in the truncated tail also changes (as observed by mmap() users).

To be clear, the same behavior within the last page of the file is already possible with current kernels: ftruncate() that doesn't remove the last page completely will look like filling its remainder with zeros (though it's also formally unspecified).

So, overall, I don't see how MAP_NOSIGBUS would help with unsafety of Rust's &[u8] referring to mmap()'ed range.