-
Notifications
You must be signed in to change notification settings - Fork 4
branch_worker: PR comments pre-processing #29
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
Merged
theihor
merged 1 commit into
kernel-patches:main
from
theihor:pr-comments-preprocessing
Oct 30, 2025
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -68,4 +68,3 @@ project-excludes = [ | |
| "**/__pycache__", | ||
| "**/*venv/**/*", | ||
| ] | ||
|
|
||
57 changes: 57 additions & 0 deletions
57
tests/data/test_ai_review_comment_preprocessor/comment-body.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
|
|
||
|
|
||
| ``` | ||
| commit 16cbc4520eb13d2065d145c76b97fb93035d81e8 | ||
| Author: KaFai Wan <[email protected]> | ||
|
|
||
| bpf: Fix tnum_overlap to check for zero mask intersection | ||
|
|
||
| This patch adds an early return check in tnum_overlap() to detect | ||
| non-overlapping tnums when their masks have no overlapping bits. The | ||
| fix addresses a syzbot report where the verifier failed to recognize | ||
| that two tnums couldn't represent the same value. | ||
|
|
||
| Reported-by: [email protected] | ||
|
|
||
| > diff --git a/kernel/bpf/tnum.c b/kernel/bpf/tnum.c | ||
| > index f8e70e9c3..1a75b7c9a 100644 | ||
| > --- a/kernel/bpf/tnum.c | ||
| > +++ b/kernel/bpf/tnum.c | ||
| > @@ -163,6 +163,8 @@ bool tnum_overlap(struct tnum a, struct tnum b) | ||
| > { | ||
| > u64 mu; | ||
| > | ||
| > + if (a.mask && b.mask && !(a.mask & b.mask)) | ||
| > + return false; | ||
| ^^^^^ | ||
|
|
||
| Does this logic correctly detect non-overlapping tnums? Consider this | ||
| counter-example: | ||
|
|
||
| a = (value=0x5, mask=0xA) // binary: value=0101, mask=1010 | ||
| b = (value=0xA, mask=0x5) // binary: value=1010, mask=0101 | ||
|
|
||
| The masks are disjoint: (0xA & 0x5) == 0, so the new check returns | ||
| false (no overlap). | ||
|
|
||
| However, these tnums actually represent overlapping sets: | ||
| a represents: {5, 7, 13, 15} // 0b0101, 0b0111, 0b1101, 0b1111 | ||
| b represents: {10, 11, 14, 15} // 0b1010, 0b1011, 0b1110, 0b1111 | ||
|
|
||
| Both sets contain 15, so they do overlap. Can this cause incorrect | ||
| verifier behavior when is_branch_taken() calls tnum_overlap() to | ||
| determine if JEQ/JNE branches are reachable? | ||
|
|
||
| > mu = ~a.mask & ~b.mask; | ||
| > return (a.value & mu) == (b.value & mu); | ||
| > } | ||
|
|
||
|
|
||
| ``` | ||
|
|
||
| --- | ||
| AI reviewed your patch. Please fix the bug or email reply why it's not a bug. | ||
| See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md | ||
|
|
||
| In-Reply-To-Subject: `bpf: Fix tnum_overlap to check for zero mask intersection` | ||
| CI run summary: https://github.com/kernel-patches/bpf/actions/runs/18880108453 |
39 changes: 39 additions & 0 deletions
39
tests/data/test_ai_review_comment_preprocessor/expected-email-body.txt
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| > diff --git a/kernel/bpf/tnum.c b/kernel/bpf/tnum.c | ||
| > index f8e70e9c3..1a75b7c9a 100644 | ||
| > --- a/kernel/bpf/tnum.c | ||
| > +++ b/kernel/bpf/tnum.c | ||
| > @@ -163,6 +163,8 @@ bool tnum_overlap(struct tnum a, struct tnum b) | ||
| > { | ||
| > u64 mu; | ||
| > | ||
| > + if (a.mask && b.mask && !(a.mask & b.mask)) | ||
| > + return false; | ||
| ^^^^^ | ||
|
|
||
| Does this logic correctly detect non-overlapping tnums? Consider this | ||
| counter-example: | ||
|
|
||
| a = (value=0x5, mask=0xA) // binary: value=0101, mask=1010 | ||
| b = (value=0xA, mask=0x5) // binary: value=1010, mask=0101 | ||
|
|
||
| The masks are disjoint: (0xA & 0x5) == 0, so the new check returns | ||
| false (no overlap). | ||
|
|
||
| However, these tnums actually represent overlapping sets: | ||
| a represents: {5, 7, 13, 15} // 0b0101, 0b0111, 0b1101, 0b1111 | ||
| b represents: {10, 11, 14, 15} // 0b1010, 0b1011, 0b1110, 0b1111 | ||
|
|
||
| Both sets contain 15, so they do overlap. Can this cause incorrect | ||
| verifier behavior when is_branch_taken() calls tnum_overlap() to | ||
| determine if JEQ/JNE branches are reachable? | ||
|
|
||
| > mu = ~a.mask & ~b.mask; | ||
| > return (a.value & mu) == (b.value & mu); | ||
| > } | ||
|
|
||
|
|
||
| --- | ||
| AI reviewed your patch. Please fix the bug or email reply why it's not a bug. | ||
| See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md | ||
|
|
||
| CI run summary: https://github.com/kernel-patches/bpf/actions/runs/18880108453 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Should this be a warning? For
is not Nonecase.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.
I don't think error logging is necessary here.
If pre-processing isn't working it'll be immediately noticeable in the emails.