runtime: publish netpoll info after incrementing fdseq

I think there is a theoretical possibility of a mistake before this CL.
pollCache.free would increment fdseq, but would not update atomicInfo.
The epoll code could compare to fdseq before the increment, but suspend
before calling setEventErr. The pollCache could get reallocated,
and pollOpen could clear eventErr. Then the setEventErr could continue
and set it again. Then pollOpen could call publishInfo.

Avoid this rather remote possibility by calling publishInfo after
incrementing fdseq. That ensures that delayed setEventErr will not
modify the eventErr flag.

Fixes #60133

Change-Id: I69e336535312544690821c9fd53f3023ff15b80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>

diff --git a/src/runtime/netpoll.go b/src/runtime/netpoll.go
index b1b3766e11b2ce47a0e4ec09733653eff6ac85a8..a2b0be22611404f38f450f67000f10ab36885a9b 100644 (file)
--- a/src/runtime/netpoll.go
+++ b/src/runtime/netpoll.go
@@ -287,12 +287,20 @@ func poll_runtime_pollClose(pd *pollDesc) {
 }
 
 func (c *pollCache) free(pd *pollDesc) {
+       // pd can't be shared here, but lock anyhow because
+       // that's what publishInfo documents.
+       lock(&pd.lock)
+
        // Increment the fdseq field, so that any currently
        // running netpoll calls will not mark pd as ready.
        fdseq := pd.fdseq.Load()
        fdseq = (fdseq + 1) & (1<<taggedPointerBits - 1)
        pd.fdseq.Store(fdseq)
 
+       pd.publishInfo()
+
+       unlock(&pd.lock)
+
        lock(&c.lock)
        pd.link = c.first
        c.first = pd