From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11392 invoked from network); 6 Jan 2021 04:04:38 -0000 Received: from mars2.inri.net (HELO 1ess.inri.net) (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 6 Jan 2021 04:04:38 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 1ess; Tue Jan 5 22:06:52 -0500 2021 Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id ea1889d0 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Tue, 5 Jan 2021 19:06:41 -0800 (PST) Message-ID: <3275749BF31AE3D97F768E72DD640E90@eigenstate.org> To: 9front@9front.org, kvik@a-b.xyz Date: Tue, 05 Jan 2021 19:06:39 -0800 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: transactional realtime cloud ActivityPub over SOAP descriptor framework Subject: Re: [9front] Patch to update Go to 1.14.6 (and ca-certificates while here) Reply-To: 9front@9front.org Precedence: bulk Quoth kokamoto@hera.eonet.ne.jp: > go1.15.6 has problem to build, such as src/cmnd/compile/internal/amd64/gsubr.go:34, > while compiling bootstrap. > Has anyone tried it? > > Kenji This version of go currently works for me sufficiently to bootstrap go master: go version go1.14.1 plan9/amd64 I believe I obtained it from ports. However, there's an important fix that I submitted to go which you'll really want in any program that execs commands, if you're running a recent 9front: https://github.com/golang/go/pull/43533 The patch on its own is below: From 18789896e6efa659df589f31c13df1c18f625896 From: Ori Bernstein Date: Wed, 06 Jan 2021 02:12:45 +0000 Subject: [PATCH] syscall/plan9: remove spooky fd action at a distance Change Plan 9 fork/exec to use the O_CLOEXEC file descriptor, instead of relying on spooky at a distance. Historically, Plan 9 has set the O_CLOEXEC flag on the underlying channels in the kernel, rather than the file descriptors -- if two fds pointed at a single channel, as with dup, changing the flags on one of them would be observable on the other. The per-Chan semantics are ok, if unexpected, when a chan is only handled within a single process, but this isn't always the case. Forked processes share Chans, but even more of a problem is the interaction between /srv and OCEXEC, which can lead to unexectedly closed file descriptors in completely unrelated proceses. For example: func exists() bool { // If some other thread execs here, // we don't want to leak the fd, so // open it O_CLOEXEC fd := Open("/srv/foo", O_CLOEXEC) if fd != -1 { Close(fd) return true } return false } would close the connection to any file descriptor (maybe even for the root fs) in ALL other processes that have it open if an exec were to happen(!), which is quite undesriable. As a result, 9front will be changing this behavior for the next release. Go is the only code observed so far that relies on this behavior on purpose, and It's easy to make the code work with both semantics: simply using the file descriptor that was opened with O_CEXEC instead of throwing it away. So we do that here. --- diff 3e1e13ce6d1271f49f3d8ee359689145a6995bad 18789896e6efa659df589f31c13df1c18f625896 --- a/src/syscall/exec_plan9.go Mon Dec 21 15:06:35 2020 +++ b/src/syscall/exec_plan9.go Tue Jan 5 18:12:45 2021 @@ -320,14 +320,15 @@ return e } - fd, e := Open("#d/"+itoa(p[1]), O_CLOEXEC) + fd, e := Open("#d/"+itoa(p[1]), O_RDWR|O_CLOEXEC) if e != nil { Close(p[0]) Close(p[1]) return e } - Close(fd) + Close(p[1]) + p[1] = fd return nil }