Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
A FALLOC_FL_NO_HIDE_STALE followup
Posted Dec 6, 2012 13:06 UTC (Thu) by andresfreund (subscriber, #69562)
Afaics the only thing that happened for 3.7 was the introduction of that flag, nothing uses it yet, so there cannot be said too much about the security implications of the real thing...
Posted Dec 6, 2012 20:45 UTC (Thu) by cesarb (subscriber, #6266)
It would be better if any attempt to use the flag always returned -EPERM.
Posted Dec 6, 2012 20:57 UTC (Thu) by andresfreund (subscriber, #69562)
int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
@@ -249,6 +254,11 @@ int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
+ /* Check for enabling _NO_HIDE_STALE flag */
+ if (mode & FALLOC_FL_NO_HIDE_STALE &&
+ return -EPERM;
So such inexperienced programmers would fall on their noses.
I don't think the process in which this got through was great, but why assume the people working on this are stupid?
Posted Dec 6, 2012 21:43 UTC (Thu) by cesarb (subscriber, #6266)
/* Return error if mode is not supported */
if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
So any inexperienced programmer incorrectly attempting to use the flag to "make things go faster" will already receive an error, and the fallocate call will do nothing.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds