[Openswan dev] Crash in ipsec_xmit_state_delete()

Holger Kummert kummert at nentec.de
Fri Feb 18 08:58:56 EST 2011


Hello,

I'm new to this list and I have a question regarding running the Openswan 2.6.32
on Linux kernel 2.6.32, architecture is ARM IXP425. My goal is to use the hw-acceleration
of the ixp-chip.
In a first step I'm trying to use the sw-kernel-algorithms of the kernel, which worked
pretty well with Openswan 2.6.32 (with klips) and linux-kernel 2.6.27.
The ocf-module is in use.
With the newer kernel I get a crash when only one ping-packet is transported back and forth
through the tunnel:

:~# Unable to handle kernel paging request at virtual address 6b6b6cf7
pgd = c4b3c000
[6b6b6cf7] *pgd=00000000
Internal error: Oops: f3 [#1]
last sysfs file: /sys/devices/platform/i2c-gpio.0/i2c-0/0-0014/name
Modules linked in: ipsec serocco fwnet(P) fwcodec(P) trace(P) cryptosoft cryptodev(P) ocf(P) e100 
ixp4xx_hss ixp4xx_eth libphy max66xx at24 pca954x i2c_mux
CPU: 0    Tainted: P            (2.6.32.28 #8)
PC is at ipsec_xmit_state_delete+0x48/0x90 [ipsec]
LR is at poison_obj+0x40/0x50
pc : [<bf0df048>]    lr : [<c0098890>]    psr: 20000013
sp : c7821ef4  ip : 6b6b6b6b  fp : c7821f04
r10: 00000018  r9 : 0000000a  r8 : 00000006
r7 : 00000001  r6 : 00000000  r5 : c4facb38  r4 : c4facb38
r3 : 00000004  r2 : c4d8586c  r1 : 6b6b6b6b  r0 : 6b6b6b6b
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 000039ff  Table: 04b3c000  DAC: 00000017
Process ksoftirqd/0 (pid: 3, stack limit = 0xc7820260)
Stack: (0xc7821ef4 to 0xc7822000)
1ee0:                                              c4facb98 c7821f1c c7821f08
1f00: bf0dd790 bf0df00c c4facb38 000003e7 c7821f38 c7821f20 bf0e29f0 bf0dd618
1f20: 00000000 c03bde60 c03e71d8 c7821f48 c7821f3c bf0f5188 bf0e2898 c7821f60
1f40: c7821f4c c004aa70 bf0f5168 c7820000 00000100 c7821f94 c7821f64 c004a6b8
1f60: c004a9f0 c0040bfc c0040bb8 60000013 00000000 c03e71a0 00000000 00000000
1f80: 00000000 00000000 c7821fa8 c7821f98 c004a788 c004a640 c7820000 c7821fc8
1fa0: c7821fac c004aea0 c004a750 c781bf20 00000000 c004ae40 00000000 c7821ff4
1fc0: c7821fcc c0059f50 c004ae4c 00000000 00000000 c7821fd4 c7821fd4 00000000
1fe0: 00000000 00000000 00000000 c7821ff8 c0047ed8 c0059edc afed8800 a7b50300
Backtrace:
[<bf0df000>] (ipsec_xmit_state_delete+0x0/0x90 [ipsec]) from [<bf0dd790>] 
(ipsec_tunnel_xsm_complete+0x184/0x19c [ipsec])
  r4:c4facb98
[<bf0dd60c>] (ipsec_tunnel_xsm_complete+0x0/0x19c [ipsec]) from [<bf0e29f0>] (ipsec_xsm+0x164/0x190 
[ipsec])
  r5:000003e7 r4:c4facb38
[<bf0e288c>] (ipsec_xsm+0x0/0x190 [ipsec]) from [<bf0f5188>] (ipsec_ocf_skbq_process+0x2c/0x60 [ipsec])
  r6:c03e71d8 r5:c03bde60 r4:00000000
[<bf0f515c>] (ipsec_ocf_skbq_process+0x0/0x60 [ipsec]) from [<c004aa70>] (tasklet_action+0x8c/0xe0)
[<c004a9e4>] (tasklet_action+0x0/0xe0) from [<c004a6b8>] (__do_softirq+0x84/0x110)
  r5:00000100 r4:c7820000
[<c004a634>] (__do_softirq+0x0/0x110) from [<c004a788>] (do_softirq+0x44/0x60)
[<c004a744>] (do_softirq+0x0/0x60) from [<c004aea0>] (ksoftirqd+0x60/0xe4)
  r4:c7820000
[<c004ae40>] (ksoftirqd+0x0/0xe4) from [<c0059f50>] (kthread+0x80/0x88)
  r7:00000000 r6:c004ae40 r5:00000000 r4:c781bf20
[<c0059ed0>] (kthread+0x0/0x88) from [<c0047ed8>] (do_exit+0x0/0x238)
  r6:00000000 r5:00000000 r4:00000000
Code: eb3eeeb6 e5940008 e3500000 0a00000d (e590018c)
---[ end trace d04501fb2fd46b26 ]---
Kernel panic - not syncing: Fatal exception in interrupt


The loaded modules are (roughly):
~# lsmod

ipsec 342690 2 - Live 0xbf0d7000
serocco 53763 0 - Live 0xbf0c2000
cryptosoft 11819 0 - Live 0xbf059000
cryptodev 10729 1 - Live 0xbf051000 (P)
ocf 16785 3 ipsec,cryptosoft,cryptodev, Live 0xbf045000 (P)
e100 31485 0 - Live 0xbf036000
ixp4xx_hss 10620 0 - Live 0xbf02e000
ixp4xx_eth 9876 0 - Live 0xbf026000
libphy 13104 1 ixp4xx_eth, Live 0xbf01b000
max66xx 11090 0 - Live 0xbf012000
at24 4047 0 - Live 0xbf00c000
pca954x 2504 0 - Live 0xbf006000
i2c_mux 1466 1 pca954x, Live 0xbf000000
version 2


/etc/ipsec.conf

config setup
         interfaces="ipsec0=eth2:1"
         klipsdebug=none
         plutodebug=none

conn nessi01
         auto=start
         ike=aes256-sha1;modp1024
         phase2alg=aes256-sha1
         authby=secret
         left=11.0.0.1
         leftnexthop=0.0.0.0
         leftsubnet=20.0.0.0/24
         right=11.0.0.2
         rightsubnet=10.0.0.1/32
         compress=no
         dpddelay=10
         dpdtimeout=30
         dpdaction=restart


When I look at the function where the crash happens, I ask myself if
there is a wrong sequence of commands:

ipsec_xmit_state_delete (struct ipsec_xmit_state *ixs)
{
         if (unlikely (! ixs))
                 return;

         spin_lock_bh (&ixs_cache_lock);
         ixs_cache_allocated_count--;
         kmem_cache_free (ixs_cache_allocator, ixs);
#if defined(HAS_NETIF_QUEUE) || defined (HAVE_NETIF_QUEUE)
         if (ixs->dev && netif_queue_stopped(ixs->dev))
                 netif_wake_queue(ixs->dev);
#else /* defined(HAS_NETIF_QUEUE) || defined (HAVE_NETIF_QUEUE) */
         if (ixs->dev)
                 ixs->dev->tbusy = 0;
#endif /* defined(HAS_NETIF_QUEUE) || defined (HAVE_NETIF_QUEUE) */
         spin_unlock_bh (&ixs_cache_lock);
}

Isn't the kmem_cache_free()-call too early? After the free the function accesses
the freed variable 'ixs'.

When I exchange those (i.e. move the free-call after the access), I get another crash:

klips_debug:ipsec_xmit_state_delete(obj 0xc5202b38)

slab: double free detected in cache 'size-256', objp c4cfa060
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Backtrace:
[<c0099954>] (slab_put_obj+0x0/0x9c) from [<c009a520>] (free_block+0xcc/0x174)
  r9:00000002 r8:c4cfa060 r7:00000000 r6:c78006c0 r5:c7802320
r4:c4cfa000
[<c009a454>] (free_block+0x0/0x174) from [<c009b16c>] (drain_array+0xac/0xe0)
[<c009b0c0>] (drain_array+0x0/0xe0) from [<c009b208>] (cache_reap+0x68/0x134)
  r6:00000000 r5:c78006c0 r4:c7802320
[<c009b1a0>] (cache_reap+0x0/0x134) from [<c0056408>] (run_workqueue+0x98/0x118)
[<c0056370>] (run_workqueue+0x0/0x118) from [<c005653c>] (worker_thread+0xb4/0xc4)

I enabled Debugging in slab to see this.

Did anyone see this behavior before?



Many thanks in advance.

Holger


More information about the Dev mailing list