Messages in this thread | | | Date | Sat, 01 Aug 1998 08:25:05 -0700 | From | Bill Hawes <> | Subject | Re: Races in open(2) |
| |
Richard Gooch wrote:
> 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
| |