[Bug 215011] kqueue: notification race condition between open and kqueue

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Dec 2 17:54:18 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215011

            Bug ID: 215011
           Summary: kqueue: notification race condition between open and
                    kqueue
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: myron.walker at emc.com

There is a race condition that must be worked around by everyone using
kqueue(s) to monitor files for changes.  The race condition is.

1. open file and get fd
2. create kqueue to listen for events like (rename, delete, etc.)
3. go to sleep and wait for changes

The problem is that if the file is deleted or renamed in between the call to
open
and before the kqueue is setup to monitor the file, you will not receive any
notification

In order to work around this people do:

1. create/open file
2. check stat and path of file
3. create kqueue to listen for events
4. check stat and path of file again and make sure nothing changed
5. go to sleep and wait for changes.

It would be useful if there was a kqueue API for opening a file that would
eliminate the race condition between opening a file and setting up monitoring
an API that combines the parameters of open and kqueue so that the file
descriptor returned and the kqueue monitoring setup will be atomic.  Maybe a
'kopen' api or something like that.

This would raise awareness of the race condition and provide a standard way of
navigating around it that can be stabalized and utilized throughout code to
provide support for a much more robust platform.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list