Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1192839ybn; Wed, 2 Oct 2019 12:13:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4uB1QywDTILPHGKxhsHPz1lcY/bwHSn9Pccsfdqvvd2MyJpXrmVlPtIB1ngPriSsbZolV X-Received: by 2002:a05:6402:17eb:: with SMTP id t11mr5407600edy.97.1570043607518; Wed, 02 Oct 2019 12:13:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570043607; cv=none; d=google.com; s=arc-20160816; b=fQ9NzJt4SKwb2LwmEo3TzjvCFE7AmjpqipyJPQokaW36rVZwbRKMuNigS9jU8QBApK a2WHo97R1lmzq452PCzae7gh7hOw8aCTJ7y5kC3Knaxi2WKKawLFYy+3lRJtkmYozxg+ ByF81bAJ9Jd3FEtqrgcSgkEO1ZDvmHTfOQCXmk8sxTL6sMn40NGj4k6HCOsSYTPVpBM5 fKntAWDOodA3Mcw1OmqYVpjyvEdXCK5c5QwE63i6soGiWQQr07gQUpliFQJSMOHR++DA oxfoR3MZcqbH5IiogaKB5dxKlto6gqHVKFsntf4h6oYiSn3WJdveLxI4e9J/VdGhQK8N Y1Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=DelKa7LzV45wkY4KRIwBFVH85lOxs8olm29zClM/KPc=; b=eFNnePp0l7wZjyU1b/xp2uXBLtR3CvfWZgCL0DxjSNfQu33xKZrB9OFXbgmYGeXeop x5TLzY8EAPiPfeVYAQGmgtGpa9ka8X6pmMfxNE0OdaYJL9b+8XN/12iBbiVhW1gM0BQn e753khY2HIRJ9VNnKvNW0/Mm58LkKAJeRtkd/T3NSO9q7k3w3xjQ0pNH7Oum2AstDtlJ XFTxJDTf/xqr8HQQQr0ShZU/wVjXJE2ACf1Ee/T7lyVioTPhVPEoXhYWPFipXH/R4VFX Nyca+Zc0xE7kIHR328/ygkGS0cxSeUUih2BsL9qmUexzgCFjxzdK2yp+dz1PSGQdG5la Tuew== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v20si31742edq.195.2019.10.02.12.13.03; Wed, 02 Oct 2019 12:13:27 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730017AbfJBTLv (ORCPT + 99 others); Wed, 2 Oct 2019 15:11:51 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35596 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729202AbfJBTIM (ORCPT ); Wed, 2 Oct 2019 15:08:12 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFjyr-00035v-D5; Wed, 02 Oct 2019 20:08:09 +0100 Received: from ben by deadeye with local (Exim 4.92.1) (envelope-from ) id 1iFjyo-0003dd-Ey; Wed, 02 Oct 2019 20:08:06 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Santosh Shilimkar" , "David S. Miller" , "Zhu Yanjun" Date: Wed, 02 Oct 2019 20:06:51 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 47/87] net: rds: fix memory leak in rds_ib_flush_mr_pool In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.75-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Zhu Yanjun commit 85cb928787eab6a2f4ca9d2a798b6f3bed53ced1 upstream. When the following tests last for several hours, the problem will occur. Server: rds-stress -r 1.1.1.16 -D 1M Client: rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M -T 30 The following will occur. " Starting up.... tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu % 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 " >From vmcore, we can find that clean_list is NULL. >From the source code, rds_mr_flushd calls rds_ib_mr_pool_flush_worker. Then rds_ib_mr_pool_flush_worker calls " rds_ib_flush_mr_pool(pool, 0, NULL); " Then in function " int rds_ib_flush_mr_pool(struct rds_ib_mr_pool *pool, int free_all, struct rds_ib_mr **ibmr_ret) " ibmr_ret is NULL. In the source code, " ... list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail); if (ibmr_ret) *ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode); /* more than one entry in llist nodes */ if (clean_nodes->next) llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list); ... " When ibmr_ret is NULL, llist_entry is not executed. clean_nodes->next instead of clean_nodes is added in clean_list. So clean_nodes is discarded. It can not be used again. The workqueue is executed periodically. So more and more clean_nodes are discarded. Finally the clean_list is NULL. Then this problem will occur. Fixes: 1bc144b62524 ("net, rds, Replace xlist in net/rds/xlist.h with llist") Signed-off-by: Zhu Yanjun Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/rds/ib_rdma.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/net/rds/ib_rdma.c +++ b/net/rds/ib_rdma.c @@ -663,12 +663,14 @@ static int rds_ib_flush_mr_pool(struct r wait_clean_list_grace(); list_to_llist_nodes(pool, &unmap_list, &clean_nodes, &clean_tail); - if (ibmr_ret) + if (ibmr_ret) { *ibmr_ret = llist_entry(clean_nodes, struct rds_ib_mr, llnode); - + clean_nodes = clean_nodes->next; + } /* more than one entry in llist nodes */ - if (clean_nodes->next) - llist_add_batch(clean_nodes->next, clean_tail, &pool->clean_list); + if (clean_nodes) + llist_add_batch(clean_nodes, clean_tail, + &pool->clean_list); }