Date: Thu, 10 Nov 2011 23:15:08 +0200 From: Mikolaj Golub <trociny@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: "ps -e" without procfs(5) Message-ID: <867h378ysj.fsf@kopusha.home.net> In-Reply-To: <86zkg5h175.fsf@in138.ua3> (Mikolaj Golub's message of "Wed, 09 Nov 2011 15:31:26 %2B0200") References: <86vcr21agm.fsf@kopusha.home.net> <20111105135801.GT50300@deviant.kiev.zoral.com.ua> <86ehxmpogp.fsf@kopusha.home.net> <20111105154443.GB50300@deviant.kiev.zoral.com.ua> <86ehxmjsza.fsf@kopusha.home.net> <20111105194553.GK50300@deviant.kiev.zoral.com.ua> <8662iyjof9.fsf@kopusha.home.net> <20111106181041.GH50300@deviant.kiev.zoral.com.ua> <86r51iqoad.fsf@kopusha.home.net> <20111109124455.GW50300@deviant.kiev.zoral.com.ua> <20111109125329.GX50300@deviant.kiev.zoral.com.ua> <86zkg5h175.fsf@in138.ua3>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 09 Nov 2011 15:31:26 +0200 Mikolaj Golub wrote:
MG> On Wed, 9 Nov 2011 14:53:29 +0200 Kostik Belousov wrote:
>>> And now you return success and nothing gets copied out for the process
>>> in P_INEXEC state. Either you should return an error like EAGAIN, or
>>> consider the P_INEXEC state as transitional and wait till process
>>> leaves it. Or, ignore the state as it was before, and return whatever
>>> error proc_rwmem generated (my preference).
KB>> Forgot to say that the check does not change much because you drop
KB>> process lock immediately after the check, so the process may enter
KB>> the INEXEC state right after the check. I believe you already tried
KB>> to do this with P_WEXIT.
MG> Good point :-). Although after adding the P_INEXEC I have not seen errors any
MG> more, while before they were often (when running 'procstat -ca' in loop and
MG> building world simultaneously). Thus it looks like the probability is much
MG> smaller.
MG> So, it still looks good for me to check for P_INEXEC and return EAGAIN, and
MG> add the comment why we do this and that it still racy. But if you still think
MG> that ignoring the state is the best option no problems for me to return it
MG> back.
Realted to this, sysctl_kern_proc_kstack() looks like has the similar issue.
But it returns ESRCH instead.
/* XXXRW: Not clear ESRCH is the right error during proc execve(). */
if (p->p_flag & P_WEXIT || p->p_flag & P_INEXEC) {
PROC_UNLOCK(p);
return (ESRCH);
}
...
_PHOLD(p);
PROC_UNLOCK(p);
--
Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?867h378ysj.fsf>