Messages in this thread | | | Date | Mon, 25 Oct 1999 15:29:38 -0400 | From | Richard Guy Briggs <> | Subject | calling skb_queue_purge() causes oops when called from FreeS/WAN under 2.2.x |
| |
Beg of your time to help debug this bewildering bug...
I am in the process of implementing PF_KEYv2 sockets in the kernel. It is a socket interface between one or more userspace keying daemons and a key-consuming kernel in the same machine. I had previously gotten it to work under 2.0.36 kernels. I notice there are significant changes in the kernel socket implementation support from 2.0.xx to 2.2.xx.
I thought I had figured out everything to change, but I'm having problems with closing sockets from userspace. When I close a socket from userspace, the kernel machinery calls pfkey_release(), similarly to most other socket drivers. I used af_unix, af_appletalk, af_inet/udp, af_netlink as examples. First, I check sk->dead, then call sk->state_change(), then call sklist_remove_socket() to take it out of the socket list, then try to dequeue all of the skb's from sk->receive_queue and kfree_skb() any that I find. At this point it will oops with:
Unable to handle kernel NULL pointer dereference at virtual address 00000008 current->tss.cr3 = 0052e000, %cr3 = 0052e000 *pde = 00000000. Entering kdb due to panic @ 0xc011e768 eax = 0xc17ea97c ebx = 0xc1fff080 ecx = 0x00000000 edx = 0xc1d48c40 esi = 0xc17ea940 edi = 0x00000202 esp = 0xc1d292a0 eip = 0xc011e768 ebp = 0xc073fee4 ss = 0xc1d48c40 cs = 0x00000010 eflags = 0x00010082 ds = 0x00000018 es = 0x00000018 origeax = 0xffffffff ®s = 0xc073fe98 kdb> bt EBP EIP Function(args) 0xc073fee4 0xc011e768 kfree+0x74( 0xc17ea940) 0xc073fef4 0xc01504b9 kfree_skbmem+0x25( 0xc1d292a0) 0xc073ff08 0xc0150581 __kfree_skb+0xa5( 0xc1d292a0) 0xc073ff1c 0xc014ff40 sklist_destroy_socket+0x60( 0xc284c540, 0xc1d48c40, 0xc042919c, 0xc0429100, 0xc073ff48) 0xc073ff34 0xc283c404 ipsec_rcv+0x1e60( 0xc042919c, 0x0) 0xc073ff48 0xc014dead sock_release+0x21( 0xc042919c) 0xc073ff58 0xc014e24b sock_close+0x27( 0xc0429100, 0xc0f13920) 0xc073ff74 0xc0122579 __fput+0x21( 0xc0f13920, 0xc0f13920) 0xc073ff88 0xc0123671 fput+0x19( 0xc0f13920) 0xc073ffa0 0xc01225f5 filp_close+0x51( 0xc0f13920, 0xc1e8e2a0) 0xc073ffbc 0xc0122661 sys_close+0x5d( 0x3, 0x80503b0, 0x4, 0x8050420, 0x804cae3) 0xbffff928 0xc0107b18 system_call kdb> id 0xc011e768 kfree+0x74: movl 0x8(%ecx),%edx kfree+0x77: movl %edx,0xfffffffc(%ebp) kfree+0x7a: cmpl $0xa5c32f2b,%edx kfree+0x80: jne kfree+0x154 kfree+0x86: movl 0xc(%ecx),%eax kfree+0x89: movl %eax,0xfffffffc(%ebp) kfree+0x8c: testl %eax,%eax kfree+0x8e: je kfree+0x10c kfree+0x90: decl %eax kfree+0x91: movl %eax,0xc(%ecx) kfree+0x94: movl (%ecx),%edx kfree+0x96: movl 0xfffffff8(%ebp),%eax kfree+0x99: movl %edx,(%eax) kfree+0x9b: movl %eax,(%ecx) kfree+0x9d: cmpl $0x0,(%eax) kfree+0xa0: je kfree+0xe0
I am really baffled by this. It always comes up with the same first line, which I don't completely understand: Unable to handle kernel NULL pointer dereference at virtual address 00000008
What baffles me even more is the fact that it works fine under 2.0.xx and the other examples in the 2.2.x kernel seem to work fine too. I have compared initialisation code on all these as well to see if I am forgetting something, but have run out of ideas.
Unfortunately I have to caution people about U.S. crypto-export restrictions. If you are a U.S. citizen or are in the U.S. please be careful what you post. Please send responses to this list. For those with a curiosity, the code is at:
ftp.xs4all.nl/pub/crypto/freeswan/snapshot.tar.gz
in file:
klips/net/ipsec/pfkey_v2.c
A sampling of the contents of the offending skb's look something like:
Oct 22 21:34:11 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6f080 stamp:0.536577 dev:c01defd8 dev->name:lo h:c1e0a820 nh:c0d3486c mac:c0d3485e dst:00000000 len:2 csum:-665534469 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c1e0a820 data:c1e0a820 tail:c1e0a822 end:c1e0a830 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b2:17: 0: 0 destructor:c014fb6c
Oct 22 21:36:30 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6fb80 stamp:0.993496 dev:c01defd8 dev->name:lo h:c1a0a260 nh:c0d34cec mac:c0d34cde dst:00000000 len:10 csum:-1981392342 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c1a0a260 data:c1a0a260 tail:c1a0a26a end:c1a0a270 data: 2: 3: 0: 9: a: 0: 0: 0: 1: 0: 0: 0:fa:18: 0: 0 destructor:c014fb6c
Oct 24 16:40:17 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6f340 stamp:0.94254 dev:c01deef8 dev->name:eth0 h:c1f87900 nh:c03efca0 mac:c03efc92 dst:00000000 len:2 csum:1808618379 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:1544 security:0 truesize:16 head:c1f87900 data:c1f87900 tail:c1f87902 end:c1f87910 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:39:22: 0: 0 destructor:c014fb6c
Oct 24 16:40:29 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c0a6f600 stamp:0.373500 dev:c01defd8 dev->name:lo h:c17dc340 nh:c1fbdbcc mac:c1fbdbbe dst:00000000 len:2 csum:0 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c17dc340 data:c17dc340 tail:c17dc342 end:c17dc350 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:f8:22: 0: 0 destructor:c014fb6c
Oct 24 16:54:53 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c03fac40 stamp:0.786748 dev:c01deef8 dev->name:eth0 h:c1591100 nh:c03ff400 mac:c03ff3f2 dst:00000000 len:2 csum:759554798 used:1 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:1544 security:0 truesize:16 head:c1591100 data:c1591100 tail:c1591102 end:c1591110 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b4:24: 0: 0 destructor:c014fb6c
Oct 24 16:58:40 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c1febd00 stamp:0.0 dev:00000000 dev->name:NULL h:c14733e0 nh:00000000 mac:00000000 dst:00000000 len:2 csum:0 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:0 security:0 truesize:16 head:c14733e0 data:c14733e0 tail:c14733e2 end:c14733f0 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b1: 1: 0: 0 destructor:c014fb6c
Oct 25 11:46:22 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c08bd6c0 stamp:0.31530 dev:c01defd8 dev->name:lo h:c1473920 nh:c1113f10 mac:c1113f02 dst:00000000 len:2 csum:1885630317 used:114 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:8 security:0 truesize:16 head:c1473920 data:c1473920 tail:c1473922 end:c1473930 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:2d: 7: 0: 0 destructor:c014fb6c
Oct 25 11:49:07 gonzales kernel: klips_debug: pfkey_skb contents: next:00000000 prev:00000000 list:00000000 sk:c1febd00 stamp:0.0 dev:00000000 dev->name:NULL h:c14733e0 nh:00000000 mac:00000000 dst:00000000 len:2 csum:0 used:0 is_clone:0 cloned:0 pkt_type:0 pkt_bridged:0 ip_summed:0 priority:0 protocol:0 security:0 truesize:16 head:c14733e0 data:c14733e0 tail:c14733e2 end:c14733f0 data: 2: 9: 0: 0: 2: 0: 0: 0: 1: 0: 0: 0:b1: 1: 0: 0 destructor:c014fb6c
There is always one packet in the queue and it usually has a size of 2, 8 or 16.
I have my doubts about the ownership of these packets. The packets we deal with are 80, 104, 112 octets, never 2! The other thing that bothers me is that there seems to be a device associated with them, such as loopback or eth0. The loopback device makes some sense, but eth0 definitely does not.
Why might these packets be ending up in our receive queue?
Why are they so small?
Why are they crashing kfree_skb()?
Any insights would be most helpful.
slainte mhath, RGB -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada <http://www.conscoop.ottawa.on.ca/rgb/> </www.flora.org/afo/> Prevent Internet Wiretapping! -- FreeS/WAN:<www.xs4all.nl/~freeswan> Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk> [unhandled content-type:application/pgp-signature] | |