Date: Wed, 18 Apr 2001 18:26:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: arch@freebsd.org Subject: Reference counters Message-ID: <200104181826.LAA17706@usr02.primenet.com>
index | next in thread | raw e-mail
As some people undoubtedly know, I've been fighting a bug with
credential reference counts, which appears to be related to a
close race under extreme load.
The architecture of the reference counting is extremely
incompatible with tracking this bug down.
I would like to propose that the reference counting be
substantially changed, and that a general philosophy be
adopted in place of the current philosophy.
First, some minor discussion.
--
Here code from kern/kern_descrip.c:
fsetown()
crhold(curproc->p_ucred);
sigio->sio_ucred = curproc->p_ucred;
falloc()
fp->f_cred = p->p_ucred;
fp->f_ops = &badfileops;
fp->f_seqcount = 1;
crhold(fp->f_cred);
kern/uipc_socket2.c:
sonewconn3()
so->so_cred = p ? p->p_ucred : head->so_cred;
crhold(so->so_cred);
kern/uipc_socket.c:
socreate()
so->so_cred = p->p_ucred;
crhold(so->so_cred);
kern/kern_fork.c:
fork1()
MALLOC(p2->p_cred, struct pcred *, sizeof(struct pcred),
M_SUBPROC, M_WAITOK);
bcopy(p1->p_cred, p2->p_cred, sizeof(*p2->p_cred));
p2->p_cred->p_refcnt = 1;
crhold(p1->p_ucred);
uihold(p1->p_cred->p_uidinfo);
--------------
Except for this last code (which is amazingly distressing to me;
it's probably going to turn out to be the ultimate source of the
problem I'm seeing), this code lends itself to cleanup; specifically:
fsetown()
sigio->sio_ucred = crhold(curproc->p_ucred);
falloc()
fp->f_ops = &badfileops;
fp->f_seqcount = 1;
fp->f_cred = crhold(p->p_ucred);
sonewconn3()
so->so_cred = p ? crhold(p->p_ucred) : crhold(head->so_cred);
etc..
This would let the crhold() function be replaced with a resource
tracking macro version. This would let me identify the instance
of the reference allocation which is being doubly freed somewhere
in my list of 30,000 descriptors, and -- more important -- with
instrumentation, permit me to identify the origin allocation.
Specifically, I can relace crhold() with crdup(), and I get the
actual double free that's the problem, instead of the last free).
I further siggest that _ALL_ reference holds in FreeBSD receive
similar treatment.
Discussion?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104181826.LAA17706>