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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
