Date: Fri, 23 Jun 2023 12:00:36 -0700 From: Alan Somers <asomers@freebsd.org> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Should close() release locks atomically? Message-ID: <CAOtMX2jjKyj5JNkEXh7_UsEQLkuhpfmybht7gDwQR64BQzAXrQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
The close() syscall automatically releases locks. Should it do so atomically or is a delay permitted? I can't find anything in our man pages or the open group specification that says. The distinction matters when using O_NONBLOCK. For example: fd = open(..., O_DIRECT | O_EXLOCK | O_NONBLOCK); //succeeds // do some I/O close(fd); fd = open(..., O_DIRECT | O_EXLOCK | O_NONBLOCK); //fails with EAGAIN! I see this error frequently on a heavily loaded system. It isn't a typical thread race though; ktrace shows that only one thread tries to open the file in question. From the ktrace, I can see that the final open() comes immediately after the close(), with no intervening syscalls from that thread. It seems that close() doesn't release the lock right away. I wouldn't notice if I weren't using O_NONBLOCK. Should this be considered a bug? If so I could try to come up with a minimal test case. But it's somewhat academic, since I plan to refactor the code in a way that will eliminate the duplicate open(). -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jjKyj5JNkEXh7_UsEQLkuhpfmybht7gDwQR64BQzAXrQ>