Date: Mon, 23 Jan 2006 14:55:47 -0500 From: John Baldwin <jhb@freebsd.org> To: Stephan Uphoff <ups@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 kern_resource.c Message-ID: <200601231455.49892.jhb@freebsd.org> In-Reply-To: <200601231915.k0NJFDE7080866@repoman.freebsd.org> References: <200601231915.k0NJFDE7080866@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 23 January 2006 14:15, Stephan Uphoff wrote: > ups 2006-01-23 19:15:13 UTC > > FreeBSD src repository > > Modified files: > sys/kern kern_exit.c kern_resource.c > Log: > Hopefully fix the "calcru: runtime went backwards from ..." problem by > keeping the resource values locked (where needed) while we use them > for calculations. > > MFC after: 3 days Why expand the locking in calcru()? calcru1() is working with a static rusage_ext on calcru()'s stack, not the one for process p that is generated while sched_lock is held. The 'p' for calcru1() is only used for printfs, no actual data is taken from p. I think the ruadd() change might be the only fix needed, though I think the updating of p->p_stats->p_ru.ru_nvcsw and p->p_ru needs to be deferred as well since the race you seem to be fixing is the case where exit1() is preempted, but with the current change you'd still have stale data in p->p_ru (since it is a copy of p->p_stats->p_ru, not a pointer) unless you move the updating of p->p_ru down to just before the ruadd() as it was previously. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601231455.49892.jhb>