Date: Thu, 14 Dec 2000 23:08:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: dillon@earth.backplane.com (Matt Dillon), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <200012142308.QAA15345@usr08.primenet.com> In-Reply-To: <20001213141917.Q16205@fw.wintelcom.net> from "Alfred Perlstein" at Dec 13, 2000 02:19:18 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, I'll see if that can happen. Basically since the reference
> never goes to zero on the socket, the buffers are never forced to
> be flushed/cleared and the mbuf will then never be free'd resulting
> it it leaking itself. Basically a socket hanging there with an
> mbuf referencing itself.
>
> I wonder if Linux fixed/has this problem.
SVR4 and Solaris avoid the problem entirely by ensuring that
each reference to a vnode pointer counts as an "open", and
the vnode can not be discarded until a 1->0 reference count
change (grep for VHOLD/VRELE/VREF in the Solaris headers).
This also makes it easier to do kernel level file I/O, since
all you need is a vp that has a reference added to it, and
you aren't stuck needing a process so that you can have an
open file table so you can hold a descriptor reference. A
trade off to this approach is that you have to supply the
offset on reads and writes, instead of assuming advancement
of an automatically maintained f_offset value. That's
actually a positive, in my book.
So when you are passing the fd, you are actually passing a
vp; this is not aproblem, since the semantics are equivalent
to "dup", not "dup2", so you don't get to pick your target
descriptor, anyway.
One real PITA that you will see, if you get into this code
at all, is that the lock references don't get reassigned, so
they all go away ("POSIX me _harder_!") when the passer does
the close, which is probably the wrong thing.
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-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012142308.QAA15345>