On Fri, 16 Jan 2004 itojun_at_iijlab.net wrote: > this does not help me repeat the symptom. could you cook up a shell > script which panics your box? (if possible, only with setkey) reproducing with setkey only should not be possible from my current understanding. one needs at least some other SP "consumers". I have identified to always have a delta of 54 SPs allocated (when no change is in progress) in my setup; these are: - 2 persistent from key.c (ip4_def, ip6_def) - 2 persistent from ipsec.c (PCB in, out) - 18 in my SPD (from setkey spdadd) - 2 grabed by inetd on startup and released on kill - 30 grabed by racoon on startup and released on kill w/o any of the 3 patches from either you or me all SPs not in sptree and not persitient will be free(9)ed too early and marked dead with the first spdflush. While your patch prevents them from being free(9)ed too early it will still mark them dead. This is addressed in my last last patch at the end of my last (somewhat gushing) mail. As said I could not find a reason for marking them dead but this is up for discussion. I haven't tested the following script yet but I hope it will do the trick for you on NetBSD (please change 127.0.0.1 to s.th. appropriate if needed). --- cut --- #!/bin/sh set -x IP_NO_ON_THIS_BOX=127.0.0.1 # either racoon(30) or inetd(2) aquire some SP (struct secpolicy) here # that are only in sptailq and not in sptree /usr/sbin/inetd -l -wW -C 60 /usr/local/sbin/racoon -f /path/to/racoon.conf # let things settle sleep 3 # just flush your SPD though there are no entries in; # w/o whichever of the three patches this will decrement refcnt # of those entries not in sptree but only in sptailq by one and mark # them dead leading to a too early free(9) (last after killing the # daemons if refcnt had been >1). # setkey -DPF # let things settle sleep 3 # this should lead to a memory modified after free situation kill `cat /var/run/inetd.pid` /usr/bin/killall racoon ping -f $IP_NO_ON_THIS_BOX --- cut --- At least if testing on FreeBSD have INVARIANTS support in your kernel for uma_dbg_alloc et al (don't know about NetBSD). -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/Received on Mon Jan 19 2004 - 13:07:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:39 UTC