mmap()ing a size-extended file on a 100% full tmpfs

[Adam Endrodi <adam.endrodi@nsn.com>]

Hello,


If you try to run the following program with /dev/shm being 100% full, it will
be terminated by a SIGBUS in memset():

"""
#define _GNU_SOURCE
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/mman.h>

int main(void)
{
	int fd = shm_open("segg", O_CREAT|O_RDWR, 0666);
	printf("fd: %d\n", fd);
	printf("truncate: %d\n", ftruncate(fd, 1024*1024));
//	errno = posix_fallocate(fd, 0, 1024*1024);
//	printf("falloc: %s\n", strerror(errno));
	void *ptr = mmap(NULL, 1024*1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	printf("ptr: %p\n", ptr);

	memset(ptr, 0, 1024*1024);

	return 0;
}
"""

On a similarly full ext2 file system memset() completes successfully (though
I'm not sure whether it made through it by mere chance).

So the probelm is that the program may not know at all what the underlying
file system is, and in case of tmpfs it may be terminated for a completely
unexpected reason.

A portable solution could be to [posix_]fallocate() the file before trying to
mmap() it.  That works (except that perhaps tmpfs can deallocate memory if
it's under pressure).

Alternatively I could imagine such an ftruncate() implementation for tmpfs,
which would incorporate fallocate()ion.

In combination with this mmap() could refuse the operation if insufficient
backing store is available.  Ie. it would return MAP_FAILED if the programmer
didn't call ftruncate() which would include fallocate().

The wayland developers faced the same problem last year:
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011501.html

My opinion is that either ftruncate() or mmap() should return an error.
What do you think?

-- 
adam

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>