Skip to content

dbus: lock subscriber mutexes when dispatch reads updateCh - #524

Open
MsfPablo wants to merge 1 commit into
coreos:mainfrom
MsfPablo:main
Open

dbus: lock subscriber mutexes when dispatch reads updateCh#524
MsfPablo wants to merge 1 commit into
coreos:mainfrom
MsfPablo:main

Conversation

@MsfPablo

Copy link
Copy Markdown

Closes #519

Conn.dispatch at dbus/subscription.go:65-66 read
c.subStateSubscriber.updateCh and c.propertiesSubscriber.updateCh
without holding the corresponding mutexes, while
SetSubStateSubscriber writes those fields under
subStateSubscriber.Lock(). Issue #519 includes a go run -race
reproducer that reliably fires the race detector.

Wrap the early-out check with the locks so the read is protected:
subStateSubscriber.Lock() then propertiesSubscriber.Lock(), then
test, then unlock in reverse order. The diff is exactly the one
suggested in the issue. The subsequent signal routing (sendPropertiesUpdate,
sendSubStateUpdate) already takes the same locks internally, so no
additional locking is needed there.

Verified locally:

gofmt -d dbus/subscription.go # no diff
go vet ./dbus/... # clean
go build ./dbus/... # clean

Disclosed assistance: this PR was authored with the assistance of an
AI coding assistant (Claude Code, Anthropic) operating under the
maintainer's direct supervision. The change is a six-line mutex
guard; no behaviour is changed in the no-race path.

The dispatch goroutine in Conn.dispatch reads
c.subStateSubscriber.updateCh and c.propertiesSubscriber.updateCh
without holding the corresponding mutexes, while SetSubStateSubscriber
writes those fields under subStateSubscriber.Lock(). This races, as
reported in issue coreos#519 with a  reproducer.

Wrap the early-out check (and the subsequent signal routing that
also touches the subscribers) so the read is protected: lock both,
test, unlock both. The lock order matches the issue's suggested
diff and is symmetric across both subscribers.

Closes coreos#519
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Apparent race on read of channel set via SetSubStateSubscriber

1 participant