Messages in this thread | | | Date | Sat, 7 Apr 2012 10:14:13 +0200 | Subject | Re: [PATCH 0/2] [RFC] Volatile Ranges (v6) | From | Dmitry Adamushko <> |
| |
On 7 April 2012 02:08, John Stultz <john.stultz@linaro.org> wrote: > > Another detail is that by hanging the volatile ranges off of the > address_space, the volatility for tmpfs files persists even when no one > has an open fd on the file. This could cause some surprises if application > A marked some pages volatile and died, then application B opened the file > and had pages dropped out underneith it while it was being used. I suspect > I need to clean up the volatility when all fds are dropped.
And how do you handle the regions that have already been purged by this moment? Unless B has some specific mechanism to verify the consistency of the content, a sensible way would be to always mark off the regions as non-volatile before accessing them and verify the return code to see if there are holes.
More generally, what if B opens the file while A is still working with it? Besides the use of normal synchronization mechanisms, B should not make any assumption on the current state of the regions (unless there is a high-level protocol between A and B to share this info). So an explicit mark-off-as-non_volatile could be a simple generic mechanism.
--Dmitry
| |