Subject: Re: IPSEC still fails on BETA2/vax (not anymore!)
To: Olaf Seibert <rhialto@polderland.nl>
From: Jaromir Dolecek <jdolecek@netbsd.org>
List: port-vax
Date: 07/18/2002 12:21:38
There are couple of quite bulky items on stack in the nfs mount
function call path. Making them use MALLOC() should save couple
hundred bytes of stack. That should make it, since the only
significant stack usage of ipsec-related functions on the stacktrace
is in rndpool_extract_data(), and it should be less that what can
be saved within nfs mount code.

Jaromir

Olaf Seibert wrote:
> On Mon 15 Jul 2002 at 13:09:43 +0200, Jaromir Dolecek wrote:
> > BTW, can you try -current (1.6D) kernel without your stack size
> > changes? There was a fix to kernel stack usage for IPsec committed
> > not too long ago, and the fix has not been pulled up to 1.6 branch
> > yet.
> 
> I tried it just now (source supped 15 july). The results are better than
> with the unmodified 1.5ZC kernel: ESP ping traffic works now without
> overflowing the interrupt stack. The NFS mount however still overflows
> the kernel stack with the following backtrace:
> 
> bash-2.04# mount /vol1
> panic: kernel stack invalid
> Stopped in pid 170 (mount_nfs) at       trap+0x174:     tstl    64(r8)
> db> tr
> panic: kernel stack invalid
> Stack traceback :
> 0x80336b34: trap+0x174(0x80336bb4)
> 0x80336bb4: trap type=0xf code=0x0 pc=0x8012a96c psl=0xcc0008
> 0x80336b80: SHA1Transform+0x15a(0x8aae94f4,0x8aae9510)
> 0x8aae9470: SHA1Update+0x66(0x8aae94f4,0x801904ac,0x200)
> 0x8aae94a8: rndpool_extract_data+0x5a(0x80190484,0x886822f0,0x8,0)
> 0x8aae9550: rnd_extract_data+0x23(0x886822f0,0x8,0)
> 0x8aae9590: key_randomfill+0x1a(0x886822f0,0x8)
> 0x8aae95bc: key_sa_stir_iv+0x25(0x88694380)
> 0x8aae95e8: esp_cbc_encrypt+0x457(0x80dc2200,0x14,0x68,0x88694380,0x801648a0,0x8
> )
> 0x8aae9648: esp_output+0x60b(0x80dc2200,0x80dc22f5,0x81ecd100,0x88602a00,0x2)
> 0x8aae96c0: esp4_output+0x42(0x80dc2200,0x88602a00)
> 0x8aae9704: ipsec4_output+0x22f(0x8aae97a4,0x8868b240,0)
> 0x8aae9728: ip_output+0x637(0x81ecd100,0,0x81372384,0,0)
> 0x8aae97c8: udp_output+0x19a(0x80dc2900,0x81372364)
> 0x8aae980c: udp_usrreq+0x1ca(0x8139967c,0x9,0x80dc2900,0x805d3500,0,0x81f7871c)
> 0x8aae9844: sosend+0x4b3(0x8139967c,0x805d3500,0,0x80dc2900,0,0)
> 0x8aae98a8: nfs_send+0x87(0x8139967c,0x805d3500,0x80dc2900,0x88696300)
> 0x8aae98f0: nfs_request+0x2a6(0x80d10034,0x80dc2a00,0x13,0x81f7871c,0x8867ca00,0
> x8aae99d4,0x8aae99d8,0x8aae99dc)
> 0x8aae997c: nfs_fsinfo+0x1e3(0x88602200,0x80d10034,0x8867ca00,0x81f7871c)
> 0x8aae99e8: nfs_bioread+0x80(0x80d10034,0x8aae9bb0,0,0x8867ca00,0x1)
> 0x8aae9acc: nfs_readdir+0x65(0x8aae9b50)
> 0x8aae9b1c: VOP_READDIR+0x4f(0x80d10034,0x8aae9bb0,0x8867ca00,0x8aae9b9c,0x8aae9
> ba0,0x8aae9ba4)
> 0x8aae9b6c: nfs_cookieheuristic+0x6f(0x80d10034,0x886023c0,0x81f7871c,0x8867ca00
> )
> 0x8aae9bd0: mountnfs+0x1f8(0x8aae9dc8,0x88685000,0x805d3500,0x8aae9d6c,0x8aae9d1
> 0,0x8aae9cc4,0x81f7871c)
> 0x8aae9c78: nfs_mount+0x135(0x88685000,0x7ffffca9,0x7ffffacc,0x8aae9e58,0x81f787
> 1c)
> 0x8aae9e10: sys_mount+0x2dc(0x81f7871c,0x8aae9f60,0x8aae9f58)
> 0x8aae9f14: syscall+0x10f(0x8aae9fb4)
> db> 
> 
> I wonder how close the interrupt stack comes to overflowing - I don't
> suppose there is an easy way to determine this. Perhaps I can pre-fill
> it with known data and then examine it periodically. How do I break into
> ddb from the serial console on a VAX? I find code in vax/vsa/lkc.c for a
> graphics console (ctrl-alt-esc) - perhaps I'll need to add that too.
> 
> > Jaromir
> -Olaf.
> -- 
> ___ Olaf 'Rhialto' Seibert - rhialto@       -- Woe betide the one who feels
> \X/ polderland.nl  -- remorse without sin - Tom Poes, "Het boze oog", 4444.
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-