Date: Mon, 23 Jul 2018 17:01:46 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: Matt Macy <mmacy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336596 - in head/sys/netinet: . cc Message-ID: <932986e5-ee47-fdc9-abb8-dd0b26dcfe6a@freebsd.org> In-Reply-To: <201807220537.w6M5bwTh005574@repo.freebsd.org> References: <201807220537.w6M5bwTh005574@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22/07/2018 15:37, Matt Macy wrote: > Author: mmacy > Date: Sun Jul 22 05:37:58 2018 > New Revision: 336596 > URL: https://svnweb.freebsd.org/changeset/base/336596 > > Log: > NULL out cc_data in pluggable TCP {cc}_cb_destroy > > When ABE was added (rS331214) to NewReno and leak fixed (rS333699) , it now has > a destructor (newreno_cb_destroy) for per connection state. Other congestion > controls may allocate and free cc_data on entry and exit, but the field is > never explicitly NULLed if moving back to NewReno which only internally > allocates stateful data (no entry contstructor) resulting in a situation where > newreno_cb_destory might be called on a junk pointer. > > - NULL out cc_data in the framework after calling {cc}_cb_destroy > - free(9) checks for NULL so there is no need to perform not NULL checks > before calling free. > - Improve a comment about NewReno in tcp_ccalgounload > > This is the result of a debugging session from Jason Wolfe, Jason Eggleston, > and mmacy@ and very helpful insight from lstewart@. > > Submitted by: Kevin Bowling > Reviewed by: lstewart > Sponsored by: Limelight Networks > Differential Revision: https://reviews.freebsd.org/D16282 Pointy hat to: lstewart Apologies for the bug and thanks for fixing. Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?932986e5-ee47-fdc9-abb8-dd0b26dcfe6a>