Change Details

This is one result of an ongoing debugging session from Jason, Jason, and Matt which should be uncontroversial. When ABC was added to New Reno, some assumptions about the state of it as the default and always ready cc seem to have changed, notably it now has a constructor and destructor (newreno_cb_destroy) for per connection state. We are seeing a double free that seems to be related to some non-standard sysctls we use, but this patch is sufficient to solve that problem while we root cause or otherwise explain why the behavior that winds up calling the callback twice is proper. * NULL out cc_data after freeing in {cc}_cb_destroy * Check for cc_data before proceeding to act on any data in cdg_cb_destroy * free(9) checks for NULL so there is no need to perform not NULL checks before calling free.

This is one result of an ongoing debugging session from Jason, Jason, and Matt which should be uncontroversial. When ABE was added (rS331214) to New Reno and leak fixed (rS333699) , some assumptions about the state of it as the default and always ready cc seem to have changed, notably it now has a constructor and destructor (newreno_cb_destroy) for per connection state. We are seeing a double free that seems to be related to some non-standard sysctls we use, but this patch is sufficient to solve that problem while we root cause or otherwise explain why the behavior that winds up calling the callback twice is proper. * NULL out cc_data after freeing in {cc}_cb_destroy * Check for cc_data before proceeding to act on any data in cdg_cb_destroy * free(9) checks for NULL so there is no need to perform not NULL checks before calling free.

This is one result of an ongoing debugging session from Jason, Jason, and Matt which should be uncontroversial. When ABCE was added (rS331214) to New Reno and leak fixed (rS333699) , some assumptions about the state of it as the default and always ready cc seem to have changed, notably it now has a constructor and destructor (newreno_cb_destroy) for per connection state. We are seeing a double free that seems to be related to some non-standard sysctls we use, but this patch is sufficient to solve that problem while we root cause or otherwise explain why the behavior that winds up calling the callback twice is proper. * NULL out cc_data after freeing in {cc}_cb_destroy * Check for cc_data before proceeding to act on any data in cdg_cb_destroy * free(9) checks for NULL so there is no need to perform not NULL checks before calling free.