<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/tools/testing/selftests/bpf/progs, branch linux-5.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.7.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.7.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-06-30T19:35:51Z</updated>
<entry>
<title>bpf: tcp: bpf_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT</title>
<updated>2020-06-30T19:35:51Z</updated>
<author>
<name>Neal Cardwell</name>
</author>
<published>2020-06-24T16:42:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=75cbd58101db3f850caf5637357067b174117a37'/>
<id>urn:sha1:75cbd58101db3f850caf5637357067b174117a37</id>
<content type='text'>
[ Upstream commit 7d21d54d624777358ab6c7be7ff778808fef70ba ]

Apply the fix from:
 "tcp_cubic: fix spurious HYSTART_DELAY exit upon drop in min RTT"
to the BPF implementation of TCP CUBIC congestion control.

Repeating the commit description here for completeness:

Mirja Kuehlewind reported a bug in Linux TCP CUBIC Hystart, where
Hystart HYSTART_DELAY mechanism can exit Slow Start spuriously on an
ACK when the minimum rtt of a connection goes down. From inspection it
is clear from the existing code that this could happen in an example
like the following:

o The first 8 RTT samples in a round trip are 150ms, resulting in a
  curr_rtt of 150ms and a delay_min of 150ms.

o The 9th RTT sample is 100ms. The curr_rtt does not change after the
  first 8 samples, so curr_rtt remains 150ms. But delay_min can be
  lowered at any time, so delay_min falls to 100ms. The code executes
  the HYSTART_DELAY comparison between curr_rtt of 150ms and delay_min
  of 100ms, and the curr_rtt is declared far enough above delay_min to
  force a (spurious) exit of Slow start.

The fix here is simple: allow every RTT sample in a round trip to
lower the curr_rtt.

Fixes: 6de4a9c430b5 ("bpf: tcp: Add bpf_cubic example")
Reported-by: Mirja Kuehlewind &lt;mirja.kuehlewind@ericsson.com&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Soheil Hassas Yeganeh &lt;soheil@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libbpf: Support pre-initializing .bss global variables</title>
<updated>2020-06-24T15:49:11Z</updated>
<author>
<name>Andrii Nakryiko</name>
</author>
<published>2020-06-12T19:45:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=845357b602f6f2e0e3b47425e8764947460c7aa2'/>
<id>urn:sha1:845357b602f6f2e0e3b47425e8764947460c7aa2</id>
<content type='text'>
[ Upstream commit caf62492f479585296e9d636c798d5ac256b7b04 ]

Remove invalid assumption in libbpf that .bss map doesn't have to be updated
in kernel. With addition of skeleton and memory-mapped initialization image,
.bss doesn't have to be all zeroes when BPF map is created, because user-code
might have initialized those variables from user-space.

Fixes: eba9c5f498a1 ("libbpf: Refactor global data map initialization")
Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200612194504.557844-1-andriin@fb.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpf: Prevent mmap()'ing read-only maps as writable</title>
<updated>2020-05-21T03:21:53Z</updated>
<author>
<name>Andrii Nakryiko</name>
</author>
<published>2020-05-19T05:38:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dfeb376dd4cb2c5004aeb625e2475f58a5ff2ea7'/>
<id>urn:sha1:dfeb376dd4cb2c5004aeb625e2475f58a5ff2ea7</id>
<content type='text'>
As discussed in [0], it's dangerous to allow mapping BPF map, that's meant to
be frozen and is read-only on BPF program side, because that allows user-space
to actually store a writable view to the page even after it is frozen. This is
exacerbated by BPF verifier making a strong assumption that contents of such
frozen map will remain unchanged. To prevent this, disallow mapping
BPF_F_RDONLY_PROG mmap()'able BPF maps as writable, ever.

  [0] https://lore.kernel.org/bpf/CAEf4BzYGWYhXdp6BJ7_=9OQPJxQpgug080MMjdSB72i9R+5c6g@mail.gmail.com/

Fixes: fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY")
Suggested-by: Jann Horn &lt;jannh@google.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Reviewed-by: Jann Horn &lt;jannh@google.com&gt;
Link: https://lore.kernel.org/bpf/20200519053824.1089415-1-andriin@fb.com
</content>
</entry>
<entry>
<title>selftests/bpf: Enforce returning 0 for fentry/fexit programs</title>
<updated>2020-05-14T19:53:53Z</updated>
<author>
<name>Yonghong Song</name>
</author>
<published>2020-05-14T05:32:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6d74f64b922b8394dccc52576659cb0dc0a1da7b'/>
<id>urn:sha1:6d74f64b922b8394dccc52576659cb0dc0a1da7b</id>
<content type='text'>
There are a few fentry/fexit programs returning non-0.
The tests with these programs will break with the previous
patch which enfoced return-0 rules. Fix them properly.

Fixes: ac065870d928 ("selftests/bpf: Add BPF_PROG, BPF_KPROBE, and BPF_KRETPROBE macros")
Signed-off-by: Yonghong Song &lt;yhs@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Acked-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Link: https://lore.kernel.org/bpf/20200514053207.1298479-1-yhs@fb.com
</content>
</entry>
<entry>
<title>selftests/bpf: Fix a couple of broken test_btf cases</title>
<updated>2020-04-25T00:47:40Z</updated>
<author>
<name>Stanislav Fomichev</name>
</author>
<published>2020-04-22T00:37:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e1cebd841b0aa1ceda771706d54a0501986a3c88'/>
<id>urn:sha1:e1cebd841b0aa1ceda771706d54a0501986a3c88</id>
<content type='text'>
Commit 51c39bb1d5d1 ("bpf: Introduce function-by-function verification")
introduced function linkage flag and changed the error message from
"vlen != 0" to "Invalid func linkage" and broke some fake BPF programs.

Adjust the test accordingly.

AFACT, the programs don't really need any arguments and only look
at BTF for maps, so let's drop the args altogether.

Before:
BTF raw test[103] (func (Non zero vlen)): do_test_raw:3703:FAIL expected
err_str:vlen != 0
magic: 0xeb9f
version: 1
flags: 0x0
hdr_len: 24
type_off: 0
type_len: 72
str_off: 72
str_len: 10
btf_total_size: 106
[1] INT (anon) size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] INT (anon) size=4 bits_offset=0 nr_bits=32 encoding=(none)
[3] FUNC_PROTO (anon) return=0 args=(1 a, 2 b)
[4] FUNC func type_id=3 Invalid func linkage

BTF libbpf test[1] (test_btf_haskv.o): libbpf: load bpf program failed:
Invalid argument
libbpf: -- BEGIN DUMP LOG ---
libbpf:
Validating test_long_fname_2() func#1...
Arg#0 type PTR in test_long_fname_2() is not supported yet.
processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
peak_states 0 mark_read 0

libbpf: -- END LOG --
libbpf: failed to load program 'dummy_tracepoint'
libbpf: failed to load object 'test_btf_haskv.o'
do_test_file:4201:FAIL bpf_object__load: -4007
BTF libbpf test[2] (test_btf_newkv.o): libbpf: load bpf program failed:
Invalid argument
libbpf: -- BEGIN DUMP LOG ---
libbpf:
Validating test_long_fname_2() func#1...
Arg#0 type PTR in test_long_fname_2() is not supported yet.
processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
peak_states 0 mark_read 0

libbpf: -- END LOG --
libbpf: failed to load program 'dummy_tracepoint'
libbpf: failed to load object 'test_btf_newkv.o'
do_test_file:4201:FAIL bpf_object__load: -4007
BTF libbpf test[3] (test_btf_nokv.o): libbpf: load bpf program failed:
Invalid argument
libbpf: -- BEGIN DUMP LOG ---
libbpf:
Validating test_long_fname_2() func#1...
Arg#0 type PTR in test_long_fname_2() is not supported yet.
processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
peak_states 0 mark_read 0

libbpf: -- END LOG --
libbpf: failed to load program 'dummy_tracepoint'
libbpf: failed to load object 'test_btf_nokv.o'
do_test_file:4201:FAIL bpf_object__load: -4007

Fixes: 51c39bb1d5d1 ("bpf: Introduce function-by-function verification")
Signed-off-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200422003753.124921-1-sdf@google.com
</content>
</entry>
<entry>
<title>selftests/bpf: Add test for freplace program with expected_attach_type</title>
<updated>2020-04-25T00:34:30Z</updated>
<author>
<name>Toke Høiland-Jørgensen</name>
</author>
<published>2020-04-24T13:34:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1d8a0af5ee1ad219a9ebd9b43559b165bcb3ff40'/>
<id>urn:sha1:1d8a0af5ee1ad219a9ebd9b43559b165bcb3ff40</id>
<content type='text'>
This adds a new selftest that tests the ability to attach an freplace
program to a program type that relies on the expected_attach_type of the
target program to pass verification.

Signed-off-by: Toke Høiland-Jørgensen &lt;toke@redhat.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/158773526831.293902.16011743438619684815.stgit@toke.dk
</content>
</entry>
<entry>
<title>bpf, lsm: Fix the file_mprotect LSM test.</title>
<updated>2020-04-03T02:42:52Z</updated>
<author>
<name>KP Singh</name>
</author>
<published>2020-04-02T20:07:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5222d69642a09261222fb9703761a029db16cadf'/>
<id>urn:sha1:5222d69642a09261222fb9703761a029db16cadf</id>
<content type='text'>
The test was previously using an mprotect on the heap memory allocated
using malloc and was expecting the allocation to be always using
sbrk(2). This is, however, not always true and in certain conditions
malloc may end up using anonymous mmaps for heap alloctions. This means
that the following condition that is used in the "lsm/file_mprotect"
program is not sufficent to detect all mprotect calls done on heap
memory:

	is_heap = (vma-&gt;vm_start &gt;= vma-&gt;vm_mm-&gt;start_brk &amp;&amp;
		   vma-&gt;vm_end &lt;= vma-&gt;vm_mm-&gt;brk);

The test is updated to use an mprotect on memory allocated on the stack.
While this would result in the splitting of the vma, this happens only
after the security_file_mprotect hook. So, the condition used in the BPF
program holds true.

Fixes: 03e54f100d57 ("bpf: lsm: Add selftests for BPF_PROG_TYPE_LSM")
Reported-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: KP Singh &lt;kpsingh@google.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200402200751.26372-1-kpsingh@chromium.org
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next</title>
<updated>2020-03-31T02:52:37Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2020-03-31T02:52:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed52f2c608c9451fa2bad298b2ab927416105d65'/>
<id>urn:sha1:ed52f2c608c9451fa2bad298b2ab927416105d65</id>
<content type='text'>
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>selftests/bpf: Test FD-based cgroup attachment</title>
<updated>2020-03-31T00:36:41Z</updated>
<author>
<name>Andrii Nakryiko</name>
</author>
<published>2020-03-30T03:00:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7cccee42bf76efc9de69fa2e5b8dbe58bfc8ecdf'/>
<id>urn:sha1:7cccee42bf76efc9de69fa2e5b8dbe58bfc8ecdf</id>
<content type='text'>
Add selftests to exercise FD-based cgroup BPF program attachments and their
intermixing with legacy cgroup BPF attachments. Auto-detachment and program
replacement (both unconditional and cmpxchng-like) are tested as well.

Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200330030001.2312810-5-andriin@fb.com
</content>
</entry>
<entry>
<title>bpf: Test_progs, add test to catch retval refine error handling</title>
<updated>2020-03-30T22:00:30Z</updated>
<author>
<name>John Fastabend</name>
</author>
<published>2020-03-30T21:37:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d2db08c7a14e0b5eed6132baf258b80622e041a9'/>
<id>urn:sha1:d2db08c7a14e0b5eed6132baf258b80622e041a9</id>
<content type='text'>
Before this series the verifier would clamp return bounds of
bpf_get_stack() to [0, X] and this led the verifier to believe
that a JMP_JSLT 0 would be false and so would prune that path.

The result is anything hidden behind that JSLT would be unverified.
Add a test to catch this case by hiding an goto pc-1 behind the
check which will cause an infinite loop if not rejected.

Signed-off-by: John Fastabend &lt;john.fastabend@gmail.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/158560423908.10843.11783152347709008373.stgit@john-Precision-5820-Tower
</content>
</entry>
</feed>
