Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Dec 2000 06:17:40 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Matt Dillon <dillon@earth.backplane.com>, Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG, net@FreeBSD.ORG
Subject:   Re: patch to cleanup inflight desciptor handling.
Message-ID:  <3A38D684.F241D6B9@elischer.org>
References:  <200012131852.KAA17423@beastie.mckusick.com> <200012132106.eBDL6Sg86570@earth.backplane.com> <20001213141917.Q16205@fw.wintelcom.net> <20001213145341.S16205@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
> 
> * Alfred Perlstein <bright@wintelcom.net> [001213 14:20] wrote:
> > * Matt Dillon <dillon@earth.backplane.com> [001213 13:07] wrote:
> > > :I believe that your changes have been sorely needed for many
> > > :years. While I would like to see regular mbufs given a callback
> > > :mechanism, your present approach of using an mbuf cluster
> > > :solves 90% of the problem.
> > > :
> > > :   Kirk  McKusick
> > >
> > >     ... Aflred, be careful that you don't break things we only just fixed
> > >     last year.  The descriptor passing code has been broken for many years.
> > >
> > >     I think the reason we have to scan the descriptor list is related to
> > >     locating isolated self-referential 'loops' with descriptor passing and
> > >     unix domain sockets and closing them.  e.g. when you pass a descriptor
> > >     for a unix-domain socket through a unix-domain socket, it is possible
> > >     for the socket descriptors to reference each other and thus never have
> > >     their ref count drop to 0 even when all associated processes have
> > >     close()'d.  This happens all the time.  Be sure you don't break the
> > >     fix that solves that particular problem.
> >
> > 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.
> 
> Ok, my patch has this problem:
> 
> void
> parent(int con)
> {
>         int fd;
> 
>         fd = open("/tmp/wank", O_RDONLY);
>         send_fd_withdata(con, con, "wank", 4);
>         sleep (5);
>  exit(1);
> 
> }
> 
> void
> child(int con)
> {
>         int fd, error;
>         char    buf[100];
> 
>         sleep(5);
>         get_fd_withdata(con, &fd, buf, sizeof(buf));
>         send_fd_withdata(con, fd, "foo", 3);
> exit(1);
>         buf[4] = '\0';
>         printf("%s\n", buf);
>         if ((error = read(fd, buf, sizeof(buf))) < 0)
>                 perror("read");
>         buf[sizeof(buf)-1] = '\0';
>         printf("%s\n", buf);
> 
> 
> }
> 
> This causes a leak, I think the trick is to just always call sorflush()
> when the pcb is free'd.

that's what I was trying to point out to you....
It get's more complicate when you have 2 pipes, and each has the 
filedescriptors for the other one in it.

> 
> Looking at linux they still are using gc.  I'll give this a lot
> more thought before resubmitting this idea.
> 
> sorry,
> --
> -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> "I have the heart of a child; I keep it in a jar on my desk."
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Budapest
            v


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A38D684.F241D6B9>