Date: Wed, 25 Oct 2006 06:54:11 +0800 From: David Xu <davidxu@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_exit.c Message-ID: <200610250654.11455.davidxu@freebsd.org> In-Reply-To: <200610241430.12149.jhb@freebsd.org> References: <200610212359.k9LNxF2P014387@repoman.freebsd.org> <200610240647.03765.davidxu@freebsd.org> <200610241430.12149.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 25 October 2006 02:30, John Baldwin wrote: > On Monday 23 October 2006 18:47, David Xu wrote: > > On Monday 23 October 2006 23:33, John Baldwin wrote: > > > On Saturday 21 October 2006 19:59, David Xu wrote: > > > > davidxu 2006-10-21 23:59:15 UTC > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > sys/kern kern_exit.c > > > > Log: > > > > Since revision 1.333 of kern_sig.c no longer uses P_WEXIT, the > > > > change opened a race window which can cause memory leak in signal > > > > queue. Here we free memory for signal queue when process state is set > > > > to PRS_ZOMBIE. > > > > > > Is there any reason to not just harvest it in wait() instead? > > > > I prefer to free it earlier rather than delaying it if I can. > > But we already do the free'ing "later" (wait() really isnt' all that later > than exit1() for most processes) for sigacts, limits, etc. It would seem > that sigqueue and sigacts would have nearly identical lifetimes. But if system is under heavily memory loaded, doesn't freeing it earlier make it better ? sigqueue does not have safe lifetime as sigacts, every thread has it, we check signal queue leak in thread_exit(), if you move the sigqueue_flush into wait1, then that code also has to be adjusted, because now not every thread will free the memory when it is exited, they no long have consistent behavior. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610250654.11455.davidxu>