Mapped region still valid when size of underlying file changes? - linux

Question

Let's have a look at a few scenarios:
a)
file size : |---------|
mapped region: |---------|
region access: |XXXXXXXXX|
--> file grows
file size : |----------------|
mapped region: |---------|
region access: |XXXXXXXXX|
Is it still well-defined/portable/safe to access (read/write) the complete mapped region?
(assuming that the file grew via normal writes to it or via truncating it; file was just mapped once, no extra remapping after the file size changed)
b)
file size : |---------|
mapped region: |-----------------------|
access : |XXXXXXXXX|
--> file grows
file size : |-----------------------|
mapped region: |-----------------------|
access : |XXXXXXXXXXXXXXXXXXXXXXX|
Say, before the file was extended the program just accessed the intersection of the file size and the mapped region. This should be fine.
After the file grew - such that the sizes of the mapping and file match - is it now well defined to access every part of the region/file?
If this is the case, creating larger mapped regions in the beginning could be an optimization to avoid some mremap (or munmap/mmap) calls - at least for some use-cases.
c)
file size : |---------|
mapped region: |---------|
access : |XXXXXXXXX|
--> file is truncated
file size : |---|
mapped region: |---------|
access : |XXX|
As long as the program accesses the still overlapping part of the region - is that well-defined behaviour?

Answer 1

Generally, if size of mapped file is changed, it's safe to access pages not affected by size change, and it's unspecified what happens with pages affected by size change.
From mmap(2):
1.
If the size of the mapped file changes after the call to mmap() as a result of some other operation on the mapped file, the effect of references to portions of the mapped region that correspond to added or removed portions of the file is unspecified.
2.
The mmap() function can be used to map a region of memory that is larger than the current size of the object. Memory access within the mapping but beyond the current end of the underlying objects may result in SIGBUS signals being sent to the process.
So, in all three cases, it seems that it's safe to access all originally mapped pages below current file size and it's not safe to access pages above current file size.
I'm not totally sure about case (b), but it seems to be a valid case and it works at least in Linux.
Note that SIGBUS generation is not guaranteed and it's not specified what really happens when you access data above mapping size or above file size. Implementation may allow you to read valid data from the end of the page, for example.
There are also two optimization tricks related to question (to avoid mremap()):
You can allocate large memory region in heap and then subsequently mmap() pages you need using MAP_FIXED flag.
You can use linux-specific remap_file_pages(2) call.
Test program
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <sys/mman.h>
#define max(a, b) (a > b ? a : b)
int main(int argc, char** argv) {
int mmap_size = atoi(argv[1]);
int file_size1 = atoi(argv[2]);
int file_size2 = atoi(argv[3]);
char* data = malloc(max(file_size1, file_size2));
memset(data, 7, max(file_size1, file_size2));
int fd = open("foo", O_RDWR | O_TRUNC | O_CREAT, 0777);
write(fd, data, file_size1);
char* addr = mmap(NULL, mmap_size, PROT_READ, MAP_SHARED, fd, 0);
if (file_size2 <= file_size1)
ftruncate(fd, file_size2);
else
write(fd, data, file_size2 - file_size1);
printf("%d\n", addr[0]);
printf("%d\n", addr[file_size1 - 1]);
printf("%d\n", addr[file_size2 - 1]);
return 0;
}
Example output on Linux:
$ ./a.out 4096 4096 $(( 4096 * 2))
7
7
0
$ ./a.out $(( 4096 * 2 )) 4096 $(( 4096 * 2))
7
7
7
$ ./a.out $(( 4096 * 2 )) $(( 4096 * 2)) 4096
7
Bus error

Answer 2

1) The file grows after having been mapped
If you know that the file will grow, you would map it with the matching flag so that the mapping grows with the file.
If you do not know that the file will grow, you would also not access behind the mapped area.
2) The file shrinks after having been mapped
If you know that the file has shrunk, there is no reason to access the the area after the end of the file as you would get a signal.
If you do not know that the file has shrunk, see my other answer to this question.