On Tue, 27 Oct 2020, Greg Kroah-Hartman wrote: > From: Alan Maguire <alan.maguire@oracle.com> > > [ Upstream commit eb58bbf2e5c7917aa30bf8818761f26bbeeb2290 ] > > bpf iter size increase to PAGE_SIZE << 3 means overflow tests assuming > page size need to be bumped also. > Alexei can correct me if I've got this wrong but I don't believe it's a stable backport candidate. This selftests change should only be relevant when the BPF iterator size has been bumped up as it was in af65320 bpf: Bump iter seq size to support BTF representation of large data structures ...so I don't _think_ this commit belongs in stable unless the above commit is backported also (and unless I'm missing something I don't see a burning reason to do that currently). Backporting this alone will likely induce bpf test failures. Apologies if the "Fix" in the title was misleading; it should probably have been "Update" to reflect the fact it's not fixing an existing bug but rather updating the test to operate correctly in the context of other changes in the for-next patch series it was part of. Thanks! Alan
On Tue, Oct 27, 2020 at 03:42:10PM +0000, Alan Maguire wrote: >On Tue, 27 Oct 2020, Greg Kroah-Hartman wrote: > >> From: Alan Maguire <alan.maguire@oracle.com> >> >> [ Upstream commit eb58bbf2e5c7917aa30bf8818761f26bbeeb2290 ] >> >> bpf iter size increase to PAGE_SIZE << 3 means overflow tests assuming >> page size need to be bumped also. >> > >Alexei can correct me if I've got this wrong but I don't believe >it's a stable backport candidate. > >This selftests change should only be relevant when the BPF iterator >size has been bumped up as it was in > >af65320 bpf: Bump iter seq size to support BTF representation of large >data structures > >...so I don't _think_ this commit belongs in stable unless the >above commit is backported also (and unless I'm missing something >I don't see a burning reason to do that currently). > >Backporting this alone will likely induce bpf test failures. >Apologies if the "Fix" in the title was misleading; it should >probably have been "Update" to reflect the fact it's not fixing >an existing bug but rather updating the test to operate correctly >in the context of other changes in the for-next patch series >it was part of. I'll drop it, thanks!
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c index 87c29dde1cf96..669f195de2fa0 100644 --- a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c +++ b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c @@ -249,7 +249,7 @@ static void test_overflow(bool test_e2big_overflow, bool ret1) struct bpf_map_info map_info = {}; struct bpf_iter_test_kern4 *skel; struct bpf_link *link; - __u32 page_size; + __u32 iter_size; char *buf; skel = bpf_iter_test_kern4__open(); @@ -271,19 +271,19 @@ static void test_overflow(bool test_e2big_overflow, bool ret1) "map_creation failed: %s\n", strerror(errno))) goto free_map1; - /* bpf_seq_printf kernel buffer is one page, so one map + /* bpf_seq_printf kernel buffer is 8 pages, so one map * bpf_seq_write will mostly fill it, and the other map * will partially fill and then trigger overflow and need * bpf_seq_read restart. */ - page_size = sysconf(_SC_PAGE_SIZE); + iter_size = sysconf(_SC_PAGE_SIZE) << 3; if (test_e2big_overflow) { - skel->rodata->print_len = (page_size + 8) / 8; - expected_read_len = 2 * (page_size + 8); + skel->rodata->print_len = (iter_size + 8) / 8; + expected_read_len = 2 * (iter_size + 8); } else if (!ret1) { - skel->rodata->print_len = (page_size - 8) / 8; - expected_read_len = 2 * (page_size - 8); + skel->rodata->print_len = (iter_size - 8) / 8; + expected_read_len = 2 * (iter_size - 8); } else { skel->rodata->print_len = 1; expected_read_len = 2 * 8;