Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Wed, 24 Apr 2013 17:52:34 +0200 Nicolas Schichan
wrote:
> > btw, what on earth is going on with seccomp_jit_free()? It does
> > disturbing undocumented typecasting and it punts the module_free into a
> > kernel thread for mysterious, undocumented and possibly buggy reasons.
> >
> > I realize it just copies bpf_jit_free(). The same observations apply there.
>
> The reason for this hack for both seccomp filters and socket filters is that
> {seccomp,bpf}_jit_free are called from a softirq. module_free() cannot be
> called directly from softirq, as it will in turn call vfree() which will
> BUG_ON() if in_interrupt() is non zero. So to call module_free(), it is
> therefore required to be in a process context, which is provided by the work
> struct.
Well let's explain this to the next sucker who comes along.
From: Andrew Morton
Subject: bpf: add comments explaining the schedule_work() operation
Cc: Will Drewry
Cc: Mircea Gherzan
Cc: Nicolas Schichan
Cc: Russell King
Cc: "David S. Miller"
Cc: Daniel Borkmann
Signed-off-by: Andrew Morton
---
arch/arm/net/bpf_jit_32.c |8
arch/powerpc/net/bpf_jit_comp.c |4
arch/s390/net/bpf_jit_comp.c|4
arch/sparc/net/bpf_jit_comp.c |4
arch/x86/net/bpf_jit_comp.c |4
5 files changed, 24 insertions(+)
diff -puN arch/arm/net/bpf_jit_32.c~a arch/arm/net/bpf_jit_32.c
--- a/arch/arm/net/bpf_jit_32.c~a
+++ a/arch/arm/net/bpf_jit_32.c
@@ -958,6 +958,10 @@ void bpf_jit_free(struct sk_filter *fp)
struct work_struct *work;
if (fp->bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
work = (struct work_struct *)fp->bpf_func;
INIT_WORK(work, bpf_jit_free_worker);
@@ -985,6 +989,10 @@ void seccomp_jit_free(struct seccomp_fil
void *bpf_func = seccomp_filter_get_bpf_func(fp);
if (bpf_func != sk_run_filter) {
+ /*
+* seccomp_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
work = (struct work_struct *)bpf_func;
INIT_WORK(work, bpf_jit_free_worker);
diff -puN arch/sparc/net/bpf_jit_comp.c~a arch/sparc/net/bpf_jit_comp.c
--- a/arch/sparc/net/bpf_jit_comp.c~a
+++ a/arch/sparc/net/bpf_jit_comp.c
@@ -817,6 +817,10 @@ static void jit_free_defer(struct work_s
void bpf_jit_free(struct sk_filter *fp)
{
if (fp->bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
struct work_struct *work = (struct work_struct *)fp->bpf_func;
INIT_WORK(work, jit_free_defer);
diff -puN arch/powerpc/net/bpf_jit_comp.c~a arch/powerpc/net/bpf_jit_comp.c
--- a/arch/powerpc/net/bpf_jit_comp.c~a
+++ a/arch/powerpc/net/bpf_jit_comp.c
@@ -699,6 +699,10 @@ static void jit_free_defer(struct work_s
void bpf_jit_free(struct sk_filter *fp)
{
if (fp->bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
struct work_struct *work = (struct work_struct *)fp->bpf_func;
INIT_WORK(work, jit_free_defer);
diff -puN arch/s390/net/bpf_jit_comp.c~a arch/s390/net/bpf_jit_comp.c
--- a/arch/s390/net/bpf_jit_comp.c~a
+++ a/arch/s390/net/bpf_jit_comp.c
@@ -818,6 +818,10 @@ void bpf_jit_free(struct sk_filter *fp)
if (fp->bpf_func == sk_run_filter)
return;
+ /*
+* bpf_jit_free() can be called from softirq; module_free() requires
+* process context.
+*/
work = (struct work_struct *)fp->bpf_func;
INIT_WORK(work, jit_free_defer);
schedule_work(work);
diff -puN arch/x86/net/bpf_jit_comp.c~a arch/x86/net/bpf_jit_comp.c
--- a/arch/x86/net/bpf_jit_comp.c~a
+++ a/arch/x86/net/bpf_jit_comp.c
@@ -749,6 +749,10 @@ static void jit_free_defer(struct work_s
void bpf_jit_free(struct sk_filter *fp)
{
if (fp->bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
struct work_struct *work = (struct work_struct *)fp->bpf_func;
INIT_WORK(work, jit_free_defer);
diff -puN include/linux/filter.h~a include/linux/filter.h
diff -puN net/core/filter.c~a net/core/filter.c
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On 04/24/2013 01:43 AM, Andrew Morton wrote:
On Mon, 22 Apr 2013 14:31:20 +0200 Nicolas Schichan
wrote:
Would including instead of in seccomp.h
be an acceptable solution ?
I have tried that and (with an additional forward declaration of struct
sk_buff) an x86_64 "make clean; make allmodconfig" run finishes succesfully.
If that's ok with you, I can resend the serie with that fix.
It would be better to make the code and include tangle less complex,
rather than more complex.
Did we really need to move the `struct seccomp_filter' definition into
the header file? afaict that wasn't really necessary - we can add a
few helper functions to kernel/seccomp.c and then have the remote code
treat seccomp_filter in an opaque fashion rather than directly poking
at its internals.
Hi,
I will resend a V3 of the patch serie with the accessors.
btw, what on earth is going on with seccomp_jit_free()? It does
disturbing undocumented typecasting and it punts the module_free into a
kernel thread for mysterious, undocumented and possibly buggy reasons.
I realize it just copies bpf_jit_free(). The same observations apply there.
The reason for this hack for both seccomp filters and socket filters is that
{seccomp,bpf}_jit_free are called from a softirq. module_free() cannot be
called directly from softirq, as it will in turn call vfree() which will
BUG_ON() if in_interrupt() is non zero. So to call module_free(), it is
therefore required to be in a process context, which is provided by the work
struct.
Here is the call stack for the socket filter case:
[] (vfree+0x28/0x2c) from [] (bpf_jit_free+0x10/0x18)
[] (bpf_jit_free+0x10/0x18) from
[](sk_filter_release_rcu+0x10/0x1c)
[] (sk_filter_release_rcu+0x10/0x1c) from []
(__rcu_process_callbacks+0x98/0xac)
[] (__rcu_process_callbacks+0x98/0xac) from []
(rcu_process_callbacks+0x10/0x20)
[] (rcu_process_callbacks+0x10/0x20) from []
(__do_softirq+0xbc/0x194)
[] (__do_softirq+0xbc/0x194) from []
(run_ksoftirqd+0x40/0x64)
[] (run_ksoftirqd+0x40/0x64) from []
(smpboot_thread_fn+0x150/0x15c)
[] (smpboot_thread_fn+0x150/0x15c) from []
(kthread+0xa4/0xb0)
[] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x24)
Here is the call stack for the seccomp filter case:
[] (vfree+0x28/0x2c) from [] (put_seccomp_filter+0x6c/0x84)
[] (put_seccomp_filter+0x6c/0x84) from []
(free_task+0x30/0x50)
[] (free_task+0x30/0x50) from []
(__rcu_process_callbacks+0x98/0xac)
[] (__rcu_process_callbacks+0x98/0xac) from []
(rcu_process_callbacks+0x10/0x20)
[] (rcu_process_callbacks+0x10/0x20) from []
(__do_softirq+0xbc/0x194)
[] (__do_softirq+0xbc/0x194) from []
(run_ksoftirqd+0x40/0x64)
[] (run_ksoftirqd+0x40/0x64) from []
(smpboot_thread_fn+0x150/0x15c)
[] (smpboot_thread_fn+0x150/0x15c) from []
(kthread+0xa4/0xb0)
[] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x24)
Regards,
--
Nicolas Schichan
Freebox SAS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On 04/24/2013 01:43 AM, Andrew Morton wrote:
On Mon, 22 Apr 2013 14:31:20 +0200 Nicolas Schichan nschic...@freebox.fr
wrote:
Would including uapi/linux/filter.h instead of linux/filter.h in seccomp.h
be an acceptable solution ?
I have tried that and (with an additional forward declaration of struct
sk_buff) an x86_64 make clean; make allmodconfig run finishes succesfully.
If that's ok with you, I can resend the serie with that fix.
It would be better to make the code and include tangle less complex,
rather than more complex.
Did we really need to move the `struct seccomp_filter' definition into
the header file? afaict that wasn't really necessary - we can add a
few helper functions to kernel/seccomp.c and then have the remote code
treat seccomp_filter in an opaque fashion rather than directly poking
at its internals.
Hi,
I will resend a V3 of the patch serie with the accessors.
btw, what on earth is going on with seccomp_jit_free()? It does
disturbing undocumented typecasting and it punts the module_free into a
kernel thread for mysterious, undocumented and possibly buggy reasons.
I realize it just copies bpf_jit_free(). The same observations apply there.
The reason for this hack for both seccomp filters and socket filters is that
{seccomp,bpf}_jit_free are called from a softirq. module_free() cannot be
called directly from softirq, as it will in turn call vfree() which will
BUG_ON() if in_interrupt() is non zero. So to call module_free(), it is
therefore required to be in a process context, which is provided by the work
struct.
Here is the call stack for the socket filter case:
[c0087bf8] (vfree+0x28/0x2c) from [c001fc5c] (bpf_jit_free+0x10/0x18)
[c001fc5c] (bpf_jit_free+0x10/0x18) from
[c0231188](sk_filter_release_rcu+0x10/0x1c)
[c0231188] (sk_filter_release_rcu+0x10/0x1c) from [c0060bb4]
(__rcu_process_callbacks+0x98/0xac)
[c0060bb4] (__rcu_process_callbacks+0x98/0xac) from [c0060bd8]
(rcu_process_callbacks+0x10/0x20)
[c0060bd8] (rcu_process_callbacks+0x10/0x20) from [c0029498]
(__do_softirq+0xbc/0x194)
[c0029498] (__do_softirq+0xbc/0x194) from [c00295b0]
(run_ksoftirqd+0x40/0x64)
[c00295b0] (run_ksoftirqd+0x40/0x64) from [c0041954]
(smpboot_thread_fn+0x150/0x15c)
[c0041954] (smpboot_thread_fn+0x150/0x15c) from [c003bb2c]
(kthread+0xa4/0xb0)
[c003bb2c] (kthread+0xa4/0xb0) from [c0013450] (ret_from_fork+0x14/0x24)
Here is the call stack for the seccomp filter case:
[c0087c28] (vfree+0x28/0x2c) from [c0060834] (put_seccomp_filter+0x6c/0x84)
[c0060834] (put_seccomp_filter+0x6c/0x84) from [c0020db4]
(free_task+0x30/0x50)
[c0020db4] (free_task+0x30/0x50) from [c0060be4]
(__rcu_process_callbacks+0x98/0xac)
[c0060be4] (__rcu_process_callbacks+0x98/0xac) from [c0060c08]
(rcu_process_callbacks+0x10/0x20)
[c0060c08] (rcu_process_callbacks+0x10/0x20) from [c00294c8]
(__do_softirq+0xbc/0x194)
[c00294c8] (__do_softirq+0xbc/0x194) from [c00295e0]
(run_ksoftirqd+0x40/0x64)
[c00295e0] (run_ksoftirqd+0x40/0x64) from [c0041984]
(smpboot_thread_fn+0x150/0x15c)
[c0041984] (smpboot_thread_fn+0x150/0x15c) from [c003bb5c]
(kthread+0xa4/0xb0)
[c003bb5c] (kthread+0xa4/0xb0) from [c0013450] (ret_from_fork+0x14/0x24)
Regards,
--
Nicolas Schichan
Freebox SAS
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Wed, 24 Apr 2013 17:52:34 +0200 Nicolas Schichan nschic...@freebox.fr
wrote:
btw, what on earth is going on with seccomp_jit_free()? It does
disturbing undocumented typecasting and it punts the module_free into a
kernel thread for mysterious, undocumented and possibly buggy reasons.
I realize it just copies bpf_jit_free(). The same observations apply there.
The reason for this hack for both seccomp filters and socket filters is that
{seccomp,bpf}_jit_free are called from a softirq. module_free() cannot be
called directly from softirq, as it will in turn call vfree() which will
BUG_ON() if in_interrupt() is non zero. So to call module_free(), it is
therefore required to be in a process context, which is provided by the work
struct.
Well let's explain this to the next sucker who comes along.
From: Andrew Morton a...@linux-foundation.org
Subject: bpf: add comments explaining the schedule_work() operation
Cc: Will Drewry w...@chromium.org
Cc: Mircea Gherzan mgher...@gmail.com
Cc: Nicolas Schichan nschic...@freebox.fr
Cc: Russell King li...@arm.linux.org.uk
Cc: David S. Miller da...@davemloft.net
Cc: Daniel Borkmann daniel.borkm...@tik.ee.ethz.ch
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
arch/arm/net/bpf_jit_32.c |8
arch/powerpc/net/bpf_jit_comp.c |4
arch/s390/net/bpf_jit_comp.c|4
arch/sparc/net/bpf_jit_comp.c |4
arch/x86/net/bpf_jit_comp.c |4
5 files changed, 24 insertions(+)
diff -puN arch/arm/net/bpf_jit_32.c~a arch/arm/net/bpf_jit_32.c
--- a/arch/arm/net/bpf_jit_32.c~a
+++ a/arch/arm/net/bpf_jit_32.c
@@ -958,6 +958,10 @@ void bpf_jit_free(struct sk_filter *fp)
struct work_struct *work;
if (fp-bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
work = (struct work_struct *)fp-bpf_func;
INIT_WORK(work, bpf_jit_free_worker);
@@ -985,6 +989,10 @@ void seccomp_jit_free(struct seccomp_fil
void *bpf_func = seccomp_filter_get_bpf_func(fp);
if (bpf_func != sk_run_filter) {
+ /*
+* seccomp_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
work = (struct work_struct *)bpf_func;
INIT_WORK(work, bpf_jit_free_worker);
diff -puN arch/sparc/net/bpf_jit_comp.c~a arch/sparc/net/bpf_jit_comp.c
--- a/arch/sparc/net/bpf_jit_comp.c~a
+++ a/arch/sparc/net/bpf_jit_comp.c
@@ -817,6 +817,10 @@ static void jit_free_defer(struct work_s
void bpf_jit_free(struct sk_filter *fp)
{
if (fp-bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
struct work_struct *work = (struct work_struct *)fp-bpf_func;
INIT_WORK(work, jit_free_defer);
diff -puN arch/powerpc/net/bpf_jit_comp.c~a arch/powerpc/net/bpf_jit_comp.c
--- a/arch/powerpc/net/bpf_jit_comp.c~a
+++ a/arch/powerpc/net/bpf_jit_comp.c
@@ -699,6 +699,10 @@ static void jit_free_defer(struct work_s
void bpf_jit_free(struct sk_filter *fp)
{
if (fp-bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
struct work_struct *work = (struct work_struct *)fp-bpf_func;
INIT_WORK(work, jit_free_defer);
diff -puN arch/s390/net/bpf_jit_comp.c~a arch/s390/net/bpf_jit_comp.c
--- a/arch/s390/net/bpf_jit_comp.c~a
+++ a/arch/s390/net/bpf_jit_comp.c
@@ -818,6 +818,10 @@ void bpf_jit_free(struct sk_filter *fp)
if (fp-bpf_func == sk_run_filter)
return;
+ /*
+* bpf_jit_free() can be called from softirq; module_free() requires
+* process context.
+*/
work = (struct work_struct *)fp-bpf_func;
INIT_WORK(work, jit_free_defer);
schedule_work(work);
diff -puN arch/x86/net/bpf_jit_comp.c~a arch/x86/net/bpf_jit_comp.c
--- a/arch/x86/net/bpf_jit_comp.c~a
+++ a/arch/x86/net/bpf_jit_comp.c
@@ -749,6 +749,10 @@ static void jit_free_defer(struct work_s
void bpf_jit_free(struct sk_filter *fp)
{
if (fp-bpf_func != sk_run_filter) {
+ /*
+* bpf_jit_free() can be called from softirq; module_free()
+* requires process context.
+*/
struct work_struct *work = (struct work_struct *)fp-bpf_func;
INIT_WORK(work, jit_free_defer);
diff -puN include/linux/filter.h~a include/linux/filter.h
diff -puN net/core/filter.c~a net/core/filter.c
_
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, 22 Apr 2013 14:31:20 +0200 Nicolas Schichan wrote: > On 04/17/2013 11:56 PM, Andrew Morton wrote: > > This patch is killing me. > > > >> --- a/include/linux/seccomp.h > >> +++ b/include/linux/seccomp.h > >> @@ -6,6 +6,7 @@ > >> #ifdef CONFIG_SECCOMP > >> > >> #include > >> +#include > >> #include > > > > In file included from include/linux/compat.h:18, > > from include/linux/filter.h:9, > > from include/linux/seccomp.h:9, > > from include/linux/sched.h:39, > > from arch/x86/kernel/asm-offsets.c:9: > > /usr/src/25/arch/x86/include/asm/compat.h: In function > > 'arch_compat_alloc_user_space': > > /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer > > to incomplete type > > > > Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for > > task_struct but as you can see from the above include tree, sched.h > > includes seccomp.h and everything falls over. The preprocessed code > > contains the definition of arch_compat_alloc_user_space() *before* the > > definition of task_struct. > > > > This is a basic x86_64 "make clean; make allmodconfig; make". > > Hi, > > Would including instead of in > seccomp.h > be an acceptable solution ? > > I have tried that and (with an additional forward declaration of struct > sk_buff) an x86_64 "make clean; make allmodconfig" run finishes succesfully. > > If that's ok with you, I can resend the serie with that fix. It would be better to make the code and include tangle less complex, rather than more complex. Did we really need to move the `struct seccomp_filter' definition into the header file? afaict that wasn't really necessary - we can add a few helper functions to kernel/seccomp.c and then have the remote code treat seccomp_filter in an opaque fashion rather than directly poking at its internals. btw, what on earth is going on with seccomp_jit_free()? It does disturbing undocumented typecasting and it punts the module_free into a kernel thread for mysterious, undocumented and possibly buggy reasons. I realize it just copies bpf_jit_free(). The same observations apply there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, 22 Apr 2013 14:31:20 +0200 Nicolas Schichan nschic...@freebox.fr wrote: On 04/17/2013 11:56 PM, Andrew Morton wrote: This patch is killing me. --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -6,6 +6,7 @@ #ifdef CONFIG_SECCOMP #include linux/thread_info.h +#include linux/filter.h #include asm/seccomp.h In file included from include/linux/compat.h:18, from include/linux/filter.h:9, from include/linux/seccomp.h:9, from include/linux/sched.h:39, from arch/x86/kernel/asm-offsets.c:9: /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space': /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for task_struct but as you can see from the above include tree, sched.h includes seccomp.h and everything falls over. The preprocessed code contains the definition of arch_compat_alloc_user_space() *before* the definition of task_struct. This is a basic x86_64 make clean; make allmodconfig; make. Hi, Would including uapi/linux/filter.h instead of linux/filter.h in seccomp.h be an acceptable solution ? I have tried that and (with an additional forward declaration of struct sk_buff) an x86_64 make clean; make allmodconfig run finishes succesfully. If that's ok with you, I can resend the serie with that fix. It would be better to make the code and include tangle less complex, rather than more complex. Did we really need to move the `struct seccomp_filter' definition into the header file? afaict that wasn't really necessary - we can add a few helper functions to kernel/seccomp.c and then have the remote code treat seccomp_filter in an opaque fashion rather than directly poking at its internals. btw, what on earth is going on with seccomp_jit_free()? It does disturbing undocumented typecasting and it punts the module_free into a kernel thread for mysterious, undocumented and possibly buggy reasons. I realize it just copies bpf_jit_free(). The same observations apply there. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On 04/17/2013 11:56 PM, Andrew Morton wrote: This patch is killing me. --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -6,6 +6,7 @@ #ifdef CONFIG_SECCOMP #include +#include #include In file included from include/linux/compat.h:18, from include/linux/filter.h:9, from include/linux/seccomp.h:9, from include/linux/sched.h:39, from arch/x86/kernel/asm-offsets.c:9: /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space': /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for task_struct but as you can see from the above include tree, sched.h includes seccomp.h and everything falls over. The preprocessed code contains the definition of arch_compat_alloc_user_space() *before* the definition of task_struct. This is a basic x86_64 "make clean; make allmodconfig; make". Hi, Would including instead of in seccomp.h be an acceptable solution ? I have tried that and (with an additional forward declaration of struct sk_buff) an x86_64 "make clean; make allmodconfig" run finishes succesfully. If that's ok with you, I can resend the serie with that fix. Regards, -- Nicolas Schichan Freebox SAS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On 04/17/2013 11:56 PM, Andrew Morton wrote: This patch is killing me. --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -6,6 +6,7 @@ #ifdef CONFIG_SECCOMP #include linux/thread_info.h +#include linux/filter.h #include asm/seccomp.h In file included from include/linux/compat.h:18, from include/linux/filter.h:9, from include/linux/seccomp.h:9, from include/linux/sched.h:39, from arch/x86/kernel/asm-offsets.c:9: /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space': /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for task_struct but as you can see from the above include tree, sched.h includes seccomp.h and everything falls over. The preprocessed code contains the definition of arch_compat_alloc_user_space() *before* the definition of task_struct. This is a basic x86_64 make clean; make allmodconfig; make. Hi, Would including uapi/linux/filter.h instead of linux/filter.h in seccomp.h be an acceptable solution ? I have tried that and (with an additional forward declaration of struct sk_buff) an x86_64 make clean; make allmodconfig run finishes succesfully. If that's ok with you, I can resend the serie with that fix. Regards, -- Nicolas Schichan Freebox SAS -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, 18 Mar 2013 15:50:30 +0100 Nicolas Schichan wrote: > Architecture must select HAVE_SECCOMP_FILTER_JIT and implement > seccomp_jit_compile() and seccomp_jit_free() if they intend to support > jitted seccomp filters. > > struct seccomp_filter has been moved to to make its > content available to the jit compilation code. > > In a way similar to the net BPF, the jit compilation code is expected > to updates struct seccomp_filter.bpf_func pointer to the generated > code. > This patch is killing me. > --- a/include/linux/seccomp.h > +++ b/include/linux/seccomp.h > @@ -6,6 +6,7 @@ > #ifdef CONFIG_SECCOMP > > #include > +#include > #include In file included from include/linux/compat.h:18, from include/linux/filter.h:9, from include/linux/seccomp.h:9, from include/linux/sched.h:39, from arch/x86/kernel/asm-offsets.c:9: /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space': /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for task_struct but as you can see from the above include tree, sched.h includes seccomp.h and everything falls over. The preprocessed code contains the definition of arch_compat_alloc_user_space() *before* the definition of task_struct. This is a basic x86_64 "make clean; make allmodconfig; make". I had a few slashes at fixing it but got all frustrated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, 18 Mar 2013 15:50:30 +0100 Nicolas Schichan nschic...@freebox.fr wrote: Architecture must select HAVE_SECCOMP_FILTER_JIT and implement seccomp_jit_compile() and seccomp_jit_free() if they intend to support jitted seccomp filters. struct seccomp_filter has been moved to linux/seccomp.h to make its content available to the jit compilation code. In a way similar to the net BPF, the jit compilation code is expected to updates struct seccomp_filter.bpf_func pointer to the generated code. This patch is killing me. --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -6,6 +6,7 @@ #ifdef CONFIG_SECCOMP #include linux/thread_info.h +#include linux/filter.h #include asm/seccomp.h In file included from include/linux/compat.h:18, from include/linux/filter.h:9, from include/linux/seccomp.h:9, from include/linux/sched.h:39, from arch/x86/kernel/asm-offsets.c:9: /usr/src/25/arch/x86/include/asm/compat.h: In function 'arch_compat_alloc_user_space': /usr/src/25/arch/x86/include/asm/compat.h:301: error: dereferencing pointer to incomplete type Problem is, compat.h's arch_compat_alloc_user_space() needs sched.h for task_struct but as you can see from the above include tree, sched.h includes seccomp.h and everything falls over. The preprocessed code contains the definition of arch_compat_alloc_user_space() *before* the definition of task_struct. This is a basic x86_64 make clean; make allmodconfig; make. I had a few slashes at fixing it but got all frustrated. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, Apr 1, 2013 at 4:53 PM, Kees Cook wrote: > On Mon, Mar 18, 2013 at 7:50 AM, Nicolas Schichan > wrote: >> Architecture must select HAVE_SECCOMP_FILTER_JIT and implement >> seccomp_jit_compile() and seccomp_jit_free() if they intend to support >> jitted seccomp filters. >> >> struct seccomp_filter has been moved to to make its >> content available to the jit compilation code. >> >> In a way similar to the net BPF, the jit compilation code is expected >> to updates struct seccomp_filter.bpf_func pointer to the generated >> code. >> >> Signed-off-by: Nicolas Schichan > > Acked-by: Kees Cook > > I'd love to see this for x86 too. I suspect it'd be a small change > after this series lands. Agreed - and thanks for working through the necessary changes! Acked-By: Will Drewry (for the series) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, Apr 1, 2013 at 4:53 PM, Kees Cook keesc...@chromium.org wrote: On Mon, Mar 18, 2013 at 7:50 AM, Nicolas Schichan nschic...@freebox.fr wrote: Architecture must select HAVE_SECCOMP_FILTER_JIT and implement seccomp_jit_compile() and seccomp_jit_free() if they intend to support jitted seccomp filters. struct seccomp_filter has been moved to linux/seccomp.h to make its content available to the jit compilation code. In a way similar to the net BPF, the jit compilation code is expected to updates struct seccomp_filter.bpf_func pointer to the generated code. Signed-off-by: Nicolas Schichan nschic...@freebox.fr Acked-by: Kees Cook keesc...@chromium.org I'd love to see this for x86 too. I suspect it'd be a small change after this series lands. Agreed - and thanks for working through the necessary changes! Acked-By: Will Drewry w...@chromium.org (for the series) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, Mar 18, 2013 at 7:50 AM, Nicolas Schichan wrote: > Architecture must select HAVE_SECCOMP_FILTER_JIT and implement > seccomp_jit_compile() and seccomp_jit_free() if they intend to support > jitted seccomp filters. > > struct seccomp_filter has been moved to to make its > content available to the jit compilation code. > > In a way similar to the net BPF, the jit compilation code is expected > to updates struct seccomp_filter.bpf_func pointer to the generated > code. > > Signed-off-by: Nicolas Schichan Acked-by: Kees Cook I'd love to see this for x86 too. I suspect it'd be a small change after this series lands. Thanks, -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/3] seccomp: add generic code for jitted seccomp filters.
On Mon, Mar 18, 2013 at 7:50 AM, Nicolas Schichan nschic...@freebox.fr wrote: Architecture must select HAVE_SECCOMP_FILTER_JIT and implement seccomp_jit_compile() and seccomp_jit_free() if they intend to support jitted seccomp filters. struct seccomp_filter has been moved to linux/seccomp.h to make its content available to the jit compilation code. In a way similar to the net BPF, the jit compilation code is expected to updates struct seccomp_filter.bpf_func pointer to the generated code. Signed-off-by: Nicolas Schichan nschic...@freebox.fr Acked-by: Kees Cook keesc...@chromium.org I'd love to see this for x86 too. I suspect it'd be a small change after this series lands. Thanks, -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
