From owner-freebsd-current Sun Feb 25 10:42:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11093 for current-outgoing; Sun, 25 Feb 1996 10:42:35 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA11086 for ; Sun, 25 Feb 1996 10:42:28 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id KAA15438; Sun, 25 Feb 1996 10:40:53 -0800 (PST) Message-Id: <199602251840.KAA15438@precipice.shockwave.com> To: Bruce Evans cc: jhay@mikom.csir.co.za, freebsd-current@freebsd.org Subject: Re: Bug in libc/db/hash/hash.c??? In-reply-to: Your message of "Sun, 25 Feb 1996 19:19:23 +1100." <199602250819.TAA09810@godzilla.zeta.org.au> Date: Sun, 25 Feb 1996 10:40:51 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk From: Bruce Evans Subject: Re: Bug in libc/db/hash/hash.c??? I'm not sure how postponing the stat helps. The problem seems to be with concurrent accesses to the database. First cap_mkdb opens it and it gets initialized. This hasn't changed. Then the getcap library opens it and it gets initialized again because the file length is 0. Oops. I'm not sure what code you're looking at, but that doesn't match my version of cap_mkdb. There is no getcap library code linked with this file, it's merely opened once, with flags O_CREAT | O_TRUNC, no more. I noticed a(nother) Heisenbug in the old code. statbuf.st_size isn't initialized if stat() fails. This only matters if stat() fails with an error other than ENOENT. (There is a similar bug involving errno.) Yes, which is why I changed it to a fstat and I only check statbuf.st_size if the fstat succeeded. Again, I did not save/restore errno because a perusal of the surrounding code shows that it's in an indeterminate state at that point (that is, there are calls immediately following it that would change the state). Now, the big question: "Is there still a bug with this?" Even if cap_mkdb doesn't do what you suggest, what happens if someone /does/ do concurrent opens of a file? You're correct, there -is- a race condition for the window between the open and the first hash_sync. We could either reduce that window by doing an initial hash_sync immediately after the table is initialized (yuck for two reasons), or toss this entire idea as being bad and revert back to pre-pst code. I don't have any brilliant ideas on how to do this, because if we implement locking, we'll break semantics further elsewhere.