Date: Wed, 08 Jan 2020 01:10:19 -0800 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-questions@freebsd.org Subject: Independence of file descriptor flags across forks (or lack thereof) Message-ID: <94417.1578474619@segfault.tristatelogic.com>
next in thread | raw e-mail | index | archive | help
Having recently found a FreeBSD kernel bug that allegedly has sat unnoticed by anyone since circa 2005, I am now emboldened to think that perhaps I may have found yet another subtle kernel bug, or perhaps two, depending on one's point of view. Before I get too cocky however, I would very much appreciate another set of eyes on this, and maybe two or three. The "bug" (or non-feature), as I perceive it, exists in two quite similar flavors, one affecting good old fashioned file descriptions (associated with good old fashioned plain files) and another quite similar issue affecting POSIX message queues, whose interface was modeled after regular file operations. The following two short example programs attempt to illustrate the problem. Checking the independence of file flags (for ordinary files) across forks: https://pastebin.com/raw/AKuWJvyS Checking the independence of file flags (for mssage queues) across forks: https://pastebin.com/raw/AKuWJvyS Quite simply, I started some development work recently with the (apparently naive) belief that when a process forks, and its child process get its own "independent" copy of all of the file descriptors that are currently open in the parent process, the child would also get its own independent copy of the system-maintained "flags word" for each of those inherited file descriptor copies. The above two programs, in particular the first one, appear to disprove this theory, and may perhaps illustrate some deviance from either the letter or the spirit of relevant POSIX standards. (The second one cannot even be executed on unpatched FreeBSD kernels dating from 2005 to the present due to the other kernel bug I found recently, but both can be tried also on Linux, where they both also appear to be to display non-standards-conformant behavior, IMHO.) Very simply these programs open a regular file, or a POSIX message queue, respectively, with the flag O_NONBLOCK set on the open file or message queue. Then fork() is called, and just after that, the child fiddles it's copy of the file flags (by un-setting O_NONBLOCK) and magically, like Werner Heisenberg's famous "spooky action at a distance", the file flags over the parent process also apparently change... rather unexpectedly, at least in the caes of me personally. So dear friends, I must ask you, am I delusional? Is this all just some massive misunderstanding on my part? Is this really the way things are supposed to work, accordiding tp POSIX? Or have I discovered a heretofore unknown "quantum entanglement" of file flag words across process boundaries that actually shouldn't be there? If there is a real bug (or two) here, I'll certainly be filing at least one formal Bugzilla report. Regards, rfg P.S. Just for reference, here's the other kernel bug I just found that is preventing the second example program lined to above from executing very much at all on an unpatched FreeBSD kernel: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243103
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94417.1578474619>