From owner-freebsd-questions@freebsd.org Wed Jan 8 09:10:23 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC2B91E82F5 for ; Wed, 8 Jan 2020 09:10:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 47t3PB6xRsz4GDV for ; Wed, 8 Jan 2020 09:10:22 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id D076C4E727; Wed, 8 Jan 2020 01:10:19 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: Independence of file descriptor flags across forks (or lack thereof) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94416.1578474619.1@segfault.tristatelogic.com> Date: Wed, 08 Jan 2020 01:10:19 -0800 Message-ID: <94417.1578474619@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 47t3PB6xRsz4GDV X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-5.36 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; IP_SCORE(-3.06)[ip: (-8.03), ipnet: 69.62.128.0/17(-4.01), asn: 14051(-3.19), country: US(-0.05)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:10:24 -0000 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