Commit 68625b76 authored by Wang YanQing's avatar Wang YanQing Committed by Daniel Borkmann

bpf, doc: clarification for the meaning of 'id'

For me, as a reader whose mother language isn't English, the
old words bring a little difficulty to catch the meaning, this
patch rewords the subsection in a more clarificatory way.

This patch also add blank lines as separator at two places
to improve readability.
Signed-off-by: default avatarWang YanQing <udknight@gmail.com>
Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
parent 96112e93
...@@ -1142,6 +1142,7 @@ into a register from memory, the register's top 56 bits are known zero, while ...@@ -1142,6 +1142,7 @@ into a register from memory, the register's top 56 bits are known zero, while
the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we
then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0; then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0;
0x1ff), because of potential carries. 0x1ff), because of potential carries.
Besides arithmetic, the register state can also be updated by conditional Besides arithmetic, the register state can also be updated by conditional
branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false' it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false'
...@@ -1150,14 +1151,16 @@ BPF_JSGE) would instead update the signed minimum/maximum values. Information ...@@ -1150,14 +1151,16 @@ BPF_JSGE) would instead update the signed minimum/maximum values. Information
from the signed and unsigned bounds can be combined; for instance if a value is from the signed and unsigned bounds can be combined; for instance if a value is
first tested < 8 and then tested s> 4, the verifier will conclude that the value first tested < 8 and then tested s> 4, the verifier will conclude that the value
is also > 4 and s< 8, since the bounds prevent crossing the sign boundary. is also > 4 and s< 8, since the bounds prevent crossing the sign boundary.
PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all
pointers sharing that same variable offset. This is important for packet range pointers sharing that same variable offset. This is important for packet range
checks: after adding some variable to a packet pointer, if you then copy it to checks: after adding a variable to a packet pointer register A, if you then copy
another register and (say) add a constant 4, both registers will share the same it to another register B and then add a constant 4 to A, both registers will
'id' but one will have a fixed offset of +4. Then if it is bounds-checked and share the same 'id' but the A will have a fixed offset of +4. Then if A is
found to be less than a PTR_TO_PACKET_END, the other register is now known to bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is
have a safe range of at least 4 bytes. See 'Direct packet access', below, for now known to have a safe range of at least 4 bytes. See 'Direct packet access',
more on PTR_TO_PACKET ranges. below, for more on PTR_TO_PACKET ranges.
The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of
the pointer returned from a map lookup. This means that when one copy is the pointer returned from a map lookup. This means that when one copy is
checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs. checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment