Skip to content

Add more assertions #5245

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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

ShadowCurse
Copy link
Contributor

@ShadowCurse ShadowCurse commented Jun 3, 2025

Changes

Add asserts in places where we have strong assumptions about inner workings of the code.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

  • I have read and understand CONTRIBUTING.md.
  • I have run tools/devtool checkstyle to verify that the PR passes the
    automated style checks.
  • I have described what is done in these changes, why they are needed, and
    how they are solving the problem in a clear and encompassing way.
  • I have updated any relevant documentation (both in code and in the docs)
    in the PR.
  • I have mentioned all user-facing changes in CHANGELOG.md.
  • If a specific issue led to this PR, this PR closes the issue.
  • When making API changes, I have followed the
    Runbook for Firecracker API changes.
  • I have tested all new and changed functionalities in unit tests and/or
    integration tests.
  • I have linked an issue to every new TODO.

  • This functionality cannot be added in rust-vmm.

Copy link

codecov bot commented Jun 3, 2025

Codecov Report

Attention: Patch coverage is 94.11765% with 2 lines in your changes missing coverage. Please review.

Project coverage is 82.90%. Comparing base (0fd78cf) to head (477677b).

Files with missing lines Patch % Lines
src/vmm/src/persist.rs 33.33% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5245      +/-   ##
==========================================
+ Coverage   82.86%   82.90%   +0.04%     
==========================================
  Files         250      250              
  Lines       26897    26868      -29     
==========================================
- Hits        22288    22276      -12     
+ Misses       4609     4592      -17     
Flag Coverage Δ
5.10-c5n.metal 83.34% <100.00%> (-0.02%) ⬇️
5.10-m5n.metal 83.33% <100.00%> (-0.01%) ⬇️
5.10-m6a.metal 82.55% <100.00%> (-0.02%) ⬇️
5.10-m6g.metal 79.16% <94.11%> (-0.02%) ⬇️
5.10-m6i.metal 83.34% <100.00%> (-0.01%) ⬇️
5.10-m7a.metal-48xl 82.54% <100.00%> (?)
5.10-m7g.metal 79.16% <94.11%> (-0.02%) ⬇️
5.10-m7i.metal-24xl 83.29% <100.00%> (?)
5.10-m7i.metal-48xl 83.29% <100.00%> (?)
5.10-m8g.metal-24xl 79.15% <94.11%> (?)
5.10-m8g.metal-48xl 79.15% <94.11%> (?)
6.1-c5n.metal 83.39% <100.00%> (-0.02%) ⬇️
6.1-m5n.metal 83.39% <100.00%> (?)
6.1-m6a.metal 82.59% <100.00%> (-0.02%) ⬇️
6.1-m6g.metal 79.16% <94.11%> (-0.02%) ⬇️
6.1-m6i.metal 83.37% <100.00%> (-0.03%) ⬇️
6.1-m7a.metal-48xl 82.59% <100.00%> (?)
6.1-m7g.metal 79.16% <94.11%> (-0.02%) ⬇️
6.1-m7i.metal-24xl 83.40% <100.00%> (?)
6.1-m7i.metal-48xl 83.39% <100.00%> (?)
6.1-m8g.metal-24xl 79.15% <94.11%> (?)
6.1-m8g.metal-48xl 79.15% <94.11%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 20 times, most recently from 70239eb to ed878a1 Compare June 11, 2025 10:32
@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 4 times, most recently from 169752b to b7d4bb8 Compare June 25, 2025 11:08
@ShadowCurse ShadowCurse changed the title Misc fixes Add more assertions Jun 25, 2025
@ShadowCurse ShadowCurse marked this pull request as ready for review June 25, 2025 11:26
@ShadowCurse ShadowCurse self-assigned this Jun 25, 2025
@ShadowCurse ShadowCurse added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label Jun 25, 2025
@ShadowCurse ShadowCurse added the Type: Enhancement Indicates new feature requests label Jun 25, 2025
roypat
roypat previously approved these changes Jun 25, 2025
roypat
roypat previously approved these changes Jun 26, 2025
@roypat roypat enabled auto-merge (rebase) June 26, 2025 10:02
Comment on lines 609 to 610
#[cfg(not(test))]
assert!(std::ptr::eq(_vcpu_ptr, self));
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is one of those cases where having a separate function return a result and then the caller decide what to do with it is better than having a assert that depends on whether we're testing or not, as it makes the code actually testable without hacks like this.

All this change would be is unwrap the result of self.reset_thread_local_data()

Copy link
Contributor

Choose a reason for hiding this comment

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

On the other hand, why do we have a test that fails this assertion? Been a while since I looked at this PR, but maybe we should fix that test to actually set things up the same way we do in prod?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added another commit which drops the VcpuDrop

Copy link
Contributor

Choose a reason for hiding this comment

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

personally, a huge fan. Thanks!

assert!(cell.get().is_none());
cell.set(Some(self as *mut Vcpu));
})
}

/// Runs `func` for the `Vcpu` associated with the current thread.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this change is really subjective. I see no issues with the current state and I actually prefer that. What is the benefit of doing like so?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was used only once, so inlining it made sense. It also makes code a bit shorter.

@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 2 times, most recently from e2ba5a2 to fc8f40b Compare July 3, 2025 15:14
It is reasonable to assume that we will not have more than u32::MAX
memory slots since kernel only returns i32 from a query syscall.
Enforce this with `.expect` calls and change the type of `max_memslots`
to u32.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Replaces never used error result type wit optional.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Vcpu TLS must only be initialized once.
Enforce this with an assertion.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Move setting of signal handler into vcpu init to
prevent race condition between setting TLS and signal handler
using TLS.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
- The reset must be called only once on vcpu drop, so move it
directly into the Drop impl.
- Replace errors with asserts since there is an assumption that TLS
will always hold correct vcpu pointer for a given thread (except in
tests).

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Merge run_on_thread_local into signal handler since it is
only used there.
The error returned from run_on_thread_local was ignored, so
instead replace it with logic to only use vcpu ptr if
TLS is initialized, without returning any errors.
The reason for not asserting on TLS being initialized here
is that during Firecracker shutdown, vcpus will be destroyed
and TLS will be reset. If signal will be send to Firecracker
during that time, the TLS accessed from a signal handler will
be empty. But this is expected, so no assertions/panics are needed.

Because Rust is a good language, it does not allow to reference
TLS_VCPU_PTR definded inside impl block inside the signal_handler
function. So move the TLS_VCPU_PTR definition outside the Vcpu impl
block.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
@ShadowCurse ShadowCurse force-pushed the misc_fixes branch 2 times, most recently from 84032e5 to b32041a Compare July 3, 2025 15:33
Instead of storing the pointer to the Vcpu in the TLS,
store the mmapped `kvm_run` struct instead. This way the Drop
implementation for Vcpu is no longer required, since the
mmapped `kvm_run` will remain valid until TLS is destroyed by
the thread Drop impl.
This also removes `unsafe` code from the implementation.

Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting review Indicates that a pull request is ready to be reviewed Type: Enhancement Indicates new feature requests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants