netdev - Re: [PATCH v2 bpf-next] bpf: abstract away entire bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEf4BzbjqhX5sgoRZX1k-=WjSsvCAXxYs6WN3j4nBzja0ZbTnw@mail.gmail.com>
Date:   Thu, 12 Mar 2020 22:04:50 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next] bpf: abstract away entire bpf_link clean up procedure

On Thu, Mar 12, 2020 at 6:50 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Thu, Mar 12, 2020 at 05:21:28PM -0700, Andrii Nakryiko wrote:
> > Instead of requiring users to do three steps for cleaning up bpf_link, its
> > anon_inode file, and unused fd, abstract that away into bpf_link_cleanup()
> > helper. bpf_link_defunct() is removed, as it shouldn't be needed as an
> > individual operation anymore.
> >
> > v1->v2:
> > - keep bpf_link_cleanup() static for now (Daniel).
> >
> > Signed-off-by: Andrii Nakryiko <andriin@...com>
>
> Applied.
>
> But noticed that the test is now sporadically failing:
> ./test_progs -n 24
> test_link_pinning:PASS:skel_open 0 nsec
> test_link_pinning_subtest:PASS:link_attach 0 nsec
> test_link_pinning_subtest:PASS:res_check1 0 nsec
> test_link_pinning_subtest:PASS:link_pin 0 nsec
> test_link_pinning_subtest:PASS:pin_path1 0 nsec
> test_link_pinning_subtest:PASS:stat_link 0 nsec
> test_link_pinning_subtest:PASS:res_check2 0 nsec
> test_link_pinning_subtest:PASS:res_check3 0 nsec
> test_link_pinning_subtest:PASS:link_open 0 nsec
> test_link_pinning_subtest:PASS:pin_path2 0 nsec
> test_link_pinning_subtest:PASS:link_unpin 0 nsec
> test_link_pinning_subtest:PASS:res_check4 0 nsec
> test_link_pinning_subtest:FAIL:link_attached got to iteration #10000
> #24/1 pin_raw_tp:FAIL
> test_link_pinning_subtest:PASS:link_attach 0 nsec
> test_link_pinning_subtest:PASS:res_check1 0 nsec
> test_link_pinning_subtest:PASS:link_pin 0 nsec
> test_link_pinning_subtest:PASS:pin_path1 0 nsec
> test_link_pinning_subtest:PASS:stat_link 0 nsec
> test_link_pinning_subtest:PASS:res_check2 0 nsec
> test_link_pinning_subtest:PASS:res_check3 0 nsec
> test_link_pinning_subtest:PASS:link_open 0 nsec
> test_link_pinning_subtest:PASS:pin_path2 0 nsec
> test_link_pinning_subtest:PASS:link_unpin 0 nsec
> test_link_pinning_subtest:PASS:res_check4 0 nsec
> test_link_pinning_subtest:FAIL:link_attached got to iteration #10000
> #24/2 pin_tp_btf:FAIL
> #24 link_pinning:FAIL
> Summary: 0/0 PASSED, 0 SKIPPED, 3 FAILED
>
> it's failing more often than passing, actually.

Can't repro this even with 2 parallel kernel builds and running this
test in VM in a loop. I can bump waiting time a little bit or can drop
that check, because it's inherently non-deterministic...
>
> The #64 tcp_rtt also started to fail sporadically.
> But I wonder whether it's leftover from 24. shrug.

Can you please paste log from #64 failure?