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

Miscellaneous fixes to allow running integration tests in bpf-linker #641

Merged
merged 7 commits into from
Jul 10, 2023

Conversation

tamird
Copy link
Member

@tamird tamird commented Jul 9, 2023

See individual commits and aya-rs/bpf-linker#69.

@netlify
Copy link

netlify bot commented Jul 9, 2023

Deploy Preview for aya-rs-docs ready!

Name Link
🔨 Latest commit b8252f4
🔍 Latest deploy log https://app.netlify.com/sites/aya-rs-docs/deploys/64ac69048267c1000899b6b8
😎 Deploy Preview https://deploy-preview-641--aya-rs-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@tamird tamird force-pushed the logger-messages-plz branch 3 times, most recently from ca4fa44 to 620b2c8 Compare July 9, 2023 23:49
@tamird tamird requested a review from alessandrod July 9, 2023 23:50
@tamird tamird marked this pull request as ready for review July 9, 2023 23:50
@tamird
Copy link
Member Author

tamird commented Jul 9, 2023

cc @ajwerner

Copy link
Member

@ajwerner ajwerner left a comment

Choose a reason for hiding this comment

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

LGTM

@tamird tamird force-pushed the logger-messages-plz branch from 620b2c8 to c883935 Compare July 10, 2023 13:59
@tamird tamird force-pushed the logger-messages-plz branch 2 times, most recently from 580e6d8 to 5a2d1fa Compare July 10, 2023 14:55
Copy link
Member

@ajwerner ajwerner left a comment

Choose a reason for hiding this comment

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

:lgtm:

Reviewed 16 of 29 files at r4, all commit messages.
Reviewable status: 16 of 30 files reviewed, all discussions resolved (waiting on @alessandrod)

xtask/src/build_ebpf.rs Outdated Show resolved Hide resolved
xtask/src/build_ebpf.rs Outdated Show resolved Hide resolved
xtask/src/build_ebpf.rs Outdated Show resolved Hide resolved
xtask/src/build_test.rs Outdated Show resolved Hide resolved
xtask/src/docs/mod.rs Outdated Show resolved Hide resolved
xtask/src/docs/mod.rs Outdated Show resolved Hide resolved
test/integration-test/tests/smoke.rs Show resolved Hide resolved
@tamird tamird force-pushed the logger-messages-plz branch from 5a2d1fa to 7d50085 Compare July 10, 2023 18:18
@dave-tucker dave-tucker self-requested a review July 10, 2023 18:25
Copy link
Member

@dave-tucker dave-tucker left a comment

Choose a reason for hiding this comment

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

Some things to clarify here before merge

aya/Cargo.toml Outdated
tokio = { version = "1.24.0", features = ["macros", "rt", "rt-multi-thread", "net"], optional = true }
async-io = { version = "1.3", optional = true }
log = "0.4"
procfs = "0.15.1"
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
procfs = "0.15.1"
procfs = { version: "0.15.1", default-features = false }

This avoids pulling in chrono as a dep.

Also how well maintained is this crate? and why should we switch from what we have.
Adding this to the commit message would be awesome.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done. Looks pretty active to me.

@@ -575,10 +575,14 @@ fn load_program<T: Link>(

let target_kernel_version = match *kernel_version {
KernelVersion::Any => {
let (major, minor, patch) = crate::sys::kernel_version().unwrap();
(major << 16) + (minor << 8) + patch
let procfs::KernelVersion {
Copy link
Member

Choose a reason for hiding this comment

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

It's a bit gross having an aya KernelVersion and procfs::KernelVersion here.
Do we need both still?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, replaced the aya KernelVersion with Option

@@ -3,6 +3,8 @@

use aya_bpf::{bindings::xdp_action, macros::xdp, programs::XdpContext};

// Note: the `frags` attribute causes this probe to be incompatible with kernel versions < 5.18.0.
Copy link
Member

Choose a reason for hiding this comment

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

This is a bug.
This test should pass on older kernels too - we shouldn't set the flag for frags supported if isn't supported by the target kernel.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, please fix in another PR.

@@ -168,8 +168,8 @@ fn pin_link() {
#[test]
fn pin_lifecycle() {
let kernel_version = KernelVersion::current().unwrap();
if kernel_version < KernelVersion::new(5, 9, 0) {
eprintln!("skipping test on kernel {kernel_version:?}, XDP uses netlink");
if kernel_version < KernelVersion::new(5, 18, 0) {
Copy link
Member

Choose a reason for hiding this comment

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

This test has nothing to do with those flags - it's just an unfortunate property of sharing the same bytecode

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I realize, but I chose not to fix this here. Please fix it in another PR.

@@ -8,6 +8,12 @@ use aya::{

#[test]
fn xdp() {
let kernel_version = KernelVersion::current().unwrap();
if kernel_version < KernelVersion::new(5, 18, 0) {
eprintln!("skipping test on kernel {kernel_version:?}, support for BPF_F_XDP_HAS_FRAGS was added in 5.18.0; see https://github.com/torvalds/linux/commit/c2f2cdb");
Copy link
Member

Choose a reason for hiding this comment

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

As above ☝️

Copy link
Member Author

Choose a reason for hiding this comment

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

Indeed.

aya/src/bpf.rs Outdated
let ret = retry_with_verifier_logs(10, &mut logger, |logger| {
bpf_load_btf(raw_btf.as_slice(), logger)
let (ret, verifier_log) = retry_with_verifier_logs(10, |logger| {
bpf_load_btf(raw_btf.as_slice(), logger, VerifierLogLevel::default())
Copy link
Member

Choose a reason for hiding this comment

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

This should come from the BpfLoader instance, assuming default() here would override someone who's explicitly disabled verifier logs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, done.

@@ -474,7 +475,7 @@ impl<T: Link> ProgramData<T> {
attach_btf_id,
attach_prog_fd: None,
btf_fd: None,
verifier_log_level: 0,
verifier_log_level: VerifierLogLevel::default(),
Copy link
Member

Choose a reason for hiding this comment

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

This should come from the BpfLoader instance, assuming default() here would override someone who's explicitly disabled verifier logs.

Copy link
Member Author

Choose a reason for hiding this comment

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

There's no BpfLoader in hand here. Where do you suggest I get one?

Copy link
Member

@dave-tucker dave-tucker Jul 10, 2023

Choose a reason for hiding this comment

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

I would suggest plumbing in the verifier_log_level: VerifierLogLevel as an argument to this function...
If BpfLoader is never available in the call stack, then setting the log level should probably be part of the public API.

The option that's less work is to keep the existing behaviour and use VerifierLogLevel::None

Copy link
Member Author

Choose a reason for hiding this comment

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

Plumbed it all the way to from_pin, which is a public API. There's no loader object in sight.

Would you like me to break the public API?

Copy link
Member

Choose a reason for hiding this comment

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

Ah okay, no need to expose that in from_pin, You can safely use VerifierLogLevel::None then, not default().
Programs are already loaded to the kernel so you won't get any verifier logs loading from pin in this case.

Copy link
Member Author

Choose a reason for hiding this comment

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

If it's all the same to you, I'd rather leave default here. If there aren't verifier logs to be had, then it doesn't matter. Agreed?

tamird added 3 commits July 10, 2023 15:25
This allows the logic to be shared between aya and the integration tests
without exposing additional public API surface.
Don't run `cargo build --verbose`; it's too noisy.
This type is really only used by one function.
@tamird tamird force-pushed the logger-messages-plz branch from 7d50085 to cd15fbd Compare July 10, 2023 19:26
@tamird tamird force-pushed the logger-messages-plz branch 2 times, most recently from b1bb810 to b8252f4 Compare July 10, 2023 20:24
Copy link
Member

@dave-tucker dave-tucker left a comment

Choose a reason for hiding this comment

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

LGTM

@tamird tamird merged commit 4c0983b into main Jul 10, 2023
@tamird tamird deleted the logger-messages-plz branch July 10, 2023 21:22
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.

4 participants