From: Eric Dumazet <eric.dumazet@gmail.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: George Bakos <gbakos@alpinista.org>,
Jay Schulist <jschlst@samba.org>,
netdev@vger.kernel.org
Subject: [PATCH net-next] filter: add MOD operation
Date: Sat, 08 Sep 2012 10:03:35 +0200 [thread overview]
Message-ID: <1347091415.1234.317.camel@edumazet-glaptop> (raw)
In-Reply-To: <20120908030311.GM17289@tassilo.jf.intel.com>
From: Eric Dumazet <edumazet@google.com>
On Fri, 2012-09-07 at 20:03 -0700, Andi Kleen wrote:
> On Fri, Sep 07, 2012 at 07:49:10AM +0000, George Bakos wrote:
> > Gents,
> > Any fundamental reason why the following (, etc.) shouldn't be
> > included in net/core/filter.c?
> >
> > case BPF_S_ALU_MOD_X:
> > if (X == 0)
> > return 0;
> > A %= X;
> > continue;
>
> Copying netdev.
>
> In principle no reason against it, but you may need to update
> the various BPF JITs too that Linux now has too.
Hi Andi, thanks for the forward
In recent commit ffe06c17afbb was added ALU_XOR_X,
so we could add ALU_MOD_X as well.
ALU_MOD_K is a bit more complex as we cant use an ancillary, and must
instead use a new BPF_OP code :
/* alu/jmp fields */
#define BPF_OP(code) ((code) & 0xf0)
#define BPF_ADD 0x00
#define BPF_SUB 0x10
#define BPF_MUL 0x20
#define BPF_DIV 0x30
#define BPF_OR 0x40
#define BPF_AND 0x50
#define BPF_LSH 0x60
#define BPF_RSH 0x70
#define BPF_NEG 0x80
So I guess we could use
#define BPF_MOD 0x90
About the various arches JIT, there is no hurry :
We can update them later.
At JIT 'compile' time, if we find a not yet handled instruction, we fall
back to the net/core/filter.c interpreter.
If the following patch is accepted, I'll do the x86 part as a followup.
Thanks !
[PATCH net-next] filter: add MOD operation
Add a new ALU opcode, to compute a modulus.
Commit ffe06c17afbbb used an ancillary to implement XOR_X,
but here we reserve one of the available ALU opcode to implement both
MOD_X and MOD_K
Signed-off-by: Eric Dumazet <edumazet@google.com>
Suggested-by: George Bakos <gbakos@alpinista.org>
Cc: Jay Schulist <jschlst@samba.org>
Cc: Jiri Pirko <jpirko@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
---
include/linux/filter.h | 4 ++++
net/core/filter.c | 15 +++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 82b0135..3cf5fd5 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -74,6 +74,8 @@ struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
#define BPF_LSH 0x60
#define BPF_RSH 0x70
#define BPF_NEG 0x80
+#define BPF_MOD 0x90
+
#define BPF_JA 0x00
#define BPF_JEQ 0x10
#define BPF_JGT 0x20
@@ -196,6 +198,8 @@ enum {
BPF_S_ALU_MUL_K,
BPF_S_ALU_MUL_X,
BPF_S_ALU_DIV_X,
+ BPF_S_ALU_MOD_K,
+ BPF_S_ALU_MOD_X,
BPF_S_ALU_AND_K,
BPF_S_ALU_AND_X,
BPF_S_ALU_OR_K,
diff --git a/net/core/filter.c b/net/core/filter.c
index 907efd2..fbe3a8d 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -167,6 +167,14 @@ unsigned int sk_run_filter(const struct sk_buff *skb,
case BPF_S_ALU_DIV_K:
A = reciprocal_divide(A, K);
continue;
+ case BPF_S_ALU_MOD_X:
+ if (X == 0)
+ return 0;
+ A %= X;
+ continue;
+ case BPF_S_ALU_MOD_K:
+ A %= K;
+ continue;
case BPF_S_ALU_AND_X:
A &= X;
continue;
@@ -469,6 +477,8 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
[BPF_ALU|BPF_MUL|BPF_K] = BPF_S_ALU_MUL_K,
[BPF_ALU|BPF_MUL|BPF_X] = BPF_S_ALU_MUL_X,
[BPF_ALU|BPF_DIV|BPF_X] = BPF_S_ALU_DIV_X,
+ [BPF_ALU|BPF_MOD|BPF_K] = BPF_S_ALU_MOD_K,
+ [BPF_ALU|BPF_MOD|BPF_X] = BPF_S_ALU_MOD_X,
[BPF_ALU|BPF_AND|BPF_K] = BPF_S_ALU_AND_K,
[BPF_ALU|BPF_AND|BPF_X] = BPF_S_ALU_AND_X,
[BPF_ALU|BPF_OR|BPF_K] = BPF_S_ALU_OR_K,
@@ -531,6 +541,11 @@ int sk_chk_filter(struct sock_filter *filter, unsigned int flen)
return -EINVAL;
ftest->k = reciprocal_value(ftest->k);
break;
+ case BPF_S_ALU_MOD_K:
+ /* check for division by zero */
+ if (ftest->k == 0)
+ return -EINVAL;
+ break;
case BPF_S_LD_MEM:
case BPF_S_LDX_MEM:
case BPF_S_ST:
next prev parent reply other threads:[~2012-09-08 8:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120905213941.03c85968@arrowsmith>
[not found] ` <C71A36A8-08D2-4D3D-AF2B-EF89FEECE1A6@alum.mit.edu>
[not found] ` <20120906073615.693d14e0@arrowsmith>
[not found] ` <46AB14E3-73F4-41FA-8086-F1D663AF4549@alum.mit.edu>
[not found] ` <20120907074910.2df46817@arrowsmith>
2012-09-08 3:03 ` [tcpdump-workers] Modular arithmetic Andi Kleen
2012-09-08 8:03 ` Eric Dumazet [this message]
2012-09-08 20:31 ` [PATCH net-next] filter: add MOD operation George Bakos
2012-09-10 19:45 ` David Miller
2012-09-10 20:48 ` [PATCH net-next] x86 bpf_jit: support " Eric Dumazet
2012-09-10 21:09 ` David Miller
2012-09-10 8:41 ` [tcpdump-workers] Modular arithmetic David Laight
2012-09-10 9:25 ` Eric Dumazet
2012-09-10 10:41 ` David Laight
2012-09-10 11:49 ` [tcpdump-workers] " Daniel Borkmann
2012-09-10 17:50 ` Guy Harris
2014-05-18 18:26 ` Guy Harris
2012-09-10 14:49 ` [tcpdump-workers] " Andi Kleen
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=1347091415.1234.317.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=ak@linux.intel.com \
--cc=gbakos@alpinista.org \
--cc=jschlst@samba.org \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox