On 2010-02-05, at 02:42, Kamil Dudka wrote:
On Friday 05 of February 2010 09:48:00 Andreas Dilger wrote:
If the on-disk nanoseconds count happens to exceed 999,999,999 then
code_ns_fraction() will overflow the 9-character array and segfault.
While this shouldn't happen normally, it can happen due to corruption
of the on-disk data. If the ns field is larger than 999,999,999
truncate it to this value
thanks for bringing the patch here. I am attaching our version of
the same
patch. It tries to count the overflowed ns into the second part and
ignores
any negative value of ns, which can cause SIGSEGV as well. In fact
I am not
sure if such a situation can really happen, tested only with a
debugger.
I would argue that any nanosecond value >= 10^9 is simply due to
corruption, and propagating that into the seconds field isn't really
helping anything. However, I agree that it should also check for ns <
0 and clamp this to 0, since the timespec.ns or timeval.us field are
normally "long" and could theoretically be negative if the on-disk
value is corrupted and the kernel/filesystem doesn't validate the
values.
It is probably worthwhile to have e2fsck et. al. check for and fix
such corruption, but there are already filesystems in the wild with
these bad timestamps and tar shouldn't segfault when backing them up.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
