> Hi, all. Appended below is a programme which demonstrates a race
> condition in the open(2) code. I pass the O_CREAT | O_EXCL flags, and
> sometimes I get ENOENT returned, which I believe should never happen.
> The test programme launches a number of threads which alternatively
> create and unlink the file. A typical output from the programme (on my
> dual PPro system), with kernel 2.1.113 is:
Most VFS operations require that the parent directory be locked in order to avoid
various nasty races. But even the operation of locking the parent directory has
races -- by the time the lock is obtained, the child might have been deleted or
moved elsewhere.
To guard against this (which caused lots of problems back in the 2.1.4x - 2.1.5x
kernels), the parent locking operation checks that the child is still a child and
is still hashed; otherwise it returns ENOENT. That's probably what you're seeing.
Arguably some of these ENOENT cases should be silently retried, but the situation
should be quite rare in actual practice, if not while under stress testing.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html