From: Vladimir Murzin <murzin.v@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, av1474@comtv.ru,
kaffeemonster@googlemail.com, edumazet@google.com,
mingo@redhat.com, tglx@linutronix.de
Subject: Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
Date: Sun, 13 Oct 2013 16:21:21 +0200 [thread overview]
Message-ID: <20131013142115.GA1872@hp530> (raw)
In-Reply-To: <20131011.145613.332487610005117559.davem@davemloft.net>
On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> From: Vladimir Murzin <murzin.v@gmail.com>
> Date: Tue, 8 Oct 2013 20:31:49 +0400
>
> > Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> > were not passed. At the same time handlers for "any offset" cases make
> > the same checks against r_addr at run-time, that will always lead to
> > bpf_error.
> >
> > Run-time checks are still necessary for indirect load operations, but
> > error path for absolute and mesh loads are worth to optimize during bpf
> > compile time.
> >
> > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> >
> > Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: "David S. Miller" <davem@davemloft.net
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> >
> > ---
> > arch/x86/net/bpf_jit_comp.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index 79c216a..28ac17f 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
> > }
> >
> > #define CHOOSE_LOAD_FUNC(K, func) \
> > - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> > + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
> >
> > /* Helper to find the offset of pkt_type in sk_buff
> > * We want to make sure its still a 3bit field starting at a byte boundary.
> > @@ -611,7 +611,13 @@ void bpf_jit_compile(struct sk_filter *fp)
> > }
> > case BPF_S_LD_W_ABS:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_word);
> > -common_load: seen |= SEEN_DATAREF;
> > +common_load:
> > + if (!func) {
> > + CLEAR_A();
> > + EMIT_JMP(cleanup_addr - addrs[i]);
> > + break;
> > + }
> > + seen |= SEEN_DATAREF;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > EMIT1_off32(0xe8, t_offset); /* call */
> > @@ -625,10 +631,7 @@ common_load: seen |= SEEN_DATAREF;
> > case BPF_S_LDX_B_MSH:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> > seen |= SEEN_DATAREF | SEEN_XREG;
> > - t_offset = func - (image + addrs[i]);
> > - EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > - EMIT1_off32(0xe8, t_offset); /* call sk_load_byte_msh */
> > - break;
> > + goto common_load;
>
> This second hunk will set SEEN_DATAREF even if common_load takes the
> !func path, that is not the intention at all here.
>
> There's a reason why these two code blocks aren't shared.
Thanks for review, David!
What about patch bellow?
---
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
Vladimir
next prev parent reply other threads:[~2013-10-13 14:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 16:31 [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path Vladimir Murzin
2013-10-08 22:50 ` Jan Seiffert
2013-10-13 14:26 ` Vladimir Murzin
[not found] ` <1381249910-17338-2-git-send-email-murzin.v@gmail.com>
2013-10-11 18:56 ` [PATCH 2/3] net: bpf jit: x86: " David Miller
2013-10-13 14:21 ` Vladimir Murzin [this message]
2013-10-13 14:25 ` malc
2013-10-13 14:31 ` Vladimir Murzin
2013-10-13 14:54 ` Vladimir Murzin
2013-10-13 14:54 ` Vladimir Murzin
2013-10-13 16:36 ` Eric Dumazet
2013-10-14 2:55 ` Vladimir Murzin
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=20131013142115.GA1872@hp530 \
--to=murzin.v@gmail.com \
--cc=av1474@comtv.ru \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kaffeemonster@googlemail.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.