On Sun, Nov 17, 2013 at 01:15:14PM +0700, Robert Elz wrote: > Alternatively, the system could actually allocate all required blocks at > the time of the posix_fallocate() call - effectively filling in any holes > in the designated region of the file. The spec doesn't say what data is > to be put in the blocks allocated to fill the holes (a well behaved > application wouldn't care, as it would normally write to the file before > reading it, and would be using fallocate to guarantee that the entire set > of write sys call it needed to make would succeed (or the fallocate() > would fail), and the system could not run out of space half way through.)
Holes in a file read as zeros, and providing backing for the holes shouldn't change that. Arguably not referencing this property is a bug in the standard, but I think it's pretty clear what the intended behavior is. > a trivial DoS attack like .... > > for (;;) { > ftruncate(fd); > posix_fallocate(fd, (off_t)0, huge); > } I don't see how this is a DoS attack that e.g. dd if=/dev/urandom of=/dev/null isn't. The write loop is in the kernel, but we're no longer in the days of nonpreemptible uniprocessor kernels, so it shouldn't matter much. -- David A. Holland dholl...@netbsd.org