From owner-freebsd-current@FreeBSD.ORG Mon Jan 19 14:07:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6863D16A4CE; Mon, 19 Jan 2004 14:07:35 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6925A43D45; Mon, 19 Jan 2004 14:07:33 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id A51471FF91D; Mon, 19 Jan 2004 23:07:31 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id EE8801FF90C; Mon, 19 Jan 2004 23:07:29 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 4C6A7153CA; Mon, 19 Jan 2004 22:07:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 417A415380; Mon, 19 Jan 2004 22:07:09 +0000 (UTC) Date: Mon, 19 Jan 2004 22:07:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Jun-ichiro itojun Hagino In-Reply-To: <20040116064434.22DF98C@coconut.itojun.org> Message-ID: References: <20040116064434.22DF98C@coconut.itojun.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: core@kame.net cc: Hajimu UMEMOTO cc: "Bjoern A. Zeeb" cc: FreeBSD current mailing list Subject: Re: [PATCH] IPSec fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2004 22:07:35 -0000 On Fri, 16 Jan 2004 itojun@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/