From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>,
Michael Holzheu
<holzheu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
Zi Shen Lim <zlim.lnx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Network Development
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH net-next 2/4] x86: bpf_jit: implement bpf_tail_call() helper
Date: Wed, 20 May 2015 09:29:28 -0700 [thread overview]
Message-ID: <555CB668.2090901@plumgrid.com> (raw)
In-Reply-To: <CALCETrV8CStuwvDXDPp5zsZw5FsSpYWBDXMYjLh6Qq703a=cgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 5/20/15 9:05 AM, Andy Lutomirski wrote:
>>>
>>> What causes the stack pointer to be right? Is there some reason that
>>> the stack pointer is the same no matter where you are in the generated
>>> code?
>>
>>
>> that's why I said 'it's _roughly_ expressed in C' this way.
>> Stack pointer doesn't change. It uses the same stack frame.
>>
>
> I think the more relevant point is that (I think) eBPF never changes
> the stack pointer after the prologue (i.e. the stack depth is truly
> constant).
ahh, that's what you were referring to.
Yes, there is no alloca(). stack cannot grow and always fixed.
That's critical for safety verification.
On a JIT side though, x64 has ugly div/mod, so JIT is doing
push/pop rax/rdx to compile 'dst_reg /= src_reg' bpf insn.
But that doesn't change 'same stack depth' rule at the time
of bpf_tail_call.
Note, s390 JIT can generate different prologue/epilogue
for every program, so it will likely be doing stack unwind
and jump. Like I was doing in my tail_call_v2 version of x64 jit:
https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/diff/arch/x86/net/bpf_jit_comp.c?h=tail_call_v2&id=bfd60c3135c8f010a6497dfc5e7d3070e26ca4d1
In case of interrupt happens sometime during this jumping process
it's also fine. no-red-zone business is very dear to my heart :)
I always keep it in mind when doing assembler/jit changes.
WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <ast@plumgrid.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "David S. Miller" <davem@davemloft.net>,
Ingo Molnar <mingo@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Michael Holzheu <holzheu@linux.vnet.ibm.com>,
Zi Shen Lim <zlim.lnx@gmail.com>,
Linux API <linux-api@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 2/4] x86: bpf_jit: implement bpf_tail_call() helper
Date: Wed, 20 May 2015 09:29:28 -0700 [thread overview]
Message-ID: <555CB668.2090901@plumgrid.com> (raw)
In-Reply-To: <CALCETrV8CStuwvDXDPp5zsZw5FsSpYWBDXMYjLh6Qq703a=cgQ@mail.gmail.com>
On 5/20/15 9:05 AM, Andy Lutomirski wrote:
>>>
>>> What causes the stack pointer to be right? Is there some reason that
>>> the stack pointer is the same no matter where you are in the generated
>>> code?
>>
>>
>> that's why I said 'it's _roughly_ expressed in C' this way.
>> Stack pointer doesn't change. It uses the same stack frame.
>>
>
> I think the more relevant point is that (I think) eBPF never changes
> the stack pointer after the prologue (i.e. the stack depth is truly
> constant).
ahh, that's what you were referring to.
Yes, there is no alloca(). stack cannot grow and always fixed.
That's critical for safety verification.
On a JIT side though, x64 has ugly div/mod, so JIT is doing
push/pop rax/rdx to compile 'dst_reg /= src_reg' bpf insn.
But that doesn't change 'same stack depth' rule at the time
of bpf_tail_call.
Note, s390 JIT can generate different prologue/epilogue
for every program, so it will likely be doing stack unwind
and jump. Like I was doing in my tail_call_v2 version of x64 jit:
https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/diff/arch/x86/net/bpf_jit_comp.c?h=tail_call_v2&id=bfd60c3135c8f010a6497dfc5e7d3070e26ca4d1
In case of interrupt happens sometime during this jumping process
it's also fine. no-red-zone business is very dear to my heart :)
I always keep it in mind when doing assembler/jit changes.
next prev parent reply other threads:[~2015-05-20 16:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-19 23:59 [PATCH net-next 0/4] bpf: introduce bpf_tail_call() helper Alexei Starovoitov
2015-05-19 23:59 ` Alexei Starovoitov
[not found] ` <1432079946-9878-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-05-19 23:59 ` [PATCH net-next 1/4] bpf: allow bpf programs to tail-call other bpf programs Alexei Starovoitov
2015-05-19 23:59 ` Alexei Starovoitov
[not found] ` <1432079946-9878-2-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-05-20 0:13 ` Andy Lutomirski
2015-05-20 0:13 ` Andy Lutomirski
2015-05-20 0:18 ` Alexei Starovoitov
[not found] ` <555BD2E4.5050608-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-05-21 16:20 ` Andy Lutomirski
2015-05-21 16:20 ` Andy Lutomirski
2015-05-21 16:40 ` Alexei Starovoitov
2015-05-21 16:43 ` Andy Lutomirski
[not found] ` <CALCETrX7xAuRoRv7WV+LS-r_pOknQdXPpBEbFy5TqB_6eGTD5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-21 16:53 ` Alexei Starovoitov
2015-05-21 16:53 ` Alexei Starovoitov
2015-05-21 16:57 ` Andy Lutomirski
[not found] ` <CALCETrWLpL8o9=P0sDGXUgcQ_LOkgJGrVdv0R6eaec=+WHPfkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-21 17:16 ` Alexei Starovoitov
2015-05-21 17:16 ` Alexei Starovoitov
2015-05-21 16:17 ` Daniel Borkmann
2015-05-21 16:17 ` Daniel Borkmann
2015-05-21 21:08 ` [PATCH net-next 0/4] bpf: introduce bpf_tail_call() helper David Miller
2015-05-21 21:08 ` David Miller
2015-05-19 23:59 ` [PATCH net-next 2/4] x86: bpf_jit: implement " Alexei Starovoitov
2015-05-20 0:11 ` Andy Lutomirski
2015-05-20 0:14 ` Alexei Starovoitov
[not found] ` <555BD1E9.5000000-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2015-05-20 16:05 ` Andy Lutomirski
2015-05-20 16:05 ` Andy Lutomirski
[not found] ` <CALCETrV8CStuwvDXDPp5zsZw5FsSpYWBDXMYjLh6Qq703a=cgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-20 16:29 ` Alexei Starovoitov [this message]
2015-05-20 16:29 ` Alexei Starovoitov
2015-05-19 23:59 ` [PATCH net-next 3/4] samples/bpf: bpf_tail_call example for tracing Alexei Starovoitov
2015-05-19 23:59 ` [PATCH net-next 4/4] samples/bpf: bpf_tail_call example for networking Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555CB668.2090901@plumgrid.com \
--to=ast-uqk4ao+rvk5wk0htik3j/w@public.gmane.org \
--cc=daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=holzheu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=zlim.lnx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.