Messages in this thread | | | Date | Wed, 27 Oct 1999 16:53:12 +0100 (BST) | From | Peter Onion <> | Subject | RE: linux-ipsec: calling skb_queue_purge() causes oops when call |
| |
Richard, have you got this fixed yet as I've been away a few days and not seen any more info on the list about it ?
If not then I'll put my mind to the problem tomorrow morning (thursday) and see what I can find....
Peter.
On 25-Oct-99 Richard Guy Briggs wrote: > 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>
---------------------------------- E-Mail: Peter Onion <ponion@srd.bt.co.uk> Date: 27-Oct-99 Time: 16:51:51
This message was sent by XFMail ----------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |