-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Issue #22527 - bpf_lxc.c: do drop notifications at drop source #25426
Conversation
d67df8a
to
9803ee0
Compare
ced942a
to
9cf0d0d
Compare
f6bc34a
to
fedc8fe
Compare
fedc8fe
to
a5c311c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this! 🚀
I've left a few inline comments below. I also have a few global comments:
- The context that you gave in the pull request description should be in the commit message.
- For the commit title, we usually follow the format of
bpf: [Description]
. I think a good title would bebpf: Fix missing drop notifications on ct lookup failures
. - I usually try to avoid referencing GitHub issues in git commits because it creates a lot of noise on the target issue. Not everyone does the same though, so I'm fine either way 🙂
- I've added a release note given this is a bug and will appear as such in the release notes.
26999a4
to
062c4ef
Compare
Thanks, but I'd actually avoid doing that unless there are conflicts or it fixes some of the CI flakes. Every time we rebase the PR, we'll have to rerun tests from scratch and one of them takes up to 3h 😬 😅 |
/test |
Thanks a lot for the contribution @bleggett! |
Fixes: #22527
#22527 points out that there may be some corner cases where packet drops are not properly logged.
This is largely possible because a macro-defined func is reused in several places, and
send_drop_notify
is assumed to be deferred up the chain - but not all parents would actually invoke it, and by definition it seems clearer/less error prone to always explicitly issue drop notification at the source, where the drop is decided.This is a smidge more verbose, but it avoids the problem of bad assumptions or hard-to-catch mistakes causing missing drop notifications.
Additionally - I might be missing something - but I couldn't see that the macro expansions ofwas missing somethingtail_ipv4_ct_ingress
/tail_ipv6_ct_ingress
actually ever get invoked? Am I missing something there?(I couldn't find any formal C style guidelines declared for this repo, so if I'm violating some understood assumption or doing something very dumb, please comment)