Re: Is -fsanitize=address working?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The combination of an open fd with CLOFORK set, and clone (which is
> just another fancy way of saying fork()) and CLONE_FILES set really
> makes no sense,

Indeed.  This is a collision among three things: (1) tzcode's use of
CLOFORK, (2) assorted programs which expect clone(CLONE_FILES) to work,
and (3) NetBSD's noticing the nonsensicality of that combination and
erroring for it.

(2) isn't likely to change.  Even if it does, NetBSD decreeing that the
use of clone(CLONE_FILES) and timezone code in the same process won't
work is...not going to be popular, I suspect.

Rolling back (3) isn't going to help anything; because the semantics
are incompatible at the conceptual level, this means breaking at least
one of the other two.

And changing (1) would mean backing off from a conceptually useful
thing, would mean introducing (additional?) changes when bringing in
new upstream code, and wouldn't actually fix anything; tzcode is not
going to be the last library using CLOEXEC for internal fds.

So what to do?

I think the best option is a variant of (3): respec CLOFORK.  I can
think of four plausible respecs: (a) CLOFORK applies to fork(), not
clone(); (b) CLOFORK applies to both fork() and clone(), but to clone()
only when CLONE_FILES is not specified, that is, it applies when a new
open file table is created, not when a new process is created; (c)
clone with CLONE_FILES requires specifying (presumably via further flag
bits) whether CLOFORK is to take effect, be ignored, or produce errors;
and (d) close any CLOFORK fd(s), but keep others, and ensure that any
future fd-affepcting calls operate on both open file tables.

(d) is only superficially plausible.  It strikes me as hellish to
implement; furthermore, it runs into problems with fd selection
semantics.  If the process in which the fd is closed opens a
descriptor, and the lowest-numbered closed descriptor is the
CLOFORK-closed one, the usual semantics call for that one to be used,
but it then can't be shared into the other open file table.

(c) renders NetBSD's clone() incompatible; it also calls on applicatino
authors to guess what libraries using CLOFORK actually want.

(a) is problematic for applications that want to use clone() for one of
the other ways it differs from fork() but want fork()-like open file
table semantics.

I think (b) is, overall, the best choice: redescribe CLOFORK as kicking
in only when a new open file table is being created, rather than when a
new process is being created.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4Bä