From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: CLUSTERIP and UML crash, was [Re: --dport in uml crash] Date: Tue, 24 Oct 2006 16:24:32 +0200 Message-ID: <453E2220.3090506@trash.net> References: <1161644625.8705.16.camel@LAPTOP4.MSHOME> <453D4D6C.5050508@trash.net> <1161680257.8705.31.camel@LAPTOP4.MSHOME> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org Return-path: To: oan@frozentux.net In-Reply-To: <1161680257.8705.31.camel@LAPTOP4.MSHOME> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Oskar Andreasson wrote: > Hi Patrick, > > I'm sorry for the delayed reply, I had to get some sleep. The original > problem seems to have been caused by compiling iptables-1.3.6 against > libc6 and then running against an old libc5. It works flawless now that > they are both the correct version. > > However, I got another kernel panic from the CLUSTERIP target > (possibly?). If not, please let me know where to get this info to:) > > server1:~# iptables -A INPUT -d 192.168.0.5 -p tcp --dport 4444 -j > CLUSTERIP --new --hashmode sourceip --clustermac 01:00:00:00:00:20 > --total-nodes 1 --local-node 1 > ip_tables: (C) 2000-2006 Netfilter Core Team > Kernel panic - not syncing: Kernel mode fault at addr 0xa0be74, ip > 0x400d8cbe > > EIP: 0073:[<400d8cbe>] CPU: 0 Not tainted ESP: 007b:bfb31118 EFLAGS: > 00200246 > Not tainted > EAX: ffffffda EBX: 00000000 ECX: 40019000 EDX: 00000400 > ESI: 08050ef0 EDI: 4014e6c0 EBP: bfb3112c DS: 007b ES: 007b > a0bc3728: [] notifier_call_chain+0x28/0x50 > a0bc3744: [] panic+0x50/0x100 > a0bc375c: [] segv+0x203/0x2d0 > a0bc3804: [] segv_handler+0x92/0x110 > a0bc3828: [] segv_handler+0x0/0x110 > a0bc382c: [] sig_handler_common_skas+0xa8/0xe0 > a0bc3854: [] sig_handler+0x4a/0x60 > a0bc38ac: [] vsnprintf+0x396/0x590 > a0bc38dc: [] maybe_map+0x70/0xb0 > a0bc38e4: [] maybe_map+0x29/0xb0 > a0bc3908: [] copy_chunk_to_user+0x0/0x30 > a0bc390c: [] do_op_one_page+0x1e/0x60 > a0bc3924: [] do_buffer_op+0x156/0x1b0 > a0bc3934: [] copy_chunk_to_user+0x0/0x30 > a0bc3948: [] set_signals+0x25/0x30 > a0bc3954: [] kmem_cache_alloc+0x2e/0x50 > a0bc3968: [] proc_alloc_inode+0x41/0x80 > a0bc3984: [] get_new_inode_fast+0x25/0xe0 > a0bc39c0: [] proc_get_inode+0xfd/0x180 > a0bc39c8: [] d_rehash+0x3b/0x40 > a0bc39d8: [] proc_lookup+0x97/0xa0 > a0bc3a00: [] maybe_map+0x29/0xb0 > a0bc3a24: [] copy_chunk_to_user+0x0/0x30 > a0bc3a28: [] do_op_one_page+0x1e/0x60 > a0bc3a40: [] do_buffer_op+0x92/0x1b0 > a0bc3a50: [] copy_chunk_to_user+0x0/0x30 > a0bc3a5c: [] copy_chunk_to_user+0x0/0x30 > a0bc3a7c: [] setjmp_wrapper+0x34/0x40 > a0bc3a9c: [] setjmp_wrapper+0x18/0x40 > a0bc3aac: [] link_path_walk+0x64/0xe0 > a0bc3ac8: [] strncpy_from_user_skas+0x9d/0x120 > a0bc3ad8: [] strncpy_chunk_from_user+0x0/0x60 > a0bc3b28: [] vsnprintf+0x351/0x590 > a0bc3b74: [] seq_printf+0x28/0x50 > a0bc3b90: [] print_unload_info+0x52/0xd0 > a0bc3bb0: [] m_show+0x31/0xa0 > a0bc3bd8: [] seq_read+0xc3/0x340 > a0bc3c0c: [] vfs_read+0xf2/0x1e0 > a0bc3c38: [] sys_read+0x38/0x80 > a0bc3c60: [] handle_syscall+0xf7/0x1d0 > a0bc3c7c: [] sys_read+0x0/0x80 > a0bc3cb4: [] userspace+0x1c8/0x2e0 > a0bc3cec: [] ____call_usermodehelper+0x0/0xc0 > a0bc3cfc: [] ____call_usermodehelper+0x0/0xc0 > a0bc3d04: [] new_thread_handler+0x9a/0xb0 > a0bc3d48: [] new_thread_handler+0x0/0xb0 > a0bc3d5c: [] kill+0x11/0x20 This looks UML module-load related. The command works fine here (with -i interface, otherwise it complains about a missing device). Does it also happen with other auto-loaded modules or when manually loading ipt_CLUSTERIP?