Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3764804pxt; Tue, 10 Aug 2021 10:47:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyak/7Yl1wIwUYZOP8GjPlxblmVQCaWeetLynkk9AalNA71jSYnAIGOSv6r0w+52VR9vGSZ X-Received: by 2002:a05:6e02:2146:: with SMTP id d6mr309217ilv.294.1628617633233; Tue, 10 Aug 2021 10:47:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628617633; cv=none; d=google.com; s=arc-20160816; b=WGbEM4E3QycMWwcVN90kgxa8g4v19RZyZRgEMrZnLRxfjQyJjV078tobkpqXIk0tp2 M8hT4aJN5e02A2KViM+GNv+su6Tihwl2j+a/gguv/oCZrhfOuSGoCIGvPMKFa/iEJUDY DkfIjIYrbeoQRcu6M6PR/kbpKzxBtHxZOT1g5yCBwi5L2JcX23dRWSZTG0f/g6KtgtK9 LBmjIL6SwVP5E77DafA2HQ+EG+Rmh5viosFJZSS5vqPIK7wo12AfQesxQUKRoCRAXTSW cOwqdtN99XIDz0csRGzuRPH8L6+qJhIkbn4R58l5kg1fAQPKZMq5KTJ92fqjD+MFmTbA aqEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=GIP4b6y/fZ76aBTcqg+KBtyOldskSztjiAGE1/5zgOk=; b=RmJZ8raCaR6wAxGlohvFfkxQzIgCFon2LOxb7M2IpWz6eFdTS1HICpcq6EMq/dlWS3 U4Km8ceV3vhvJKhziCPmDc1+sGt5gqTNWn45aLTv1ecKDpcA5QhlJ4pDjs866rs4V3vZ 8qQGlXiumEMGeB693Gj/of/sHdJIYVUxW3FagnF87nfuSF+wycYI0831j2671oT2UeLv xSQcZp4DxH/sZGZ3Oa/vw6IcDDtIqfUWQCOXshY9xM5WlMSPO1Z3GM/wwo3A6EM7kdvq OlMWxGoXg8YaSjcxnPPcO3BbZ9uKWMwj61Zd/1JV1ygLEJc4XLizpFKpsEMCQbfUTXj8 droQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kBRyyjXu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y23si21479246jak.77.2021.08.10.10.46.59; Tue, 10 Aug 2021 10:47:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kBRyyjXu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236155AbhHJRqg (ORCPT + 99 others); Tue, 10 Aug 2021 13:46:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:41666 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234012AbhHJRnx (ORCPT ); Tue, 10 Aug 2021 13:43:53 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EBFCB606A5; Tue, 10 Aug 2021 17:39:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1628617162; bh=XJBcsXSIRcusmHj+x5GP3rBMU2877z0rlhQN0e2SMvM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kBRyyjXudmEr1EQI1vq5OMWB34kltepa6cvcTfqaklhnh7WPsf/HnF6z2HW6km/eQ wZoKIlPV+Egax2i/I1dha0Z3ZhpWHPZ5eI8Dv6LY+wKKXI5ktn42g+mBG0G4KP/IKf gLDuBPESMop+vSzJJf/cV36+HcF9l2t7HdXlTYaI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Aharon Landau , Maor Gottlieb , Leon Romanovsky , Jason Gunthorpe , Sasha Levin Subject: [PATCH 5.10 038/135] RDMA/mlx5: Delay emptying a cache entry when a new MR is added to it recently Date: Tue, 10 Aug 2021 19:29:32 +0200 Message-Id: <20210810172956.979317851@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210810172955.660225700@linuxfoundation.org> References: <20210810172955.660225700@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Aharon Landau [ Upstream commit d6793ca97b76642b77629dd0783ec64782a50bdb ] Fixing a typo that causes a cache entry to shrink immediately after adding to it new MRs if the entry size exceeds the high limit. In doing so, the cache misses its purpose to prevent the creation of new mkeys on the runtime by using the cached ones. Fixes: b9358bdbc713 ("RDMA/mlx5: Fix locking in MR cache work queue") Link: https://lore.kernel.org/r/fcb546986be346684a016f5ca23a0567399145fa.1627370131.git.leonro@nvidia.com Signed-off-by: Aharon Landau Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin --- drivers/infiniband/hw/mlx5/mr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c index 971694e781b6..19346693c1da 100644 --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -526,8 +526,8 @@ static void __cache_work_func(struct mlx5_cache_ent *ent) */ spin_unlock_irq(&ent->lock); need_delay = need_resched() || someone_adding(cache) || - time_after(jiffies, - READ_ONCE(cache->last_add) + 300 * HZ); + !time_after(jiffies, + READ_ONCE(cache->last_add) + 300 * HZ); spin_lock_irq(&ent->lock); if (ent->disabled) goto out; -- 2.30.2