[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ+HfNjJ+Yy=+bpvBnAMugCQBjNNvaMBs=gBFfgE7U5dv37MRw@mail.gmail.com>
Date: Wed, 16 Jan 2019 20:06:08 +0100
From: Björn Töpel <bjorn.topel@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: linux-riscv@...ts.infradead.org,
Palmer Dabbelt <palmer@...ive.com>, davidlee@...ive.com,
Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 3/3] bpf, riscv: added eBPF JIT for RV64G
Den ons 16 jan. 2019 kl 16:41 skrev Daniel Borkmann <daniel@...earbox.net>:
>
[...]
>
> > For the fixed prologue: how does, say x86, deal with BPF stack usage
> > in the tail call case? If the caller doesn't use the bpf stack, but
> > the callee does. From a quick glance in the code, the x86 prologue
> > still uses aux->stack_depth. If the callee has a different stack usage
> > that the caller, and then the callee does a function call, wouldn't
> > this mess up the frame? (Yeah, obviously missing something! :-))
>
> Basically in this case verifier sets stack size to MAX_BPF_STACK when it
> finds a tail call in the prog, meaning the callee will be reusing <= stack
> size than the caller and then upon exit unwinds it via leave+ret.
>
Ugh, so for "dynamic" tail calls this would mean "more expensive
functions calls with maximum stack usage per call"? I.e. each tail
call consumes MAX_BPF_STACK plus regular pro-/epilogue plus depth
tracking. I'd still prefer optimizing to regular functions calls, than
tail calls -- or is that naive? What is most common in larger bpf
deployments, say, Katran or Cilium?
Cheers!
Björn
> Cheers,
> Daniel
Powered by blists - more mailing lists