* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
[not found] ` <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
@ 2013-04-24 17:41 ` Daniel Borkmann
[not found] ` <3592414.M8kQZLCXlW@wuerfel>
1 sibling, 0 replies; 7+ messages in thread
From: Daniel Borkmann @ 2013-04-24 17:41 UTC (permalink / raw)
To: Nicolas Schichan
Cc: Will Drewry, Mircea Gherzan, Andrew Morton, linux-kernel,
linux-arm-kernel, Russell King, David S. Miller, Daniel Borkmann,
netdev
On 04/24/2013 07:27 PM, Nicolas Schichan wrote:
> This is in preparation of bpf_jit support for seccomp filters.
Please also CC the netdev list for BPF related patches.
Just to give you a heads-up, this might likely lead to a merge
conflict with the net-next tree (commit 79617801ea0c0e66, "filter:
bpf_jit_comp: refactor and unify BPF JIT image dump output").
> Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
> ---
> arch/arm/net/bpf_jit_32.c | 46 ++++++++++++++++++++++++++++-----------------
> 1 file changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index a0bd8a7..bb66a2b 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -55,7 +55,8 @@
> #define FLAG_NEED_X_RESET (1 << 0)
>
> struct jit_ctx {
> - const struct sk_filter *skf;
> + unsigned short prog_len;
> + struct sock_filter *prog_insns;
> unsigned idx;
> unsigned prologue_bytes;
> int ret0_fp_idx;
> @@ -131,8 +132,8 @@ static u16 saved_regs(struct jit_ctx *ctx)
> {
> u16 ret = 0;
>
> - if ((ctx->skf->len > 1) ||
> - (ctx->skf->insns[0].code == BPF_S_RET_A))
> + if ((ctx->prog_len > 1) ||
> + (ctx->prog_insns[0].code == BPF_S_RET_A))
> ret |= 1 << r_A;
>
> #ifdef CONFIG_FRAME_POINTER
> @@ -181,7 +182,7 @@ static inline bool is_load_to_a(u16 inst)
> static void build_prologue(struct jit_ctx *ctx)
> {
> u16 reg_set = saved_regs(ctx);
> - u16 first_inst = ctx->skf->insns[0].code;
> + u16 first_inst = ctx->prog_insns[0].code;
> u16 off;
>
> #ifdef CONFIG_FRAME_POINTER
> @@ -279,7 +280,7 @@ static u16 imm_offset(u32 k, struct jit_ctx *ctx)
> ctx->imms[i] = k;
>
> /* constants go just after the epilogue */
> - offset = ctx->offsets[ctx->skf->len];
> + offset = ctx->offsets[ctx->prog_len];
> offset += ctx->prologue_bytes;
> offset += ctx->epilogue_bytes;
> offset += i * 4;
> @@ -419,7 +420,7 @@ static inline void emit_err_ret(u8 cond, struct jit_ctx *ctx)
> emit(ARM_MOV_R(ARM_R0, ARM_R0), ctx);
> } else {
> _emit(cond, ARM_MOV_I(ARM_R0, 0), ctx);
> - _emit(cond, ARM_B(b_imm(ctx->skf->len, ctx)), ctx);
> + _emit(cond, ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
> }
> }
>
> @@ -469,14 +470,13 @@ static inline void update_on_xread(struct jit_ctx *ctx)
> static int build_body(struct jit_ctx *ctx)
> {
> void *load_func[] = {jit_get_skb_b, jit_get_skb_h, jit_get_skb_w};
> - const struct sk_filter *prog = ctx->skf;
> const struct sock_filter *inst;
> unsigned i, load_order, off, condt;
> int imm12;
> u32 k;
>
> - for (i = 0; i < prog->len; i++) {
> - inst = &(prog->insns[i]);
> + for (i = 0; i < ctx->prog_len; i++) {
> + inst = &(ctx->prog_insns[i]);
> /* K as an immediate value operand */
> k = inst->k;
>
> @@ -769,8 +769,8 @@ cmp_x:
> ctx->ret0_fp_idx = i;
> emit_mov_i(ARM_R0, k, ctx);
> b_epilogue:
> - if (i != ctx->skf->len - 1)
> - emit(ARM_B(b_imm(prog->len, ctx)), ctx);
> + if (i != ctx->prog_len - 1)
> + emit(ARM_B(b_imm(ctx->prog_len, ctx)), ctx);
> break;
> case BPF_S_MISC_TAX:
> /* X = A */
> @@ -858,7 +858,7 @@ b_epilogue:
> }
>
>
> -void bpf_jit_compile(struct sk_filter *fp)
> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
> {
> struct jit_ctx ctx;
> unsigned tmp_idx;
> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
> if (!bpf_jit_enable)
> return;
>
> - memset(&ctx, 0, sizeof(ctx));
> - ctx.skf = fp;
> + ctx = *out_ctx;
> ctx.ret0_fp_idx = -1;
>
> - ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> + ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
> if (ctx.offsets == NULL)
> return;
>
> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
> print_hex_dump(KERN_INFO, "BPF JIT code: ",
> DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
> alloc_size, false);
> -
> - fp->bpf_func = (void *)ctx.target;
> out:
> kfree(ctx.offsets);
> +
> + *out_ctx = ctx;
> return;
> }
>
> +void bpf_jit_compile(struct sk_filter *fp)
> +{
> + struct jit_ctx ctx;
> +
> + memset(&ctx, 0, sizeof(ctx));
> + ctx.prog_len = fp->len;
> + ctx.prog_insns = fp->insns;
> +
> + __bpf_jit_compile(&ctx);
> + if (ctx.target)
> + fp->bpf_func = (void *)ctx.target;
> +}
> +
> static void bpf_jit_free_worker(struct work_struct *work)
> {
> module_free(NULL, work);
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
[not found] ` <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
@ 2013-04-26 19:47 ` Daniel Borkmann
2013-04-26 20:09 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Borkmann @ 2013-04-26 19:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Nicolas Schichan, Will Drewry, Mircea Gherzan,
linux-kernel, linux-arm-kernel, Russell King, David S. Miller,
Daniel Borkmann, netdev
On 04/26/2013 09:26 PM, Andrew Morton wrote:
> On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
>>> @@ -858,7 +858,7 @@ b_epilogue:
>>> }
>>>
>>>
>>> -void bpf_jit_compile(struct sk_filter *fp)
>>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>>> {
>>> struct jit_ctx ctx;
>>> unsigned tmp_idx;
>>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>>> if (!bpf_jit_enable)
>>> return;
>>>
>>> - memset(&ctx, 0, sizeof(ctx));
>>> - ctx.skf = fp;
>>> + ctx = *out_ctx;
>>> ctx.ret0_fp_idx = -1;
>>>
>>> - ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
>>> + ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>>> if (ctx.offsets == NULL)
>>> return;
>>>
>>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>>> print_hex_dump(KERN_INFO, "BPF JIT code: ",
>>> DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>>> alloc_size, false);
>>> -
>>> - fp->bpf_func = (void *)ctx.target;
>>> out:
>>> kfree(ctx.offsets);
>>> +
>>> + *out_ctx = ctx;
>>> return;
>>
>> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
>> refactor and unify BPF JIT image dump output" is now causing build errors
>> in linux-next:
>>
>> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
>> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
>> bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
>
> Thanks, I did this. There may be a smarter way...
I think also seccomp_jit_compile() would need this change then, otherwise the build
with CONFIG_SECCOMP_FILTER_JIT might break.
I can fix this up for you if not already applied. I presume it's against
linux-next tree?
> --- a/arch/arm/net/bpf_jit_32.c~arm-net-bpf_jit-make-code-generation-less-dependent-on-struct-sk_filter-fix
> +++ a/arch/arm/net/bpf_jit_32.c
> @@ -858,7 +858,7 @@ b_epilogue:
> }
>
>
> -static void __bpf_jit_compile(struct jit_ctx *out_ctx)
> +static void __bpf_jit_compile(struct sk_filter *fp, struct jit_ctx *out_ctx)
> {
> struct jit_ctx ctx;
> unsigned tmp_idx;
> @@ -934,7 +934,7 @@ void bpf_jit_compile(struct sk_filter *f
> ctx.prog_len = fp->len;
> ctx.prog_insns = fp->insns;
>
> - __bpf_jit_compile(&ctx);
> + __bpf_jit_compile(fp, &ctx);
> if (ctx.target)
> fp->bpf_func = (void *)ctx.target;
> }
> _
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
2013-04-26 19:47 ` Daniel Borkmann
@ 2013-04-26 20:09 ` Andrew Morton
2013-04-26 22:01 ` Daniel Borkmann
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2013-04-26 20:09 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Arnd Bergmann, Nicolas Schichan, Will Drewry, Mircea Gherzan,
linux-kernel, linux-arm-kernel, Russell King, David S. Miller,
Daniel Borkmann, netdev
On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann <dborkman@redhat.com> wrote:
> On 04/26/2013 09:26 PM, Andrew Morton wrote:
> > On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
> >>> @@ -858,7 +858,7 @@ b_epilogue:
> >>> }
> >>>
> >>>
> >>> -void bpf_jit_compile(struct sk_filter *fp)
> >>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
> >>> {
> >>> struct jit_ctx ctx;
> >>> unsigned tmp_idx;
> >>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
> >>> if (!bpf_jit_enable)
> >>> return;
> >>>
> >>> - memset(&ctx, 0, sizeof(ctx));
> >>> - ctx.skf = fp;
> >>> + ctx = *out_ctx;
> >>> ctx.ret0_fp_idx = -1;
> >>>
> >>> - ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
> >>> + ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
> >>> if (ctx.offsets == NULL)
> >>> return;
> >>>
> >>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
> >>> print_hex_dump(KERN_INFO, "BPF JIT code: ",
> >>> DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
> >>> alloc_size, false);
> >>> -
> >>> - fp->bpf_func = (void *)ctx.target;
> >>> out:
> >>> kfree(ctx.offsets);
> >>> +
> >>> + *out_ctx = ctx;
> >>> return;
> >>
> >> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
> >> refactor and unify BPF JIT image dump output" is now causing build errors
> >> in linux-next:
> >>
> >> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
> >> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
> >> bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
> >
> > Thanks, I did this. There may be a smarter way...
>
> I think also seccomp_jit_compile() would need this change then, otherwise the build
> with CONFIG_SECCOMP_FILTER_JIT might break.
urgh, that tears it.
> I can fix this up for you if not already applied. I presume it's against
> linux-next tree?
Yup, please send something.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
2013-04-26 20:09 ` Andrew Morton
@ 2013-04-26 22:01 ` Daniel Borkmann
2013-04-26 22:18 ` Xi Wang
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Borkmann @ 2013-04-26 22:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Nicolas Schichan, Will Drewry, Mircea Gherzan,
linux-kernel, linux-arm-kernel, Russell King, David S. Miller,
Daniel Borkmann, netdev, Xi Wang
[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]
On 04/26/2013 10:09 PM, Andrew Morton wrote:
> On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 04/26/2013 09:26 PM, Andrew Morton wrote:
>>> On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
>>>>> @@ -858,7 +858,7 @@ b_epilogue:
>>>>> }
>>>>>
>>>>>
>>>>> -void bpf_jit_compile(struct sk_filter *fp)
>>>>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>>>>> {
>>>>> struct jit_ctx ctx;
>>>>> unsigned tmp_idx;
>>>>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>> if (!bpf_jit_enable)
>>>>> return;
>>>>>
>>>>> - memset(&ctx, 0, sizeof(ctx));
>>>>> - ctx.skf = fp;
>>>>> + ctx = *out_ctx;
>>>>> ctx.ret0_fp_idx = -1;
>>>>>
>>>>> - ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
>>>>> + ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>>>>> if (ctx.offsets == NULL)
>>>>> return;
>>>>>
>>>>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>> print_hex_dump(KERN_INFO, "BPF JIT code: ",
>>>>> DUMP_PREFIX_ADDRESS, 16, 4, ctx.target,
>>>>> alloc_size, false);
>>>>> -
>>>>> - fp->bpf_func = (void *)ctx.target;
>>>>> out:
>>>>> kfree(ctx.offsets);
>>>>> +
>>>>> + *out_ctx = ctx;
>>>>> return;
>>>>
>>>> This part of the patch, in combination with 79617801e "filter: bpf_jit_comp:
>>>> refactor and unify BPF JIT image dump output" is now causing build errors
>>>> in linux-next:
>>>>
>>>> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
>>>> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
>>>> bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
>>>
>>> Thanks, I did this. There may be a smarter way...
>>
>> I think also seccomp_jit_compile() would need this change then, otherwise the build
>> with CONFIG_SECCOMP_FILTER_JIT might break.
>
> urgh, that tears it.
>
>> I can fix this up for you if not already applied. I presume it's against
>> linux-next tree?
>
> Yup, please send something.
Patch is attached. However, I currently don't have an ARM toolchain at hand, so
uncompiled, untested.
@Nicolas, Xi (cc, ref: http://thread.gmane.org/gmane.linux.kernel/1481464):
If there is someday support for other archs as well, it would be nice if we
do not have each time duplicated seccomp_jit_compile() etc functions in each
JIT implementation, i.e. because they do basically the same. So follow-up
{fix,clean}up is appreciated.
Also, I find it a bit weird that seccomp_filter_get_len() and some other
_one-line_ functions from kernel/seccomp.c are not placed into the
corresponding header file as inlines.
[-- Attachment #2: 0001-ARM-bpf_jit-seccomp-filtering-fixup-merge-conflict.patch --]
[-- Type: text/x-patch, Size: 1668 bytes --]
>From 655f4aabee7ccb909345ccfce92a405e3d173de5 Mon Sep 17 00:00:00 2001
Message-Id: <655f4aabee7ccb909345ccfce92a405e3d173de5.1367012811.git.dborkman@redhat.com>
In-Reply-To: <cover.1367012811.git.dborkman@redhat.com>
References: <cover.1367012811.git.dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Fri, 26 Apr 2013 23:41:06 +0200
Subject: [PATCH linux-next -mm] ARM: bpf_jit: seccomp filtering: fixup merge conflict
Commit e4c67f4c0479d8e3cb0 (ARM: net: bpf_jit: make code generation
less dependent on struct sk_filter.) caused a merge conflict with
commit 79617801ea0c0e6 (filter: bpf_jit_comp: refactor and unify
BPF JIT image dump output) resulting in a build failure:
arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in this function)
bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
Fix this up by using ctx.prog_len that is being set before we enter
__bpf_jit_compile().
Reported-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
arch/arm/net/bpf_jit_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index c5ef845..eb4daba 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -927,7 +927,7 @@ static void __bpf_jit_compile(struct jit_ctx *out_ctx)
if (bpf_jit_enable > 1)
/* there are 2 passes here */
- bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
+ bpf_jit_dump(ctx.prog_len, alloc_size, 2, ctx.target);
out:
kfree(ctx.offsets);
--
1.7.11.7
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
2013-04-26 22:01 ` Daniel Borkmann
@ 2013-04-26 22:18 ` Xi Wang
2013-04-26 22:30 ` Daniel Borkmann
2013-04-26 23:33 ` David Miller
0 siblings, 2 replies; 7+ messages in thread
From: Xi Wang @ 2013-04-26 22:18 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Andrew Morton, Arnd Bergmann, Nicolas Schichan, Will Drewry,
Mircea Gherzan, linux-kernel, linux-arm-kernel, Russell King,
David S. Miller, Daniel Borkmann, netdev
Thanks for CCing. One way to clean up this would be to refactor the
bpf jit interface as:
bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
void bpf_jit_free(bpf_func_t bpf_func);
Then both packet and seccomp filters can share the unified interface.
Also, we don't need seccomp_filter_get_len() and other helpers.
Do you want me to rebase my patch against linux-next and see how that goes?
- xi
On Fri, Apr 26, 2013 at 6:01 PM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 04/26/2013 10:09 PM, Andrew Morton wrote:
>>
>> On Fri, 26 Apr 2013 21:47:46 +0200 Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>>>
>>> On 04/26/2013 09:26 PM, Andrew Morton wrote:
>>>>
>>>> On Fri, 26 Apr 2013 16:04:44 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>>>>>
>>>>> On Wednesday 24 April 2013 19:27:08 Nicolas Schichan wrote:
>>>>>>
>>>>>> @@ -858,7 +858,7 @@ b_epilogue:
>>>>>> }
>>>>>>
>>>>>>
>>>>>> -void bpf_jit_compile(struct sk_filter *fp)
>>>>>> +static void __bpf_jit_compile(struct jit_ctx *out_ctx)
>>>>>> {
>>>>>> struct jit_ctx ctx;
>>>>>> unsigned tmp_idx;
>>>>>> @@ -867,11 +867,10 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>>> if (!bpf_jit_enable)
>>>>>> return;
>>>>>>
>>>>>> - memset(&ctx, 0, sizeof(ctx));
>>>>>> - ctx.skf = fp;
>>>>>> + ctx = *out_ctx;
>>>>>> ctx.ret0_fp_idx = -1;
>>>>>>
>>>>>> - ctx.offsets = kzalloc(4 * (ctx.skf->len + 1), GFP_KERNEL);
>>>>>> + ctx.offsets = kzalloc(4 * (ctx.prog_len + 1), GFP_KERNEL);
>>>>>> if (ctx.offsets == NULL)
>>>>>> return;
>>>>>>
>>>>>> @@ -921,13 +920,26 @@ void bpf_jit_compile(struct sk_filter *fp)
>>>>>> print_hex_dump(KERN_INFO, "BPF JIT code: ",
>>>>>> DUMP_PREFIX_ADDRESS, 16, 4,
>>>>>> ctx.target,
>>>>>> alloc_size, false);
>>>>>> -
>>>>>> - fp->bpf_func = (void *)ctx.target;
>>>>>> out:
>>>>>> kfree(ctx.offsets);
>>>>>> +
>>>>>> + *out_ctx = ctx;
>>>>>> return;
>>>>>
>>>>>
>>>>> This part of the patch, in combination with 79617801e "filter:
>>>>> bpf_jit_comp:
>>>>> refactor and unify BPF JIT image dump output" is now causing build
>>>>> errors
>>>>> in linux-next:
>>>>>
>>>>> arch/arm/net/bpf_jit_32.c: In function '__bpf_jit_compile':
>>>>> arch/arm/net/bpf_jit_32.c:930:16: error: 'fp' undeclared (first use in
>>>>> this function)
>>>>> bpf_jit_dump(fp->len, alloc_size, 2, ctx.target);
>>>>
>>>>
>>>> Thanks, I did this. There may be a smarter way...
>>>
>>>
>>> I think also seccomp_jit_compile() would need this change then, otherwise
>>> the build
>>> with CONFIG_SECCOMP_FILTER_JIT might break.
>>
>>
>> urgh, that tears it.
>>
>>> I can fix this up for you if not already applied. I presume it's against
>>> linux-next tree?
>>
>>
>> Yup, please send something.
>
>
> Patch is attached. However, I currently don't have an ARM toolchain at hand,
> so
> uncompiled, untested.
>
> @Nicolas, Xi (cc, ref: http://thread.gmane.org/gmane.linux.kernel/1481464):
>
> If there is someday support for other archs as well, it would be nice if we
> do not have each time duplicated seccomp_jit_compile() etc functions in each
> JIT implementation, i.e. because they do basically the same. So follow-up
> {fix,clean}up is appreciated.
>
> Also, I find it a bit weird that seccomp_filter_get_len() and some other
> _one-line_ functions from kernel/seccomp.c are not placed into the
> corresponding header file as inlines.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
2013-04-26 22:18 ` Xi Wang
@ 2013-04-26 22:30 ` Daniel Borkmann
2013-04-26 23:33 ` David Miller
1 sibling, 0 replies; 7+ messages in thread
From: Daniel Borkmann @ 2013-04-26 22:30 UTC (permalink / raw)
To: Xi Wang
Cc: Andrew Morton, Arnd Bergmann, Nicolas Schichan, Will Drewry,
Mircea Gherzan, linux-kernel, linux-arm-kernel, Russell King,
David S. Miller, Daniel Borkmann, netdev
On 04/27/2013 12:18 AM, Xi Wang wrote:
> Thanks for CCing. One way to clean up this would be to refactor the
> bpf jit interface as:
>
> bpf_func_t bpf_jit_compile(struct sock_filter *filter, unsigned int flen);
> void bpf_jit_free(bpf_func_t bpf_func);
>
> Then both packet and seccomp filters can share the unified interface.
> Also, we don't need seccomp_filter_get_len() and other helpers.
>
> Do you want me to rebase my patch against linux-next and see how that goes?
Sure, whatever works for you. Not sure if it will still make it though.
Also, as Eric already mentioned earlier, please do not top-post your mails!
I think one reminder should be sufficient for that. ;-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter.
2013-04-26 22:18 ` Xi Wang
2013-04-26 22:30 ` Daniel Borkmann
@ 2013-04-26 23:33 ` David Miller
1 sibling, 0 replies; 7+ messages in thread
From: David Miller @ 2013-04-26 23:33 UTC (permalink / raw)
To: xi.wang
Cc: wad, arnd, nschichan, netdev, linux-kernel, daniel.borkmann,
mgherzan, dborkman, linux, akpm, linux-arm-kernel
Please stop top-posting.
Thank you.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-04-26 23:33 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1366824429-26652-1-git-send-email-nschichan@freebox.fr>
[not found] ` <1366824429-26652-3-git-send-email-nschichan@freebox.fr>
2013-04-24 17:41 ` [PATCH V3 2/3] ARM: net: bpf_jit: make code generation less dependent on struct sk_filter Daniel Borkmann
[not found] ` <3592414.M8kQZLCXlW@wuerfel>
[not found] ` <20130426122601.10ec05fcb4860df1b0a5b409@linux-foundation.org>
2013-04-26 19:47 ` Daniel Borkmann
2013-04-26 20:09 ` Andrew Morton
2013-04-26 22:01 ` Daniel Borkmann
2013-04-26 22:18 ` Xi Wang
2013-04-26 22:30 ` Daniel Borkmann
2013-04-26 23:33 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).