Date: Mon, 16 Feb 2004 10:00:29 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Jails that keep hanging around Message-ID: <Pine.NEB.3.96L.1040216095603.63057G-100000@fledge.watson.org> In-Reply-To: <20040216133617.GD14639@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Feb 2004, Pawel Jakub Dawidek wrote: > Yeah, there is a cred leak and I am the one who track it down!:) > > http://garage.freebsd.pl/patches/tcp_subr.c.patch > > Don't do 'jls' just after killing 'nc', because cred will be freed after > timeout, so wait few minutes and then try 'jls'. > > If there is no objections I'm going to commit it tomorrow. Nice catch -- looks like that has been there since the introduction of reduced state time wait in early 2003. That was never merged to RELENG_4, so isn't present there. One request -- NULL the tw_cred pointer as is done with the other fields, so that if there is a failure to initialize it propery later, we get a panic instead of something less predictable. As you point out, this is actually a relatively benign leak in most systems, because credentials are reference counted copy-on-write, and relatively small data structures. In most cases, there are relatively few unique credentials floating around the system, and they are heavily reused. Each time a jail is created, it results in several credential modifications (one for the jail system call, then the setuid/etc calls during the setup of processes in the jails), increasing the chances a leak will be noticed, especially now that we have a tool to list instances of ojects referenced by credentials. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040216095603.63057G-100000>