Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp173624imd; Wed, 31 Oct 2018 16:48:18 -0700 (PDT) X-Google-Smtp-Source: AJdET5cvZOKQd6OgxflztPouaMPhgEv18uClMUQ6VlFQaVF4az4llPndajPEI7GYIEVicrZR1ODM X-Received: by 2002:a63:924e:: with SMTP id s14-v6mr4925835pgn.141.1541029697943; Wed, 31 Oct 2018 16:48:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541029697; cv=none; d=google.com; s=arc-20160816; b=dEnJ1e94Mdq5DMBRRBvg4KhsM7GIc57pcmo0mNlxx0OHHcrPjEeKGsa4xAbAk6nNcR AX6rYxACgIj7D9+b8QqNCzYdopnw7SAhkOKvadnYNBwxQWXowb022qyV96k3xLL+ouHc uCNNPP57OuWjk7KuXJe034zfUXstkdr2P6WwKxC/+A/yFO5MbaCKUtUX2Ia3R6Yp5Joj GFdUHGXk2/8LdwnU7nmC5gLIlF96OEbU1aM2l9YiXmUlFOlbLD9m01HUIdkAsGq3NL5V ljLiCI5htO0y6R32EhnEgQbr6LcVQsoTxh/B9x/DHFIs00msDpFzZTRD53Sk3Og+Ku8/ xsmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=7Y1cf1XAJprXEPOXBA9UXdCGJJ66q3EaKc7z2Hss/GM=; b=sGRsom/y+NNsmWKw88jwtRFA+YaxnpGAHKeCdUMKk3qvEjXVAxZHaasZqqjbk6Xi1Z 4CEnGNe09SVz/30pvywMShcMgbTZ9hIxWJEFqv13kDk1GV0s4Kuu2eTBuoq89y4McPG+ ZECK7h+5mm1AbUsC0BEEdrCRUJDId9ec45FXUkyPUBwsP5u8jO1+KlAWEjVIgwxlRmtz i4bbElKMoBWpWuJW2o+ctX1TnKCLiR6yJyzLWHQ2WP1fTvGb46nH5VbYUFzqpKDoVa53 IrgTdYX/BFuf/mWMUqJbjBqu4g3SDeaMRVWp1IphbiUdvDkQaA6IIZIQIA1cMkmFTTgq d7/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=032+qSpr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9-v6si4300640pgi.580.2018.10.31.16.48.03; Wed, 31 Oct 2018 16:48:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=032+qSpr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728741AbeKAIHS (ORCPT + 99 others); Thu, 1 Nov 2018 04:07:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:54860 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728695AbeKAIHP (ORCPT ); Thu, 1 Nov 2018 04:07:15 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 009A920823; Wed, 31 Oct 2018 23:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541027224; bh=LOdhwDStj3ZM725HkUVFKVnrUaHDHdQjfHe9FlR0ubw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=032+qSprq3aBYu3HuQLq7Su08hdE4yGhqEAylJTDJFqGf+TOCdNgW808GGPSc4rnH 72iq6VtQnJgYmjK30Ha6Dv4of1Td4/zaXj/nS7xFBUrS/51iIYjF5WNr7NHR2+MVtK bBoWbmJDEaW2JlJGxks6n69QDftHt6N0v1tAfY0A= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Jack Wang , Shaohua Li , Sasha Levin Subject: [PATCH AUTOSEL 4.19 090/146] md: fix memleak for mempool Date: Wed, 31 Oct 2018 19:04:45 -0400 Message-Id: <20181031230541.28822-90-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181031230541.28822-1-sashal@kernel.org> References: <20181031230541.28822-1-sashal@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jack Wang [ Upstream commit 6aaa58c994277647f8b05ffef3b9b225a2d08f36 ] I noticed kmemleak report memory leak when run create/stop md in a loop, backtrace: [<000000001ca975e7>] mempool_create_node+0x86/0xd0 [<0000000095576bcd>] md_run+0x1057/0x1410 [md_mod] [<000000007b45c5fc>] do_md_run+0x15/0x130 [md_mod] [<000000001ede9ec0>] md_ioctl+0x1f49/0x25d0 [md_mod] [<000000004142cacf>] blkdev_ioctl+0x680/0xd00 The root cause is we alloc mddev->flush_pool and mddev->flush_bio_pool in md_run, but from do_md_stop will not call into md_stop but __md_stop, move the mempool_destroy to __md_stop fixes the problem for me. The bug was introduced in 5a409b4f56d5, the fixes should go to 4.18+ Fixes: 5a409b4f56d5 ("MD: fix lock contention for flush bios") Signed-off-by: Jack Wang Reviewed-by: Xiao Ni Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin --- drivers/md/md.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 06f68f19b5f3..8668793262d0 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -5906,14 +5906,6 @@ static void __md_stop(struct mddev *mddev) mddev->to_remove = &md_redundancy_group; module_put(pers->owner); clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery); -} - -void md_stop(struct mddev *mddev) -{ - /* stop the array and free an attached data structures. - * This is called from dm-raid - */ - __md_stop(mddev); if (mddev->flush_bio_pool) { mempool_destroy(mddev->flush_bio_pool); mddev->flush_bio_pool = NULL; @@ -5922,6 +5914,14 @@ void md_stop(struct mddev *mddev) mempool_destroy(mddev->flush_pool); mddev->flush_pool = NULL; } +} + +void md_stop(struct mddev *mddev) +{ + /* stop the array and free an attached data structures. + * This is called from dm-raid + */ + __md_stop(mddev); bioset_exit(&mddev->bio_set); bioset_exit(&mddev->sync_set); } -- 2.17.1