* Eric W. Biederman: > Florian Weimer, would it be possible to get glibc's ld.so implementation to use > MAP_SHARED? Just so people reading the code know what to expect of the > kernel? As far as I can tell there is not a practical difference > between a read-only MAP_PRIVATE and a read-only MAP_SHARED. Some applications use mprotect to change page protections behind glibc's back. Using MAP_SHARED would break fork pretty badly. Most of the hard-to-diagnose crashes seem to come from global data or relocations because they are wiped by truncation. And we certainly can't use MAP_SHARED for those. Code often seems to come back unchanged after the truncation because the overwritten file hasn't actually changed. File attributes don't help because the copying is an adminstrative action in the context of the application (maybe the result of some automation). I think avoiding the crashes isn't the right approach. What I'd like to see is better diagnostics. Writing mtime and ctime to the core file might help. Or adding a flag to the core file and /proc/PID/smaps that indicates if the file has been truncated across the mapping since the mapping was created. A bit less conservative and even more obvious to diagnose would be a new flag for the mapping (perhaps set via madvise) that causes any future access to the mapping to fault with SIGBUS and a special si_code value after the file has been truncated across the mapping. I think we would set that in the glibc dynamic loader. It would make the crashes much less weird. Thanks, Florian
