Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(subscriber): mitigate race in Callsites::contains #474

Closed
wants to merge 5 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion console-subscriber/src/callsites.rs
Original file line number Diff line number Diff line change
Expand Up @@ -46,8 +46,13 @@ impl<const MAX_CALLSITES: usize> Callsites<MAX_CALLSITES> {
let mut len = self.len.load(Ordering::Acquire);
loop {
for cs in &self.ptrs[start..len] {
if ptr::eq(cs.load(Ordering::Acquire), callsite) {
let recorded = cs.load(Ordering::Acquire);
if ptr::eq(recorded, callsite) {
return true;
} else if ptr::eq(recorded, ptr::null_mut()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style nit, take it or leave it: this could be

Suggested change
} else if ptr::eq(recorded, ptr::null_mut()) {
} else if recorded.is_null() {

// We have read a recorded callsite before it has been
// written. We need to check again.
continue;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, this restarts the whole loop over again. should we, instead, have an inner loop for loading the specific array index until it's no longer null?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hawkw After some thinking (and then forgetting about this), I beleive that this change doesn't make sense.

In fact, I'm not sure that the retry mechanism makes sense in general. If tracing gives the guarantee that Subscriber::register_callsite will be called (and finish!) before Subscriber::event get's called, then the retry shouldn't be necessary at all.

If it doesn't give that guarantee, then the retry is increasing our chances of finding the callsite we are interested in during a race condition, but I don't think that it actually solves the problem either.

For now I'm going to close this PR. After looking at tokio-rs/tracing#2743 a bit more I'll revisit.

}
}

Expand Down