From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754956AbcCBTmX (ORCPT ); Wed, 2 Mar 2016 14:42:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37928 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754693AbcCBTmU (ORCPT ); Wed, 2 Mar 2016 14:42:20 -0500 Date: Wed, 2 Mar 2016 16:42:16 -0300 From: Marcelo Ricardo Leitner To: Dmitry Vyukov Cc: Vlad Yasevich , Neil Horman , "David S. Miller" , linux-sctp@vger.kernel.org, netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin , Eric Dumazet Subject: Re: net/sctp: sock memory leak Message-ID: <20160302194216.GD31743@localhost.localdomain> References: <20160115184620.GE6074@mrl.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 02, 2016 at 09:56:51AM +0100, Dmitry Vyukov wrote: > On Fri, Jan 15, 2016 at 8:11 PM, Dmitry Vyukov wrote: > > 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. > > > Still happens on 4.5-rc6. > > Marcelo, try to apply my config (if yours differs), run the program in > a parallel loop and check /proc/slabinfo (or kmemleak). Hi Dmitry, I'm just back from PTOs. Will get back to this asap. Thanks, Marcelo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Date: Wed, 02 Mar 2016 19:42:16 +0000 Subject: Re: net/sctp: sock memory leak Message-Id: <20160302194216.GD31743@localhost.localdomain> List-Id: References: <20160115184620.GE6074@mrl.redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dmitry Vyukov 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 Wed, Mar 02, 2016 at 09:56:51AM +0100, Dmitry Vyukov wrote: > On Fri, Jan 15, 2016 at 8:11 PM, Dmitry Vyukov wrote: > > 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. > > > Still happens on 4.5-rc6. > > Marcelo, try to apply my config (if yours differs), run the program in > a parallel loop and check /proc/slabinfo (or kmemleak). Hi Dmitry, I'm just back from PTOs. Will get back to this asap. Thanks, Marcelo