lkml.org 
[lkml]   [1998]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.049 / U:1.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site