Further offtopic.. On Fri, 16 Nov 2012, Jaegeuk Hanse wrote: > Some questions about your shmem/tmpfs: misc and fallocate patchset. > > - Since shmem_setattr can truncate tmpfs files, why need add another similar > codes in function shmem_fallocate? What's the trick? I don't know if I understand you. In general, hole-punching is different from truncation. Supporting the hole-punch mode of the fallocate system call is different from supporting truncation. They're closely related, and share code, but meet different specifications. > - in tmpfs: support fallocate preallocation patch changelog: > "Christoph Hellwig: What for exactly? Please explain why preallocating on > tmpfs would make any sense. > Kay Sievers: To be able to safely use mmap(), regarding SIGBUS, on files on > the /dev/shm filesystem. The glibc fallback loop for -ENOSYS [or > -EOPNOTSUPP] on fallocate is just ugly." > Could shmem/tmpfs fallocate prevent one process truncate the file which the > second process mmap() and get SIGBUS when the second process access mmap but > out of current size of file? Again, I don't know if I understand you. fallocate does not prevent truncation or races or SIGBUS. I believe that Kay meant that without using fallocate to allocate the memory in advance, systemd found it hard to protect itself from the possibility of getting a SIGBUS, if access to a shmem mapping happened to run out of memory/space in the middle. I never grasped why writing the file in advance was not good enough: fallocate happened to be what they hoped to use, and it was hard to deny it, given that tmpfs already supported hole-punching, and was about to convert to the fallocate interface for that. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>