I noticed that the kernel does not do any locking when copying the
inode stat info. This make stat very fast, but there is a small
race condition on SMP machines that can cause stat to return unexpected
results for if another process is simulteously changing something
returned by stat that is not updated atomically.
One example, is a stat() at the same time of a chown(new_uid, new_gid).
Since uid and gid are updated individually, the stat() can
return new_uid and old_gid. I have a test program that sees
this on my 2 processor system running 2.4.18. I am not sure if this
is a bug, but it is unexpected behavior. One would expect to see the
stat() return the old_uid,old_gid OR new_uid,new_gid.
The 2nd example is a stat64() at the same time as a write() on a 32bit
cpu that causes the upper 32bits to be modified -- like a write causing
the length of a file to grow from 4GB-1 to 4GB. Obviously, compiling the
application for large file support is required. Since the 64bit size
is not atomically updated on a 32bit cpu, it is possible, very rarely,
to see an incorrect size of 8GB-1 returned by stat64() in this case.
I have a test program that sees this on my 2 processor x86. Also,
a stat64() racing with a truncate64() can see this on a x86 as well.
This is a bug.
Both of these race conditions could be considered to be bugs. The
second is more serious. However, both are rare. Can anyone tell me of
a case where the uid/gid race or the 64-bit increment race would cause a
problem for an application or utility?
Daniel
-
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/
This archive was generated by hypermail 2b29 : Sun Mar 31 2002 - 22:00:19 EST