Subject: Re: squid now reveals a new kernel problem.
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Charles M. Hannum <root@ihack.net>
List: tech-net
Date: 10/28/1999 19:10:18
woods@most.weird.com (Greg A. Woods) writes:

> [ On , October 28, 1999 at 16:44:16 (-0400), Charles M. Hannum wrote: ]
> > Subject: Re: squid now reveals a new kernel problem.
> >
> > I don't see what's surprising about this.  fdalloc() put the struct
> > file (`fp') into the process's file descriptor table, but your ffree()
> > call did not remove it.  Any future operation on that file descriptor
> > -- including cleanup during process exit -- will thus walk a stale
> > pointer.
> > 
> > You should have used fdrelease() instead.
> 
> There's no call to fdalloc() -- only falloc().

That was a typo.  The point stands; you *must* remove the pointer from
the file descriptor table, which you're not doing.

> Indeed my idea to mimic the other routines and use ffree() survived
> testing twice as long in a relatively heavy production environment
> without even exhibiting any of the previous symptoms of the problem I
> was trying to solve in the first place, and only failed in a new
> scenario.

Note that sys_socket(), sys_socketpair(), sys_pipe(), sys_open() and
sys_fhopen() -- which are all the routines that use ffree() -- do this
explicitly.

In short, both your change and Darren's are clearly
in{sufficient,correct}.