[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bf5a63c-7607-a24d-7e14-e41caa84bfc3@iogearbox.net>
Date: Tue, 15 Sep 2020 17:03:40 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Cc: ast@...nel.org, bpf@...r.kernel.org, netdev@...r.kernel.org,
bjorn.topel@...el.com, magnus.karlsson@...el.com
Subject: Re: [PATCH v7 bpf-next 7/7] selftests: bpf: add dummy prog for
bpf2bpf with tailcall
On 9/15/20 6:39 AM, Alexei Starovoitov wrote:
> On Fri, Sep 11, 2020 at 08:59:27PM +0200, Maciej Fijalkowski wrote:
>> On Thu, Sep 03, 2020 at 12:51:14PM -0700, Alexei Starovoitov wrote:
>>> On Wed, Sep 02, 2020 at 10:08:15PM +0200, Maciej Fijalkowski wrote:
[...]
>>> Could you add few more tests to exercise the new feature more thoroughly?
>>> Something like tailcall3.c that checks 32 limit, but doing tail_call from subprog.
>>> And another test that consume non-trival amount of stack in each function.
>>> Adding 'volatile char arr[128] = {};' would do the trick.
>>
>> Yet another prolonged silence from my side, but not without a reason -
>> this request opened up a Pandora's box.
>
> Great catch and thanks to our development practices! As a community we should
> remember this lesson and request selftests more often than not.
+1, speaking of pandora ... ;-) I recently noticed that we also have the legacy
ld_abs/ld_ind instructions. Right now check_ld_abs() gates them by bailing out
if env->subprog_cnt > 1, but that doesn't solve everything given the prog itself
may not have bpf2bpf calls, but it could get tail-called out of a subprog. We
need to reject such cases (& add selftests for it), otherwise this would be a
verifier bypass given they may implicitly exit the program (and then mismatch
the return type that the verifier was expecting).
Best,
Daniel
Powered by blists - more mailing lists