Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
On Mon, Dec 25, 2006 at 11:42:32PM -0500, Chuck Ebbert wrote: > ebtables: don't compute gap until we know we have an ebt_entry > > We must check the bitmap field to make sure we have an ebt_entry and > not an ebt_entries struct before using fields from ebt_entry. > > Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> Acked-by: Al Viro <[EMAIL PROTECTED]> My fault. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
Sorry for not replying before but I could not do any tests before today as I didn't have access to any of the machines. > Bingo! Yes, I can confirm that your patch solves the problem, at least on my test cases. Thanks for your help! Regards... -- Santiago García Mantiñán - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 23 Dec 2006 22:07:46 -0500, Christopher S. Aker wrote:
> We're hitting this too, on both 2.6.16.36 and 2.6.19.1.
>
> BUG: unable to handle kernel paging request at virtual address f8cec008
> printing eip:
> c0462272
> *pde =
> Oops: [#1]
> SMP
> Modules linked in: e1000
> CPU:1
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010286 (2.6.19.1-1-bigmem #1)
> EIP is at translate_table+0x2b3/0xddf
> Considering I've never had these problems before, and that both stable
> (2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to
> guess that it's something that went into both of them very recently.
Bingo!
It is dying here:
static inline int
ebt_check_entry(struct ebt_entry *e, struct ebt_table_info *newinfo,
const char *name, unsigned int *cnt, unsigned int valid_hooks,
struct ebt_cl_stack *cl_s, unsigned int udc_cnt)
{
struct ebt_entry_target *t;
struct ebt_target *target;
unsigned int i, j, hook = 0, hookmask = 0;
size_t gap = e->next_offset - e->target_offset; <
int ret;
/* don't mess with the struct ebt_entries */
if (e->bitmask == 0)
return 0;
when trying to access e->next_offset, which may or may not exist because
'e' sometimes points to a 'struct ebt_entries', not 'struct ebt_entry'
(note the comment before the 'if'.) This code was recently added.
So this (untested) patch should fix it (I tried to move the computation to
a place where it's efficient.) If so it's needed for 2.6.16.x, 2.6.18.x,
2.6.19.x and 2.6.20-rc.
ebtables: don't compute gap until we know we have an ebt_entry
We must check the bitmap field to make sure we have an ebt_entry and
not an ebt_entries struct before using fields from ebt_entry.
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
--- 2.6.19.1-32smp.orig/net/bridge/netfilter/ebtables.c
+++ 2.6.19.1-32smp/net/bridge/netfilter/ebtables.c
@@ -575,7 +575,7 @@ ebt_check_entry(struct ebt_entry *e, str
struct ebt_entry_target *t;
struct ebt_target *target;
unsigned int i, j, hook = 0, hookmask = 0;
- size_t gap = e->next_offset - e->target_offset;
+ size_t gap;
int ret;
/* don't mess with the struct ebt_entries */
@@ -625,6 +625,7 @@ ebt_check_entry(struct ebt_entry *e, str
if (ret != 0)
goto cleanup_watchers;
t = (struct ebt_entry_target *)(((char *)e) + e->target_offset);
+ gap = e->next_offset - e->target_offset;
target = find_target_lock(t->u.name, &ret, &ebt_mutex);
if (!target)
goto cleanup_watchers;
--
MBTI: IXTP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
Christopher S. Aker wrote:
Patrick McHardy wrote:
I'm trying to reproduce this (without success so far), please send your
kernel config and your ebtables script.
You could try if 2.6.19 works, there were some ebtables changes in
2.6.19.1 that touched this code.
We're hitting this too, on both 2.6.16.36 and 2.6.19.1.
BUG: unable to handle kernel paging request at virtual address f8cec008
printing eip:
c0462272
*pde =
Oops: [#1]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.19.1-1-bigmem #1)
EIP is at translate_table+0x2b3/0xddf
eax: f8ce2000 ebx: 0004 ecx: f6d53e90 edx: f8ce2000
esi: f8cebfa0 edi: 000e ebp: esp: f6d53e08
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000)
Stack: f6d53e40 c0540440 0007 f6d53ebc 0001 0028
0004 0fa0 0fd0 f8d38000 f8ce2000 f6d53e90
8000
0004 0014 0014
0600
Call Trace:
[] do_replace+0x113/0x6da
[] get_page_from_freelist+0x8c/0xa8
[] do_ebt_set_ctl+0x2d/0x2e
[] nf_sockopt+0xfa/0xfc
[] nf_setsockopt+0x23/0x2b
[] ip_setsockopt+0x86/0x91
[] sock_common_setsockopt+0x23/0x2f
[] sys_setsockopt+0x61/0xac
[] sys_socketcall+0x1e9/0x249
[] do_page_fault+0x0/0x664
[] sysenter_past_esp+0x56/0x79
[] svc_recv+0x9c/0x3f5
===
Code: 30 3b 28 0f 83 5c 02 00 00 8b 54 24 30 8b 74 24 24 8b 4c 24 34 8b
5c 24 4c 03 72 24 8b 79 20 89 5c 24 20 c7 44 24 1c 00 00 00 00 <8b> 56
68 8b 46 6c 29 d0 31 d2 89 44 24 14 8b 06 85 c0 0f 84 f7
EIP: [] translate_table+0x2b3/0xddf SS:ESP 0068:f6d53e08
Unable to handle kernel paging request at virtual address f8a3b00c
printing eip:
c03cce45
*pde =
Oops: [#13]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.16.36-1-bigmem #1)
EIP is at translate_table+0x47b/0xfc2
eax: d8fbbc3c ebx: 0098 ecx: c049b780 edx:
esi: f8a3afa0 edi: 000e ebp: 0001 esp: d8fbbb7c
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550)
Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 0007 d8fbbc68
d30f4260
00d2 d8fba000 d30f4240 d8fba000 0028 0004
0004
0fa0 0fd0 f8a8e000 f8a38000
Call Trace:
[] do_replace+0x16b/0x887
[] copy_everything_to_user+0x21a/0x35c
[] do_ebt_set_ctl+0x40/0x42
[] nf_sockopt+0x11f/0x121
[] nf_setsockopt+0x37/0x3b
[] ip_setsockopt+0x3f9/0xb0e
[] nf_sockopt+0xad/0x121
[] nf_getsockopt+0x37/0x3b
[] ip_getsockopt+0x5bd/0x62b
[] current_fs_time+0x5d/0x78
[] touch_atime+0x7d/0xcd
[] zap_pte_range+0xf1/0x316
[] unmap_page_range+0x103/0x174
[] prio_tree_remove+0x77/0xe7
[] buffered_rmqueue+0x155/0x209
[] buffered_rmqueue+0x155/0x209
[] get_page_from_freelist+0x8c/0xa6
[] get_page_from_freelist+0x8c/0xa6
[] __alloc_pages+0x56/0x309
[] page_add_file_rmap+0x2a/0x2c
[] do_anonymous_page+0x122/0x22a
[] __handle_mm_fault+0x138/0x326
[] sock_common_setsockopt+0x33/0x37
[] sys_setsockopt+0x6c/0xb2
[] sys_socketcall+0x1f4/0x254
[] do_page_fault+0x0/0x630
[] sysenter_past_esp+0x54/0x75
Code: 24 8b bc 24 8c 00 00 00 8b 84 24 88 00 00 00 8b 54 24 64 8b 74 24
44 03 77 24 8b 78 20 c7 44 24 38 00 00 00 00 89 54 24 3c 31 d2 <8b> 4e
6c 8b 5e 68 29 d9 89 4c 24 30 8b 06 85 c0 0f 84 14 02 00
It seems to happen when flushing a user-defined ebtable, or removing a
rule -- but not every time. It leaves the ebtable userspace process in D
state on 2.6.19.1 but not on 2.6.16.36 (?).
Considering I've never had these problems before, and that both stable
(2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to
guess that it's something that went into both of them very recently.
Just a follow-up -- this doesn't happen with 2.6.19.
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36
Patrick McHardy wrote:
I'm trying to reproduce this (without success so far), please send your
kernel config and your ebtables script.
You could try if 2.6.19 works, there were some ebtables changes in
2.6.19.1 that touched this code.
We're hitting this too, on both 2.6.16.36 and 2.6.19.1.
BUG: unable to handle kernel paging request at virtual address f8cec008
printing eip:
c0462272
*pde =
Oops: [#1]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.19.1-1-bigmem #1)
EIP is at translate_table+0x2b3/0xddf
eax: f8ce2000 ebx: 0004 ecx: f6d53e90 edx: f8ce2000
esi: f8cebfa0 edi: 000e ebp: esp: f6d53e08
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000)
Stack: f6d53e40 c0540440 0007 f6d53ebc 0001 0028
0004 0fa0 0fd0 f8d38000 f8ce2000 f6d53e90
8000
0004 0014 0014
0600
Call Trace:
[] do_replace+0x113/0x6da
[] get_page_from_freelist+0x8c/0xa8
[] do_ebt_set_ctl+0x2d/0x2e
[] nf_sockopt+0xfa/0xfc
[] nf_setsockopt+0x23/0x2b
[] ip_setsockopt+0x86/0x91
[] sock_common_setsockopt+0x23/0x2f
[] sys_setsockopt+0x61/0xac
[] sys_socketcall+0x1e9/0x249
[] do_page_fault+0x0/0x664
[] sysenter_past_esp+0x56/0x79
[] svc_recv+0x9c/0x3f5
===
Code: 30 3b 28 0f 83 5c 02 00 00 8b 54 24 30 8b 74 24 24 8b 4c 24 34 8b
5c 24 4c 03 72 24 8b 79 20 89 5c 24 20 c7 44 24 1c 00 00 00 00 <8b> 56
68 8b 46 6c 29 d0 31 d2 89 44 24 14 8b 06 85 c0 0f 84 f7
EIP: [] translate_table+0x2b3/0xddf SS:ESP 0068:f6d53e08
Unable to handle kernel paging request at virtual address f8a3b00c
printing eip:
c03cce45
*pde =
Oops: [#13]
SMP
Modules linked in: e1000
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.16.36-1-bigmem #1)
EIP is at translate_table+0x47b/0xfc2
eax: d8fbbc3c ebx: 0098 ecx: c049b780 edx:
esi: f8a3afa0 edi: 000e ebp: 0001 esp: d8fbbb7c
ds: 007b es: 007b ss: 0068
Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550)
Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 0007 d8fbbc68
d30f4260
00d2 d8fba000 d30f4240 d8fba000 0028 0004
0004
0fa0 0fd0 f8a8e000 f8a38000
Call Trace:
[] do_replace+0x16b/0x887
[] copy_everything_to_user+0x21a/0x35c
[] do_ebt_set_ctl+0x40/0x42
[] nf_sockopt+0x11f/0x121
[] nf_setsockopt+0x37/0x3b
[] ip_setsockopt+0x3f9/0xb0e
[] nf_sockopt+0xad/0x121
[] nf_getsockopt+0x37/0x3b
[] ip_getsockopt+0x5bd/0x62b
[] current_fs_time+0x5d/0x78
[] touch_atime+0x7d/0xcd
[] zap_pte_range+0xf1/0x316
[] unmap_page_range+0x103/0x174
[] prio_tree_remove+0x77/0xe7
[] buffered_rmqueue+0x155/0x209
[] buffered_rmqueue+0x155/0x209
[] get_page_from_freelist+0x8c/0xa6
[] get_page_from_freelist+0x8c/0xa6
[] __alloc_pages+0x56/0x309
[] page_add_file_rmap+0x2a/0x2c
[] do_anonymous_page+0x122/0x22a
[] __handle_mm_fault+0x138/0x326
[] sock_common_setsockopt+0x33/0x37
[] sys_setsockopt+0x6c/0xb2
[] sys_socketcall+0x1f4/0x254
[] do_page_fault+0x0/0x630
[] sysenter_past_esp+0x54/0x75
Code: 24 8b bc 24 8c 00 00 00 8b 84 24 88 00 00 00 8b 54 24 64 8b 74 24
44 03 77 24 8b 78 20 c7 44 24 38 00 00 00 00 89 54 24 3c 31 d2 <8b> 4e
6c 8b 5e 68 29 d9 89 4c 24 30 8b 06 85 c0 0f 84 14 02 00
It seems to happen when flushing a user-defined ebtable, or removing a
rule -- but not every time. It leaves the ebtable userspace process in D
state on 2.6.19.1 but not on 2.6.16.36 (?).
Considering I've never had these problems before, and that both stable
(2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to
guess that it's something that went into both of them very recently.
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
