cvs commit: src/sys/kern kern_exit.c

John Baldwin jhb at freebsd.org
Wed Oct 25 15:04:13 UTC 2006


On Tuesday 24 October 2006 18:54, David Xu wrote:
> 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.

If it works as it is now, then it is fine.  Forgot that sigqueue was
per-thread rather than per-process.

-- 
John Baldwin


More information about the cvs-all mailing list