Re: Data races in ext4

[Pedro Fonseca <pfonseca@mpi-sws.org>]

>> 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