From owner-freebsd-current Sun Jun 16 20:15:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by hub.freebsd.org (Postfix) with ESMTP id EB08037B406 for ; Sun, 16 Jun 2002 20:15:11 -0700 (PDT) Received: from mfg1.cim.alcatel.com.au (localhost.localdomain [127.0.0.1]) by alcanet.com.au (8.12.1/8.12.1/Alcanet1.2) with ESMTP id g5H3F9CS012291 for ; Mon, 17 Jun 2002 13:15:10 +1000 Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01KJ1ECCWRN490Q4FI@cim.alcatel.com.au> for freebsd-current@freebsd.org; Mon, 17 Jun 2002 13:14:37 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.3/8.12.3) with ESMTP id g5H3F3Dp007941 for ; Mon, 17 Jun 2002 13:15:03 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.3/8.12.3/Submit) id g5H3F3XT007940 for freebsd-current@freebsd.org; Mon, 17 Jun 2002 13:15:03 +1000 (EST) Content-return: prohibited Date: Mon, 17 Jun 2002 13:15:03 +1000 From: Peter Jeremy Subject: proc-args (M_PARGS) leakage To: freebsd-current@freebsd.org Mail-Followup-To: freebsd-current@freebsd.org Message-id: <20020617131502.O680@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is -CURRENT from 7th May so it's possible the bug has been fixed, though there's nothing obvious in either the CVS commit logs or by diffing the relevant files. Having noticed that my system is paging far more than I would have expected, I went looking and found that the 'proc-args' pool was far larger than I expected. And is growing over time: gsmx07# vmstat -m|grep proc-args proc-args701802 70634K 70634K 1589264 16,32,64,128,256 [about 10 minutes delay] gsmx07# vmstat -m|grep proc-args;vmstat -m|grep proc-args proc-args702048 70652K 70652K 1589557 16,32,64,128,256 proc-args702047 70652K 70652K 1589558 16,32,64,128,256 gsmx07# Unfortunately, M_PARGS is not the easiest pool to track allocations and de-allocations. Having gone through the references to pargs_*() and p_args, I can't see any obvious cause of this. Whilst I'm fairly certain it's not my problem, sysctl_kern_proc_args() (1.136) looks dubious: ... PROC_LOCK(p); pa = p->p_args; pargs_hold(pa); PROC_UNLOCK(p); if (req->oldptr && pa != NULL) { error = SYSCTL_OUT(req, pa->ar_args, pa->ar_length); } if (req->newptr == NULL) { pargs_drop(pa); return (error); } To this point, it all looks correct: An additional reference has been added to p_args to allow the SYSCTL_OUT() to copy the arguments without them being freed. The relevant pargs entry will have a ref count of at least 2 (the original reference from 'p' and a new reference via pargs_hold()). PROC_LOCK(p); pa = p->p_args; p->p_args = NULL; PROC_UNLOCK(p); pargs_drop(pa); (And later code shows pa dead at this point). I don't follow this. pargs_drop(pa) deletes a single reference count - which matches the line "p->p_args = NULL;" - but I don't see anything to match the pargs_hold(pa) above. Additionally, whilst I'm certain it's not my problem, fill_kinfo_proc() copys a reference to pargs, but doesn't increment the reference counter (using pargs_hold()). Has anyone else bumped into this? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message