From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755329AbcAOTL3 (ORCPT ); Fri, 15 Jan 2016 14:11:29 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36947 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755247AbcAOTLY (ORCPT ); Fri, 15 Jan 2016 14:11:24 -0500 MIME-Version: 1.0 In-Reply-To: <20160115184620.GE6074@mrl.redhat.com> References: <20160115184620.GE6074@mrl.redhat.com> From: Dmitry Vyukov Date: Fri, 15 Jan 2016 20:11:03 +0100 Message-ID: Subject: Re: net/sctp: sock memory leak To: Marcelo Ricardo Leitner Cc: Vlad Yasevich , Neil Horman , "David S. Miller" , linux-sctp@vger.kernel.org, netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin , Eric Dumazet Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Vyukov Date: Fri, 15 Jan 2016 19:11:03 +0000 Subject: Re: net/sctp: sock memory leak Message-Id: List-Id: References: <20160115184620.GE6074@mrl.redhat.com> In-Reply-To: <20160115184620.GE6074@mrl.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Marcelo Ricardo Leitner Cc: Vlad Yasevich , Neil Horman , "David S. Miller" , linux-sctp@vger.kernel.org, netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin , Eric Dumazet On Fri, Jan 15, 2016 at 7:46 PM, Marcelo Ricardo Leitner 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.