Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1310369 > unrolled thread

Re: net/sctp: sock memory leak

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: net/sctp: sock memory leak Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> - 2016-01-15 19:50 +0100
    Re: net/sctp: sock memory leak Dmitry Vyukov <dvyukov@google.com> - 2016-01-15 20:20 +0100

#1310369 — Re: net/sctp: sock memory leak

On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> The following program leads to a leak of two sock objects:
...
> 
> On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).

I'm afraid I cannot reproduce this one?
I enabled dynprintk at sctp_destroy_sock and it does print twice when I
run this test app.
Also added debugs to check association lifetime, and then it was
destroyed. Same for endpoint. 

Checking with trace-cmd, both calls to sctp_close() resulted in
sctp_destroy_sock() being called.

As for sock_hold/put, they are matched too. 

Ideas? Log is below for double checking

[ 1112.558217] sctp_endpoint_init(ffff88000015d400) sock_hold sk:ffff8800336da000
[ 1112.558539] sctp_endpoint_hold(ffff88000015d400)
[ 1112.558544] sctp_association_init(ffff8800b2db9000) sock_hold sk:ffff8800336da000
[ 1112.558878] sctp_association_hold(ffff8800b2db9000)
[ 1112.558957] sctp_association_hold(ffff8800b2db9000)
[ 1112.559062] sctp_association_hold(ffff8800b2db9000)
[ 1112.559079] sctp_association_hold(ffff8800b2db9000)
[ 1112.658745] sctp_endpoint_init(ffff88000015e200) sock_hold sk:ffff8800336dc800
[ 1112.658815] sctp_endpoint_put(ffff88000015d400)
[ 1112.658819] sctp_assoc_migrate(ffff8800b2db9000) sock_put sk:ffff8800336da000 oldsk:ffff8800336da000
[ 1112.658822] sctp_endpoint_hold(ffff88000015e200)
[ 1112.658824] sctp_assoc_migrate(ffff8800b2db9000) sock_hold sk:ffff8800336dc800
[ 1112.659627] sctp_association_put(ffff8800b2db9000)
[ 1112.659673] sctp_association_free(ffff8800b2db9000)
[ 1112.659691] sctp_association_put(ffff8800b2db9000)
[ 1112.659735] sctp_transport_put(ffff8800b3426000)
[ 1112.659737] sctp_transport_destroy(ffff8800b3426000)
[ 1112.659741] sctp_association_put(ffff8800b2db9000)
[ 1112.659745] sctp_association_put(ffff8800b2db9000)
[ 1112.659757] sctp_association_put(ffff8800b2db9000)
[ 1112.659759] sctp_association_destroy(ffff8800b2db9000)
[ 1112.659761] sctp_endpoint_put(ffff88000015e200)
[ 1112.659773] sctp_association_destroy(ffff8800b2db9000) sock_put sk:ffff8800336dc800
[ 1112.659814] sctp_close sock_hold sk:ffff8800336dc800
[ 1112.659818] sctp: sctp_destroy_sock: sk:ffff8800336dc800
[ 1112.659823] sctp_endpoint_put(ffff88000015e200)
[ 1112.659825] sctp_endpoint_destroy(ffff88000015e200)
[ 1112.659841] sctp_endpoint_destroy(ffff88000015e200) sock_put sk:ffff8800336dc800
[ 1112.659852] sctp_close sock_put sk:ffff8800336dc800
[ 1112.662437] sctp_close sock_hold sk:ffff8800336da000
[ 1112.662443] sctp: sctp_destroy_sock: sk:ffff8800336da000
[ 1112.662448] sctp_endpoint_put(ffff88000015d400)
[ 1112.662450] sctp_endpoint_destroy(ffff88000015d400)
[ 1112.662466] sctp_endpoint_destroy(ffff88000015d400) sock_put sk:ffff8800336da000
[ 1112.662476] sctp_close sock_put sk:ffff8800336da000
[ 1112.677226] sctp_transport_destroy_rcu(ffff8800b3426000)

[toc] | [next] | [standalone]

#1310391

On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, Dec 30, 2015 at 09:42:27PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program leads to a leak of two sock objects:
> ...
>>
>> On commit 8513342170278468bac126640a5d2d12ffbff106 (Dec 28).
>
> I'm afraid I cannot reproduce this one?
> I enabled dynprintk at sctp_destroy_sock and it does print twice when I
> run this test app.
> Also added debugs to check association lifetime, and then it was
> destroyed. Same for endpoint.
>
> Checking with trace-cmd, both calls to sctp_close() resulted in
> sctp_destroy_sock() being called.
>
> As for sock_hold/put, they are matched too.
>
> Ideas? Log is below for double checking


Hummm... I can reproduce it pretty reliably.

[  197.459024] kmemleak: 11 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[  307.494874] kmemleak: 409 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
[  549.784022] kmemleak: 125 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)

I double checked via /proc/slabinfo:

SCTPv6              4373   4420   2368   13    8 : tunables    0    0
  0 : slabdata    340    340      0

SCTPv6 starts with almost 0, but grows infinitely while I run the
program in a loop.

Here is my SCTP related configs:

CONFIG_IP_SCTP=y
CONFIG_NET_SCTPPROBE=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE=y
# CONFIG_SCTP_COOKIE_HMAC_MD5 is not set
# CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set

I am on commit 67990608c8b95d2b8ccc29932376ae73d5818727 and I don't
seem to have any sctp-related changes on top.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web