Regarding the generic_fillattr() function, apart from the inconsistency
between i_blocks/i_size, it looks like it can also cause wrong values to be
returned because several of those fields are 64 bits.
Well, it's actually a 32-bit seconds and 32-bit nanoseconds field. So
we could theoretically get a torn value, but if the ns field is from a
previous update, the worst that could happen under those circumstances
is that two quick successive stat() commands could potentially result
in end up with an apparent "time moving backwards" in the nanoseconds
field. If someone was constantly calling utimes(2) to modify the
mtime/atime at high rate, that might cause a more serious wrong value,
but that's an argument you should take up with the generic VFS folks
as to whether it's important enough that they would want to care about
it.
Note that the races in stat() also involve the "inode->i_blocks" field,
which is also 64-bits. So, as far as I understand, this field too can
get wrapped, although it should only affect very large files. (On the
other hand, the field inode->i_size seems to be protected.)
I'll follow your suggestion and let the VFS developers know about this.
P.S. What did you use to generate these reports? Is it something
that can be easily replicated by others?
We're currently developing an experimental tool to test the kernel for
concurrency bugs. It's not yet publicly available, but we hope it will
become available at some point in the future.
Thanks,
Pedro
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
