Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 May 2002 10:02:08 -0400 (EDT)
From:      "Geoffrey C. Speicher" <geoff@sea-incorporated.com>
To:        Paul Herman <pherman@frenchfries.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: bug in pw, -STABLE [patch]
Message-ID:  <Pine.BSF.4.10.10205180936470.72119-100000@sea-incorporated.com>
In-Reply-To: <20020517200005.J912-100000@mammoth.eat.frenchfries.net>

next in thread | previous in thread | raw e-mail | index | archive | help
[I'm bringing the discussion back to -hackers, since it was omitted in
your original reply, Paul.  To get everyone up to speed, Paul suggested
that calling unlink() _before_ close() should solve the race condition
mentioned in my original message.  However, that still leads to
corruption, and we're trying to figure out why.]

On Fri, 17 May 2002, Paul Herman wrote:

> > The file isn't actually unlinked until p1 closes the fd
> 
> Sure it is.  Try a little C:
> 
>         fd = open("watchme", O_CREAT|O_EXLOCK);
>         sleep(10);
>         unlink("watchme");
>         sleep(10);
>         close(fd);
> 
> You'll see the file disappear after 10 seconds, not 20.

Hmm.  Rechecking the man page for unlink(2) I see that I worded the above
incorrectly.  The file is unlinked when you unlink(), but not actually
removed until close().

> Also, open() looks like it blocks until it can get the lock

But when does open() block in the following scenario?

 p1:open()	- open & lock file
 p2:open()	- BLOCK
 p1:unlink()	- remove link only, do not remove file
 p2:open()	- WAKEUP
 p1:close()	- close fd

Does it block before it opens a fd, or after then but before it gains an
exclusive lock?  In other words, did p2 open a new file after it woke up,
or did it open the same file that p1 had opened?  If the latter is true
then we could extend the above:

 p3:open()	- open & lock file (since p1 unlinked p1 & p2's copy)
 p2/p3:<update master.passwd>	- BOOM

If the former is true, then I'm pretty much out of ideas.  I don't think
the corruption is due to something else, since simply removing the call to
unlink() does in fact fix the problem.

Geoff


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10205180936470.72119-100000>