9front - general discussion about 9front
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9front@9front.org, kvik@a-b.xyz
Subject: Re: [9front] Patch to update Go to 1.14.6 (and ca-certificates while here)
Date: Tue, 05 Jan 2021 19:06:39 -0800	[thread overview]
Message-ID: <3275749BF31AE3D97F768E72DD640E90@eigenstate.org> (raw)
In-Reply-To: <B3B6856BB102887BDCA9E7B15167320E@hera.eonet.ne.jp>

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 <ori@eigenstate.org>
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
 }

  parent reply	other threads:[~2021-01-06  4:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-06 14:02 kokamoto
2021-01-06  0:59 ` kylejnusbaum
2021-01-06  5:10   ` kokamoto
2021-01-06  1:37 ` sl
2021-01-06  3:06   ` kokamoto
2021-01-06 20:45     ` kylejnusbaum
2021-01-09 19:02       ` Philip Silva
2021-01-09 23:24         ` kokamoto
2021-01-10 20:33           ` Philip Silva
2021-01-06  3:06 ` ori [this message]
2021-01-06  3:57   ` kokamoto
  -- strict thread matches above, loose matches on Subject: below --
2020-08-06 13:39 Aaron Bieber
2020-08-06 14:02 ` [9front] " kvik
2020-08-06 15:00 ` kvik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3275749BF31AE3D97F768E72DD640E90@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9front@9front.org \
    --cc=kvik@a-b.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).