From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264514AbUESTsi (ORCPT ); Wed, 19 May 2004 15:48:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264518AbUESTsi (ORCPT ); Wed, 19 May 2004 15:48:38 -0400 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]:53703 "EHLO av8-1-sn3.vrr.skanova.net") by vger.kernel.org with ESMTP id S264514AbUESTse (ORCPT ); Wed, 19 May 2004 15:48:34 -0400 Message-ID: <40ABBA0F.5050805@ringstrom.mine.nu> Date: Wed, 19 May 2004 21:48:31 +0200 From: =?UTF-8?B?VG9iaWFzIFJpbmdzdHLDtm0=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, Christophe Saout Subject: IPsec/crypto kernel panic in 2.6.[456] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I get a kernel panic that is very easy to reproduce. The panic goes away if I revert the following changeset ("fix in-place de/encryption bug with highmem"): http://linux.bkbits.net:8080/linux-2.5/cset@1.1371.476.15 I have not analyzed the code closely, so I cannot say for certain that there is a problem with that specific changeset, and I'm certainly not out to blame anyone, but reverting it at least seems to fix the problem. The panic occurs when I receive more than a little TCP data in an IPsec ESP tunnel. I'm of course willing to test patches or provide further info if required. [Please CC me because I'm not subscribed to the list.] /Tobias Unable to handle kernel paging request at virtual address 77d89bb3 printing eip: e38c230d *pde = 00000000 Oops: 0002 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010216 (2.6.6) EIP is at des_small_fips_decrypt+0x96d/0x9a0 [des] eax: 0030f000 ebx: 00030f00 ecx: 1b24b797 edx: ba4d7f77 esi: dcf91438 edi: 77d89bb3 ebp: c040fbb0 esp: c040fb5c ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c040e000 task=c0386a40) Stack: 77d89bb3 dcf91330 da6e4458 e38c28ed dcf91438 77d89bb3 c040fbf0 77d89bb3 c040fbf0 c01e7623 dcf91330 77d89bb3 c040fbf0 c01e7373 c040fbf2 dec77000 00000006 c040fb94 c040fbf0 000004a0 00000008 c040fc50 c01e7513 dcf91304 Call Trace: [] des3_ede_decrypt+0x2d/0x70 [des] [] cbc_process+0x63/0x170 [] scatterwalk_copychunks+0x83/0xd0 [] crypt+0x153/0x200 [] des3_ede_decrypt+0x0/0x70 [des] [] dst_output+0x0/0x30 [] ip_push_pending_frames+0x344/0x420 [] dst_output+0x0/0x30 [] cbc_decrypt+0x48/0x50 [] des3_ede_decrypt+0x0/0x70 [des] [] cbc_process+0x0/0x170 [] esp_input+0x1fb/0x500 [esp4] [] esp_input+0x11e/0x500 [esp4] [] kfree_skbmem+0x24/0x30 [] xfrm_state_lookup+0x5b/0x70 [] xfrm4_rcv_encap+0xee/0x4a0 [] ip_finish_output2+0xb2/0x1d0 [] ipt_do_table+0x294/0x380 [] nf_hook_slow+0xd2/0x120 [] ip_local_deliver_finish+0x0/0x1d0 [] ipt_hook+0x37/0x40 [] xfrm4_rcv+0x17/0x20 [] ip_local_deliver_finish+0xc9/0x1d0 [] ip_local_deliver_finish+0x0/0x1d0 [] nf_hook_slow+0xd2/0x120 [] ip_local_deliver_finish+0x0/0x1d0 [] ip_local_deliver+0x217/0x240 [] ip_local_deliver_finish+0x0/0x1d0 [] ip_rcv_finish+0x1c0/0x230 [] ip_rcv_finish+0x0/0x230 [] nf_hook_slow+0xd2/0x120 [] ip_rcv_finish+0x0/0x230 [] ip_rcv+0x3b4/0x470 [] ip_rcv_finish+0x0/0x230 [] netif_receive_skb+0x150/0x190 [] process_backlog+0x6d/0x100 [] net_rx_action+0x6a/0xf0 [] __do_softirq+0x85/0x90 [] do_softirq+0x26/0x30 [] do_IRQ+0xc9/0xf0 [] default_idle+0x0/0x30 [] common_interrupt+0x18/0x20 [] default_idle+0x0/0x30 [] default_idle+0x24/0x30 [] cpu_idle+0x30/0x40 [] start_kernel+0x14d/0x170 [] unknown_bootoption+0x0/0x130 Code: 88 0f c1 e9 08 31 c2 88 4f 01 c1 e9 08 88 57 04 88 4f 02 c1 <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing