Re: tcp_sack related panic

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Also just got this with the same sources:
:
:panic: zone: freeing free entry
:mp_lock =3D 00000000; cpuid =3D 0
:boot() called on cpu#0
:Uptime: 1d11h35m59s
:...
:#3  0xc02a6aa8 in zerror (error=3D2) at /usr/src/sys/vm/vm_zone.c:567
:#4  0xc02a6ff5 in zfree (z=3D0xd7049438, item=3D0xdb991760) at /usr/src/sys=
:/vm/vm_zone.c:98
:#5  0xc02341ac in tcp_sack_update_scoreboard (tp=3D0xdad397c0, to=3D0xdaa45=
:be8) at /usr/src/sys/netinet/tcp_sack.c:165
:#6  0xc02318d9 in tcp_input (m=3D0xeb7df200) at /usr/src/sys/netinet/tcp_in=
:put.c:1900
:#7  0xc0229ae2 in transport_processing_oncpu (m=3D0xeb7df200, hlen=3D20, ip=
:
:Do you think it's the same problem?

    Same sources prior to the patch?  It's quite possible.

    I tracked this second crash to line 321 of tcp_sack.c (the kgdb backtrace
    is all wrong due to all the inlining).  It's freeing 'newblock' here,
    which should always succeed at this paricular point in the code.

    I think this case can only occur if the list had previously been
    corrupted due to the hint not getting NULL'd out in those two places.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>