On 11/17/2012 12:48 PM, Hugh Dickins wrote:
Further offtopic..
Thanks for your explanation, Hugh. :-)
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.
What's the different between shmem/tmpfs hole-punching and
truncate_setsize/truncate_pagecache?
Do you mean one is punch hole in the file and the other one is shrink or
extent the size of a file?
- 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.
IIUC, it will return VM_xxx_OOM instead of SIGBUS if run out of memory.
Then how can get SIGBUS in this scene?
Regards,
Jaegeuk
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
