Messages in this thread | | | Date | Mon, 3 Aug 1998 10:50:02 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: Races in open(2) |
| |
On Sat, 1 Aug 1998, Bill Hawes wrote:
> 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.
Returning ENOENT when the parent exists is not compliant. This is the type of kernel bug that's really annoying for application developers. "Oh, if it's linux then I have to retry my open() in user-space if I get ENOENT because they've got some fancy locking scheme and don't want to spend a few cycles in the kernel being compliant"...
In Richard's example the parent is /tmp ... I can't imagine it not being present.
Dean
- 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
| |