Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1370235yba; Tue, 2 Apr 2019 07:40:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqxeuhmtdsNtThKb70dI/cQ2Iaxf8pfaHUdv+CCCTxS2tbf1f75iaqrSdpYCByjVjp0cMcEF X-Received: by 2002:a17:902:b713:: with SMTP id d19mr55616688pls.54.1554216048051; Tue, 02 Apr 2019 07:40:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554216048; cv=none; d=google.com; s=arc-20160816; b=u+I3Isq4Tg+OEw2ji+6kBsTwUdOv+y4NyqhfI4jQWNdnLeedePiwqz0mrEIwSk44wS /zdTY5m/cssI3qf1us3UqnlnYDGwPk414+llrywRm99oTNL2EuGM55TAgiteR1O/88gz rdUSEhMjmw+PVlwrORA9wf8ZLTTQW++MpgzM+N3BwOEcvwwgMW1jK077M9pM2sa4QZz7 8q5YRj43GelycDsV9q96CDbPqkuIjyNLTPZiye8g18t+c68w9Y/pkUiw6y3a8dCLqpYT bXsA5Mg/cO1LB13r/Y14ZtAN2pI8XZsow16jAq6CLqxW89twCU0YquIYMg7M6GCNheUO bvJw== 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=vIbdyjN6MSbmLf4kElNeFjGY/vOtybPFaTP2m9sagWo=; b=s2vNefIQWf9z7eoHirE18f1L9MYUZi8/kEGdoWfvJr9X0r5Flm4l6spY7laPZ8stIb yaadUnn1AbwyVfcfAUW/OBVUH9DXhqEoBnfW8DP9ydNfgroMChPHIys2jCCmCqctvTqU uWtckFzHrJduoQWIugG2PqVRANou/J3fGRwmnIjJsNrCHEh0mRN+EYs+J+RaDJiamKCa CrRq6coK5cB9P0p4CyABXBNKlNyLjYnDqwNZLuRosq5sgw4DbLRUjXdynn9ZWqgTIWMr AIVRSytzUmtg0Bi3jl4g6u/uoR+1lZ30et151RR2ETuEMNE4JYyDWtU3xjUteMysLLrf IqVg== 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 i69si11684789plb.75.2019.04.02.07.40.32; Tue, 02 Apr 2019 07:40:48 -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 S1731570AbfDBNkP (ORCPT + 99 others); Tue, 2 Apr 2019 09:40:15 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:42850 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731173AbfDBNkC (ORCPT ); Tue, 2 Apr 2019 09:40:02 -0400 Received: from [167.98.27.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hBJdv-0002n8-AM; Tue, 02 Apr 2019 14:39:59 +0100 Received: from ben by deadeye with local (Exim 4.92) (envelope-from ) id 1hBJdu-0004sC-9a; Tue, 02 Apr 2019 14:39:58 +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 , "NeilBrown" , "J. Bruce Fields" , "Pavel Tikhomirov" , "Vasily Averin" Date: Tue, 02 Apr 2019 14:38:27 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 22/99] sunrpc: fix cache_head leak due to queued request In-Reply-To: X-SA-Exim-Connect-IP: 167.98.27.226 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.65-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Vasily Averin commit 4ecd55ea074217473f94cfee21bb72864d39f8d7 upstream. After commit d202cce8963d, an expired cache_head can be removed from the cache_detail's hash. However, the expired cache_head may be waiting for a reply from a previously submitted request. Such a cache_head has an increased refcounter and therefore it won't be freed after cache_put(freeme). Because the cache_head was removed from the hash it cannot be found during cache_clean() and can be leaked forever, together with stalled cache_request and other taken resources. In our case we noticed it because an entry in the export cache was holding a reference on a filesystem. Fixes d202cce8963d ("sunrpc: never return expired entries in sunrpc_cache_lookup") Cc: Pavel Tikhomirov Signed-off-by: Vasily Averin Reviewed-by: NeilBrown Signed-off-by: J. Bruce Fields [bwh: Backported to 3.16: - cache_fresh_lock() doesn't take a struct cache_detail pointer - Adjust context] Signed-off-by: Ben Hutchings --- net/sunrpc/cache.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/net/sunrpc/cache.c +++ b/net/sunrpc/cache.c @@ -50,6 +50,10 @@ static void cache_init(struct cache_head h->last_refresh = now; } +static void cache_fresh_locked(struct cache_head *head, time_t expiry); +static void cache_fresh_unlocked(struct cache_head *head, + struct cache_detail *detail); + struct cache_head *sunrpc_cache_lookup(struct cache_detail *detail, struct cache_head *key, int hash) { @@ -94,6 +98,7 @@ struct cache_head *sunrpc_cache_lookup(s *hp = tmp->next; tmp->next = NULL; detail->entries --; + cache_fresh_locked(tmp, 0); freeme = tmp; break; } @@ -109,8 +114,10 @@ struct cache_head *sunrpc_cache_lookup(s cache_get(new); write_unlock(&detail->hash_lock); - if (freeme) + if (freeme) { + cache_fresh_unlocked(freeme, detail); cache_put(freeme, detail); + } return new; } EXPORT_SYMBOL_GPL(sunrpc_cache_lookup);