From patchwork Tue Jun 6 16:22:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roland Dreier X-Patchwork-Id: 9769261 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2F6D36035D for ; Tue, 6 Jun 2017 16:22:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 322A728438 for ; Tue, 6 Jun 2017 16:22:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 26B852848D; Tue, 6 Jun 2017 16:22:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8B88328438 for ; Tue, 6 Jun 2017 16:22:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751423AbdFFQWZ (ORCPT ); Tue, 6 Jun 2017 12:22:25 -0400 Received: from mail-pf0-f178.google.com ([209.85.192.178]:36824 "EHLO mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751431AbdFFQWY (ORCPT ); Tue, 6 Jun 2017 12:22:24 -0400 Received: by mail-pf0-f178.google.com with SMTP id x63so1541690pff.3 for ; Tue, 06 Jun 2017 09:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google; h=sender:from:to:cc:subject:date:message-id; bh=lAaPi7JI1wN49DDVwIWvh2UupBuYrxs7wd79r0MycPA=; b=EEv2bjI7VRHJovYa6mE6CQSRpfeg2ULM057MU1hdJQwx2j0OwsOSXWufzsTMXPZp/m FyvYrce56PyWI6PzPWDKSKiTzGKpG2XcZE2B1xKUdfKZlXnm5ff/RbsnbtOcbkrlFLk+ h6XQIzk+52+7Y/605BmjENtcsBi4T0zK9UDQs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id; bh=lAaPi7JI1wN49DDVwIWvh2UupBuYrxs7wd79r0MycPA=; b=PkrNZujhIsEos9kUAqMZPQZa5Z3QQ6PXo67UkBN2b8m30IS2sJd61zr/U+/ITN8d7v 8okD/ZNonPpuioDqVCquyrgtfbNuOR3ywMUxDGEAL9Zo1r/aoNMVCkayyYjCCyEGs+lh HAD6LGZVgc6CCAjBtEczmcFWTn6WXk9I5ASjEuHRwfUEdVXvdj1xZaM99Qvdfv17E6ZQ i5WfbsUTU+9dV6JHFfbIBBzOZrcvoXPsGROFVTrlTlIbqjv2G/Glaf0g8jbwFNAzLufY UMAeB2y4/R+ug4sJM/461xVFjYnCRwePpmOXIuoyW3OjuE0RpLT2TuU7Q408cED9+sHr XD8A== X-Gm-Message-State: AODbwcD0uFKzuV+PdEk2N5URoUypVzZSulEHsoqmm/rbQIZHIphxMgcS sS3hTCQpOQ1XO8+Zxuk= X-Received: by 10.98.63.218 with SMTP id z87mr17460339pfj.144.1496766144090; Tue, 06 Jun 2017 09:22:24 -0700 (PDT) Received: from localhost.localdomain ([2001:470:1f05:221:3841:258:cce4:bfdb]) by smtp.gmail.com with ESMTPSA id x6sm62084949pfk.22.2017.06.06.09.22.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 09:22:23 -0700 (PDT) From: Roland Dreier To: Paolo Abeni , Doug Ledford Cc: linux-rdma@vger.kernel.org Subject: [PATCH] IB/addr: Fix setting source address in addr6_resolve() Date: Tue, 6 Jun 2017 09:22:00 -0700 Message-Id: <20170606162200.24629-1-roland@kernel.org> X-Mailer: git-send-email 2.11.0 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Roland Dreier Commit eea40b8f624f ("infiniband: call ipv6 route lookup via the stub interface") introduced a regression in address resolution when connecting to IPv6 destination addresses. The old code called ip6_route_output(), while the new code calls ipv6_stub->ipv6_dst_lookup(). The two are almost the same, except that ipv6_dst_lookup() also calls ip6_route_get_saddr() if the source address is in6addr_any. This means that the test of ipv6_addr_any(&fl6.saddr) now never succeeds, and so we never copy the source address out. This ends up causing rdma_resolve_addr() to fail, because without a resolved source address, cma_acquire_dev() will fail to find an RDMA device to use. For me, this causes connecting to an NVMe over Fabrics target via RoCE / IPv6 to fail. Fix this by copying out fl6.saddr if ipv6_addr_any() is true for the original source address passed into addr6_resolve(). We can drop our call to ipv6_dev_get_saddr() because ipv6_dst_lookup() already does that work. Fixes: eea40b8f624 ("infiniband: call ipv6 route lookup via the stub interface") Cc: # 3.12+ Signed-off-by: Roland Dreier Acked-by: Paolo Abeni --- drivers/infiniband/core/addr.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c index 02971e239a18..ece6926fa2e6 100644 --- a/drivers/infiniband/core/addr.c +++ b/drivers/infiniband/core/addr.c @@ -449,12 +449,7 @@ static int addr6_resolve(struct sockaddr_in6 *src_in, return ret; rt = (struct rt6_info *)dst; - if (ipv6_addr_any(&fl6.saddr)) { - ret = ipv6_dev_get_saddr(addr->net, ip6_dst_idev(dst)->dev, - &fl6.daddr, 0, &fl6.saddr); - if (ret) - goto put; - + if (ipv6_addr_any(&src_in->sin6_addr)) { src_in->sin6_family = AF_INET6; src_in->sin6_addr = fl6.saddr; } @@ -471,9 +466,6 @@ static int addr6_resolve(struct sockaddr_in6 *src_in, *pdst = dst; return 0; -put: - dst_release(dst); - return ret; } #else static int addr6_resolve(struct sockaddr_in6 *src_in,