svn commit: r297742 - head/sys/netinet

[Bjoern A. Zeeb]

On Sat, 9 Apr 2016, John Baldwin wrote:

> On Saturday, April 09, 2016 12:05:24 PM Bjoern A. Zeeb wrote:
>> Author: bz
>> Date: Sat Apr  9 12:05:23 2016
>> New Revision: 297742
>> URL: https://svnweb.freebsd.org/changeset/base/297742
>>
>> Log:
>>   Mfp: r296310,r296343
>>
>>   It looks like as with the safety belt of DELAY() fastened (*) we can
>>   completely tear down and free all memory for TCP (after r281599).
>>
>>   (*) in theory a few ticks should be good enough to make sure the timers
>>   are all really gone. Could we use a better matric here and check a
>>   tcbcb count as an optimization?
>
> In theory, no amount of DELAY() is ever enough to close a theoretical race
> window.  In practice you might get lucky, but you might also panic and

Yes I do understand.  Thus saying a better metric should do the right
thing.  I am aware of the consequences of removing type stability.
Should there be reports I'll make sure that DELAY becomes something
more proper sooner than later.


> trash user data.  In the rest of the tree, we tend to prefer marking items
> as NOFREE instead of this approach putting a priority on stability and
> reliability over memory efficiency.
>
> For all of the zones that you removed NOFREE from, do you know why that was
> added in the first place (e.g. which stale pointers to pcbs could be
> referenced after free)?  Did you verify that those conditions have been
> fixed?

I did check.  I did check a few years ago (and I think you had
reviewed that; maybe it was trouble).  And the TCP bits here were
the last ones that were problematic back then.  With the changes from
r281599 this should no longer be a problem.

As for the others, a few years ago Andre already removed the NOFREE
and we unconditionally made him back the change out, which was a
mistake as otherwise some of these zones would have been "clean" for
years.  Others have had KASSERTs ensuring that on VNET stack they were
actually empty.