[BPF] Report an warning if certain insn imm operand cannot fit in 32bit #142989
Conversation
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
Contributor
Author
|
cc @jemarch |
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
yonghong-song
force-pushed
the
fix-invalid-insn
branch
2 times, most recently
from
0ba6601 to
17df3a8
Compare
eddyz87
approved these changes
Jun 9, 2025
Contributor
Author
Yes, I do prefer Imm > INT_MAX. But I will emit warning instead of error to maintain some kind of backward compatibility. |
yonghong-song
force-pushed
the
fix-invalid-insn
branch
2 times, most recently
from
474eb57 to
5148d25
Compare
yonghong-song
changed the title
yonghong-song
force-pushed
the
fix-invalid-insn
branch
from
5148d25 to
b51ec73
Compare
eddyz87
reviewed
Jun 10, 2025
Contributor
|
There are quite a few kernel selftests failing to build because of the -Werror: But all seem to be legit warnings for statements like: |
Contributor
Author
Right, this one definitely legit warnings. |
yonghong-song
force-pushed
the
fix-invalid-insn
branch
from
b51ec73 to
4da76a2
Compare
yonghong-song
changed the title
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
Contributor
|
Latest changes lgtm. |
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this pull request
Jun 12, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this pull request
Jun 13, 2025
In one of upstream thread ([1]), there is a discussion about
the below inline asm code:
if r1 == 0xdeadbeef goto +2;
...
In actual llvm backend, the above 0xdeadbeef will actually do
sign extension to 64bit value and then compare to register r1.
But the code itself does not imply the above semantics. It looks
like the comparision is between r1 and 0xdeadbeef. For example,
let us at a simple C code:
$ cat t1.c
int foo(long a) { return a == 0xdeadbeef ? 2 : 3; }
$ clang --target=bpf -O2 -c t1.c && llvm-objdump -d t1.o
...
w0 = 0x2
r2 = 0xdeadbeef ll
if r1 == r2 goto +0x1
w0 = 0x3
exit
It does try to compare r1 and 0xdeadbeef.
To address the above confusing inline asm issue, llvm backend ([2])
added some range checking for such insns and beyond. For the above
insn asm, the warning like below
warning: immediate out of range, shall fit in int range
will be issued. If -Werror is in the compilation flags, the
error will be issued.
To avoid the above warning/error, the afore-mentioned inline asm
should be rewritten to
if r1 == -559038737 goto +2;
...
Fix a few selftest cases like the above based on insn range checking
requirement in [2].
[1] https://lore.kernel.org/bpf/[email protected]/
[2] llvm/llvm-project#142989
Signed-off-by: Yonghong Song <[email protected]>
Ihor Solodrai reported a case ([1]) where gcc reports an error but clang ignores that error and proceeds to generate incorrect code. More specifically, the problematic code looks like: if r1 == 0xcafefeeddeadbeef goto <label> Here, 0xcafefeeddeadbeef needs to be encoded in a 32-bit imm field of the insns and the 32-bit imm allows sign extenstion to 64-bit imm. Obviously, 0xcafefeeddeadbeef cannot encode properly. The compilation failed for gcc with the following error: Error: immediate out of range, shall fit in 32 bits Given a 64-bit imm value, converting to the proper 32-bit imm value must satisfy the following 64-bit patterns: 00000000 00000000 00000000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 11111111 11111111 11111111 11111111 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx So if the top 32-bits is 0 or the top 33-bits is 0x1ffffffff, then the 64-bit imm value can be truncated into proper 32-bit imm. Otherwise, a warning message, the same as gcc will be issued. If -Werror is enabled during compilation, the warning will turn into an error. [1] https://lore.kernel.org/bpf/[email protected]/
yonghong-song
force-pushed
the
fix-invalid-insn
branch
from
4da76a2 to
4110710
Compare
yonghong-song
changed the title
tomtor
pushed a commit
to tomtor/llvm-project
that referenced
this pull request
Jun 14, 2025
…it (llvm#142989) Ihor Solodrai reported a case ([1]) where gcc reports an error but clang ignores that error and proceeds to generate incorrect code. More specifically, the problematic code looks like: if r1 == 0xcafefeeddeadbeef goto <label> Here, 0xcafefeeddeadbeef needs to be encoded in a 32-bit imm field of the insns and the 32-bit imm allows sign extenstion to 64-bit imm. Obviously, 0xcafefeeddeadbeef cannot encode properly. The compilation failed for gcc with the following error: Error: immediate out of range, shall fit in 32 bits Given a 64-bit imm value, converting to the proper 32-bit imm value must satisfy the following 64-bit patterns: 00000000 00000000 00000000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 11111111 11111111 11111111 11111111 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx So if the top 32-bits is 0 or the top 33-bits is 0x1ffffffff, then the 64-bit imm value can be truncated into proper 32-bit imm. Otherwise, a warning message, the same as gcc, will be issued. If -Werror is enabled during compilation, the warning will turn into an error. [1] https://lore.kernel.org/bpf/[email protected]/
akuhlens
pushed a commit
to akuhlens/llvm-project
that referenced
this pull request
Jun 24, 2025
…it (llvm#142989) Ihor Solodrai reported a case ([1]) where gcc reports an error but clang ignores that error and proceeds to generate incorrect code. More specifically, the problematic code looks like: if r1 == 0xcafefeeddeadbeef goto <label> Here, 0xcafefeeddeadbeef needs to be encoded in a 32-bit imm field of the insns and the 32-bit imm allows sign extenstion to 64-bit imm. Obviously, 0xcafefeeddeadbeef cannot encode properly. The compilation failed for gcc with the following error: Error: immediate out of range, shall fit in 32 bits Given a 64-bit imm value, converting to the proper 32-bit imm value must satisfy the following 64-bit patterns: 00000000 00000000 00000000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 11111111 11111111 11111111 11111111 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx So if the top 32-bits is 0 or the top 33-bits is 0x1ffffffff, then the 64-bit imm value can be truncated into proper 32-bit imm. Otherwise, a warning message, the same as gcc, will be issued. If -Werror is enabled during compilation, the warning will turn into an error. [1] https://lore.kernel.org/bpf/[email protected]/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Ihor Solodrai reported a case ([1]) where gcc reports an error but clang
ignores that error and proceeds to generate incorrect code. More
specifically, the problematic code looks like:
Here, 0xcafefeeddeadbeef needs to be encoded in a 32-bit imm field
of the insns and the 32-bit imm allows sign extenstion to 64-bit imm.
Obviously, 0xcafefeeddeadbeef cannot encode properly.
The compilation failed for gcc with the following error:
Given a 64-bit imm value, converting to the proper 32-bit imm value
must satisfy the following 64-bit patterns:
So if the top 32-bits is 0 or the top 33-bits is 0x1ffffffff, then the 64-bit imm
value can be truncated into proper 32-bit imm. Otherwise, a warning
message, the same as gcc, will be issued. If -Werror is enabled during
compilation, the warning will turn into an error.
[1] https://lore.kernel.org/bpf/[email protected]/