I know that when a page cache page is modified, it is marked dirty and requires a writeback, but what happens when:
Scenario: The file /apps/EXE, which is an executable file, is paged in to the page cache completely (all of its pages are in cache/memory) and being executed by process P
Continuous release then replaces /apps/EXE with a brand new executable.
Assumption 1: I assume that process P (and anyone else with a file descriptor referencing the old executable) will continue to use the old, in memory /apps/EXE without an issue, and any new process which tries to exec that path will get the new executable.
Assumption 2: I assume that if not all pages of the file are mapped into memory, that things will be fine until there is a page fault requiring pages from the file that have been replaced, and probably a segfault will occur?
Question 1: If you mlock all of the pages of the file with something like vmtouch does that change the scenario at all?
Question 2: If /apps/EXE is on a remote NFS, would that make any difference? (I assume not)
Please correct or validate my 2 assumptions and answer my 2 questions.
Let's assume this is a CentOS 7.6 box with some kind of 3.10.0-957.el7 kernel
Update: Thinking about it further, I wonder if this scenario is no different than any other dirty page scenario..
I suppose the process that writes the new binary will do a read and get all cache pages since it’s all paged in, and then all those pages will be marked dirty. If they are mlocked, they will just be useless pages occupying core memory after the ref count goes to zero.
I suspect when the currently-executing programs end, anything else will use the new binary. Assuming that’s all correct, I guess it’s only interesting when only some of the file is paged in.