lkml.org 
[lkml]   [1999]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: 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 &regs = 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:1.748 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site