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

Fixes #14

Merged
merged 6 commits into from
Jun 14, 2024
Merged

Fixes #14

merged 6 commits into from
Jun 14, 2024

Conversation

sosthene-nitrokey
Copy link
Contributor

This imports the fixes from #13 but without the support for interrupts, which is not being used.

  • Reduce duplication by moving the transition method to the channel
  • Fix a race condition in the respond implementation:
    Since the check of State::BuildingResponse == self.channel.state.load(Ordering::Acquire) was distinct from the self.channel.state.store(State::Responded, …), the request could be cancelled while the response was written. 0cd5037 adds the fix and updates tests/loom.rs to trigger this case.
  • It relaxes the ordering of the transition method.
    The first ordering of no operation relies on SeqCst semantics.
    All works with Acquire/Release semantics, so there is no reason to use the SeqCst ordering.
    The second ordering argument is for the failure, in which case we don't read any data,
    and therefore doesn't need any synchronization.

src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated
Comment on lines 169 to 170
// 10 => State::CancelingRequested,
// 11 => State::CancelingBuildingResponse,
Copy link
Member

Choose a reason for hiding this comment

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

These can now be removed too.

Reduce code duplication
The Responder never actually dealt with the intermediary stages of
CancelingRequested and CancelingBuildingResponse, but could still observe them.

Despite that, the loom tests still don't reach any panic
The first ordering of no operation relies on SeqCst semantics.
All works with Acquire/Release semantics, so there is no reason to use the SeqCst ordering.

The second ordering argument is for the failure, in which case we don't read any data,
and therefore don't need any synchronization.
@sosthene-nitrokey sosthene-nitrokey merged commit 379a463 into trussed-dev:main Jun 14, 2024
1 check passed
@robin-nitrokey
Copy link
Member

This does not affect the public API, right?

@sosthene-nitrokey
Copy link
Contributor Author

No, (unless you count doc(hidden) items.

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.

2 participants