I don't like them really.
Yes, I know, a bug is a bug is a bug and it should be fixed. But the fix
is fugly and the bug seems to be very theoretical. And the patches appear
to not address all the i_size accesses down in filesystems.
The patches add barriers and cache footprint to fastpaths, and we don't get
a lot back. As far as I know the bug has only been demonstrated when one
CPU is spinning on stat() and the other is waggling the file size across
the 4G boundary.
I'd be interested in seeing if the race is demonstrable anywhere else,
because the stat() problem can be plugged just by taking i_sem in
sys_stat().
So yeah, I know it _should_ be fixed, but it gives me the creeps, and the
fix may not be complete anyway.
And if the race _does_ hit, what is the effect? Assuming stat() was fixed
with i_sem, I don't think the race has a very serious effect. We won't
oops, or corrupt filesystems, or be insecure. Maybe some
probably-already-racy application gets a page of zeroes instead of live
data. Or maybe not - I'd need to think about that some more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/