The shrinking role of ETXTBSY

Posted Aug 23, 2021 9:06 UTC (Mon) by anton (subscriber, #25547)
In reply to: The shrinking role of ETXTBSY by willy
Parent article: The shrinking role of ETXTBSY

Even if the application has used MAP_PRIVATE, that covers how to handle a store from the mmapper, not a write() from somebody else.

That's disturbing. Still, if a MAP_PRIVATE page is written to (e.g., with its original content) in one place, it is copied on that write, and later changes to the original don't affect it.

So that is what could be done on writing to an executed text file: in every affected process, make private copies of the pages of the whole original text (as if on copy-on-write) and populate the mapping with them. There is an opportunity for sharing between several processes that run the same changed binary, but I guess that the benefit is too small and too rare to make that effort. OTOH, the benefit of not having ETXTBSY and not having processes crash when their binary changes is more substantial IMO.

Actually, I would like that also for interpreters (a have had a number of shell scripts crash when I edited them while they were running), maybe by making MAP_PRIVATE|MAP_POPULATE behave that way, or with an additional flag to mmap().

The shrinking role of ETXTBSY

Posted Aug 23, 2021 20:18 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (1 responses)

What would be the benefit of doing that with mmap(MAP_PRIVATE|MAP_POPULATE) vs. just reading the entire file into the process's anonymous private memory? Of course even if you do that the file could change while you're reading it, so it would reduce the window where the data could be corrupted but not eliminate it altogether.

For that matter, any process that could rewrite or truncate a file while it's in use could also corrupt the data beforehand. ETXTBUSY only protects against *accidentally* corrupting a file by updating it while it's in use, by forcing the update to fail. However, since we don't want the update to fail anyway, the solution which doesn't risk data corruption *or* an ETXTBUSY error is to write the new data to a temporary file and rename it over the original. This does require write access to the parent directory, but that doesn't seem unreasonable to me since logically you are modifying the directory to point to a new file. Any attempt to atomically update the content without replacing the file will run into the issue that mapping follow the file, not the content.

The shrinking role of ETXTBSY

Posted Aug 23, 2021 21:28 UTC (Mon) by anton (subscriber, #25547) [Link]

What would be the benefit of doing that with mmap(MAP_PRIVATE|MAP_POPULATE) vs. just reading the entire file into the process's anonymous private memory?

Zero-copy unless someone tries to write to the file. The way I imagine it, the write would block until the copying is completed, so this race condition would not exist.

The approach to write new file and rename over the old one would a good one, but despite the inconvenience of ETXTBSY linkers don't use this approach, so maybe the problem with the unwritable directories is more relevant than we think.