Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754065AbWLXDPR (ORCPT ); Sat, 23 Dec 2006 22:15:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754070AbWLXDPR (ORCPT ); Sat, 23 Dec 2006 22:15:17 -0500 Received: from ns.theshore.net ([67.18.92.50]:49649 "EHLO www.theshore.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754065AbWLXDPP (ORCPT ); Sat, 23 Dec 2006 22:15:15 -0500 X-Greylist: delayed 445 seconds by postgrey-1.27 at vger.kernel.org; Sat, 23 Dec 2006 22:15:15 EST Message-ID: <458DEF02.90908@theshore.net> Date: Sat, 23 Dec 2006 22:07:46 -0500 From: "Christopher S. Aker" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Patrick McHardy CC: Santiago Garcia Mantinan , linux-kernel@vger.kernel.org, ebtables-devel@lists.sourceforge.net Subject: Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36 References: <20061218082413.GA11064@clandestino.aytolacoruna.es> <45890135.9000306@trash.net> In-Reply-To: <45890135.9000306@trash.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4627 Lines: 119 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 = 00000000 Oops: 0000 [#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: 00000004 ecx: f6d53e90 edx: f8ce2000 esi: f8cebfa0 edi: 0000000e ebp: 00000000 esp: f6d53e08 ds: 007b es: 007b ss: 0068 Process ebtables (pid: 4788, ti=f6d52000 task=f6d51550 task.ti=f6d52000) Stack: f6d53e40 c0540440 00000007 f6d53ebc 00000001 00000028 00000000 00000000 00000004 00000fa0 00000fd0 f8d38000 f8ce2000 f6d53e90 00000000 80000000 00000000 00000000 00000000 00000004 00000014 00000000 00000014 00000600 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 = 00000000 Oops: 0000 [#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: 00000098 ecx: c049b780 edx: 00000000 esi: f8a3afa0 edi: 0000000e ebp: 00000001 esp: d8fbbb7c ds: 007b es: 007b ss: 0068 Process ebtables (pid: 7917, threadinfo=d8fba000 task=e7892550) Stack: <0>c049b75c f8a3af78 c04468f8 d8fbbbcc c049b740 00000007 d8fbbc68 d30f4260 000000d2 d8fba000 d30f4240 d8fba000 00000028 00000004 00000000 00000004 00000000 00000fa0 00000fd0 f8a8e000 00000000 f8a38000 00000000 00000000 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 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/