On Wed, Aug 24, 2016 at 2:02 AM, David Ahern <d...@cumulusnetworks.com> wrote: >> Looking at the code again, it seems that there's a bug in >> sock_diag_destroy. If the destroy operation does not occur (e.g., if >> sock_diag_destroy returns EPERM, or the protocol doesn't support >> destroy), then it doesn't release the refcount. This affects the TCP >> code as well and as such is my fault, not yours. The most obvious way >> to fix this might be to call sock_gen_put in sock_diag_destroy. > > sock_gen_put seems specific to tcp which is why I used sock_put here.
I thought sock_gen_put can be used on UDP as well, but it does seem a bit counterintuitive. > Perhaps better to have the callers of sock_diag_destroy handle the refcnt? > This > function took it; it should release it success or fail. Same for tcp. So you'd remove the sock_put and sock_gen_put calls from tcp_abort and just add one sock_gen_put in tcp_diag_destroy? That does seem simpler.
