Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3319679imu; Sun, 11 Nov 2018 12:17:04 -0800 (PST) X-Google-Smtp-Source: AJdET5fPkXHNK1sp9441CnqaC+kVbDrflxvUqDXZs/vr8w+QDyL0gUa/djV7taVCYdpd43Y3tPZ6 X-Received: by 2002:a63:2c0e:: with SMTP id s14mr15398945pgs.132.1541967423991; Sun, 11 Nov 2018 12:17:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541967423; cv=none; d=google.com; s=arc-20160816; b=bVh46BwcQVRO3nPceCagqSfSI6/UjPgQLBDhyIOWrQSIXwm/weZe/iam9ma5G8/Laa 28DhloT4GJ0cib26UqtZLft8qGjP3as72xcUazvzFaGpJhZ77SilSCedCPpGiHFjJW8T /u2NQROYH6vWKmvKxzJogt3nIOuwTOyh+fFYt1gXyZK7LzLfjeakLeORYHH21ZLcZxIw 58iAC0QpEEMKfZdFXw+A/23lcEEEDab3y5eHd+Iqw+zqcyB4GjB4gQwEZgtn4Ary/M/5 eSdLQ54WJGvjbLz2X4Ph0A/AnCgajDRBZVyndtVDRvUTzkZ4nJqoI5gxro98azAXn52e +JNA== 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=XmamQkUpqXAwflxMxyefoA3aypCBeIrWdNOo/gT4JgI=; b=O4rZa+LYe7UQfC00r8KKwAuyCaVnLnUiVfLW2v0oONy9V+URQ8CX74aAJwnhdcbrYU JaYF2oXM4TQ3qf6zDlW8lxSpQo6U4DuSDo2Mgwa8BnzbqHnCJL44of3DRsN1gRVg06W4 sfjXjhsPIKvKXav4SgVd1qBR8zYz/L7M1Esopw9OjpDGNyvpvfGmDFRLsPxCvYmdlxmq 9iQfI10XP5YeFUUyaHdyK/pDJQz+J5tZYAPQ99MSjo0OEcrMiY6V/oUGr8EQ1nJ0d3Mm Q12z0I2Om7qwxqERceOuUb3i0rYWo7a8ycJs5/Hm168CktIJwV7/4FKwoD9KmpZeSAWk SZLA== 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 i63si14151627pge.515.2018.11.11.12.16.48; Sun, 11 Nov 2018 12:17:03 -0800 (PST) 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 S1731921AbeKLGF6 (ORCPT + 99 others); Mon, 12 Nov 2018 01:05:58 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:53168 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731143AbeKLGF5 (ORCPT ); Mon, 12 Nov 2018 01:05:57 -0500 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 1gLvt8-0000l4-K7; Sun, 11 Nov 2018 19:59:18 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsP-0001Rz-Rl; Sun, 11 Nov 2018 19:58:33 +0000 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, "Evgenii Smirnov" , "Doug Ledford" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 074/366] RDMA/ipoib: Update paths on CLIENT_REREG/SM_CHANGE events 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.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Doug Ledford commit fa9391dbad4b868512ed22a7e41765f881a8a935 upstream. We do a light flush on CLIENT_REREG and SM_CHANGE events. This goes through and marks paths invalid. But we weren't always checking for this validity when we needed to, and so we could keep using a path marked invalid. What's more, once we establish a path with a valid ah, we put a pointer to the ah in the neigh struct directly, so even if we mark the path as invalid, as long as the neigh has a direct pointer to the ah, it keeps using the old, outdated ah. To fix this we do several things. 1) Put the valid flag in the ah instead of the path struct, so when we put the ah pointer directly in the neigh struct, we can easily check the validity of the ah on send events. 2) Check the neigh->ah and neigh->ah->valid elements in the needed places, and if we have an ah, but it's invalid, then invoke a refresh of the ah. 3) Fix the various places that check for path, but didn't check for path->valid (now path->ah && path->ah->valid). Reported-by: Evgenii Smirnov Fixes: ee1e2c82c245 ("IPoIB: Refresh paths instead of flushing them on SM change events") Signed-off-by: Doug Ledford [bwh: Backported to 3.16: - s/phdr->hwaddr/cb->hdwaddr/ - s/ipoib_priv/netdev_priv/ - Adjust context] Signed-off-by: Ben Hutchings --- drivers/infiniband/ulp/ipoib/ipoib.h | 2 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 33 ++++++++++++++++++----- 2 files changed, 28 insertions(+), 7 deletions(-) --- a/drivers/infiniband/ulp/ipoib/ipoib.h +++ b/drivers/infiniband/ulp/ipoib/ipoib.h @@ -384,6 +384,7 @@ struct ipoib_ah { struct list_head list; struct kref ref; unsigned last_send; + int valid; }; struct ipoib_path { @@ -400,7 +401,6 @@ struct ipoib_path { struct rb_node rb_node; struct list_head list; - int valid; }; struct ipoib_neigh { --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -426,7 +426,8 @@ void ipoib_mark_paths_invalid(struct net ipoib_dbg(priv, "mark path LID 0x%04x GID %pI6 invalid\n", be16_to_cpu(path->pathrec.dlid), path->pathrec.dgid.raw); - path->valid = 0; + if (path->ah) + path->ah->valid = 0; } spin_unlock_irq(&priv->lock); @@ -535,7 +536,7 @@ static void path_rec_completion(int stat while ((skb = __skb_dequeue(&neigh->queue))) __skb_queue_tail(&skqueue, skb); } - path->valid = 1; + path->ah->valid = 1; } path->query = NULL; @@ -615,6 +616,24 @@ static int path_rec_start(struct net_dev return 0; } +static void neigh_refresh_path(struct ipoib_neigh *neigh, u8 *daddr, + struct net_device *dev) +{ + struct ipoib_dev_priv *priv = netdev_priv(dev); + struct ipoib_path *path; + unsigned long flags; + + spin_lock_irqsave(&priv->lock, flags); + + path = __path_find(dev, daddr + 4); + if (!path) + goto out; + if (!path->query) + path_rec_start(dev, path); +out: + spin_unlock_irqrestore(&priv->lock, flags); +} + static struct ipoib_neigh *neigh_add_path(struct sk_buff *skb, u8 *daddr, struct net_device *dev) { @@ -651,7 +670,7 @@ static struct ipoib_neigh *neigh_add_pat list_add_tail(&neigh->list, &path->neigh_list); - if (path->ah) { + if (path->ah && path->ah->valid) { kref_get(&path->ah->ref); neigh->ah = path->ah; @@ -710,7 +729,7 @@ static void unicast_arp_send(struct sk_b spin_lock_irqsave(&priv->lock, flags); path = __path_find(dev, cb->hwaddr + 4); - if (!path || !path->valid) { + if (!path || !path->ah || !path->ah->valid) { int new_path = 0; if (!path) { @@ -736,7 +755,7 @@ static void unicast_arp_send(struct sk_b return; } - if (path->ah) { + if (path->ah && path->ah->valid) { ipoib_dbg(priv, "Send unicast ARP to %04x\n", be16_to_cpu(path->pathrec.dlid)); @@ -818,9 +837,11 @@ send_using_neigh: ipoib_cm_send(dev, skb, ipoib_cm_get(neigh)); goto unref; } - } else if (neigh->ah) { + } else if (neigh->ah && neigh->ah->valid) { ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(cb->hwaddr)); goto unref; + } else if (neigh->ah) { + neigh_refresh_path(neigh, cb->hwaddr, dev); } if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) {