Date: Sun, 25 Feb 1996 10:40:51 -0800 From: Paul Traina <pst@shockwave.com> To: Bruce Evans <bde@zeta.org.au> Cc: jhay@mikom.csir.co.za, freebsd-current@freebsd.org Subject: Re: Bug in libc/db/hash/hash.c??? Message-ID: <199602251840.KAA15438@precipice.shockwave.com> In-Reply-To: Your message of "Sun, 25 Feb 1996 19:19:23 %2B1100." <199602250819.TAA09810@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Bruce Evans <bde@zeta.org.au> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602251840.KAA15438>