| Message ID | 20170609104925.28927-1-rajur@chelsio.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, 2017-06-09 at 16:19 +0530, Raju Rangoju wrote: > The recent changes to addr6_resolve() to call ipv6 route lookup via > the stub interface broke cxgb4/ipv6. If the source address is already > resolved by ipv6_dst_lookup() then the check > ipv6_addr_any(&fl6.saddr) > would fail; consequently, copying saddr to the src_in buffer is > omitted. > > This commit addresses the above issue by moving the copy code out of > the ipv6_addr_any() block in addr6_resolve(). > > Signed-off-by: Raju Rangoju <rajur@chelsio.com> > --- > drivers/infiniband/core/addr.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/infiniband/core/addr.c > b/drivers/infiniband/core/addr.c > index 02971e239a18..c32477907765 100644 > --- a/drivers/infiniband/core/addr.c > +++ b/drivers/infiniband/core/addr.c > @@ -454,11 +454,11 @@ static int addr6_resolve(struct sockaddr_in6 > *src_in, > &fl6.daddr, 0, &fl6.saddr); > if (ret) > goto put; > - > - src_in->sin6_family = AF_INET6; > - src_in->sin6_addr = fl6.saddr; > } > > + src_in->sin6_family = AF_INET6; > + src_in->sin6_addr = fl6.saddr; > + > /* If there's a gateway and type of device not > ARPHRD_INFINIBAND, we're > * definitely in RoCE v2 (as RoCE v1 isn't routable) set the > network > * type accordingly. There was a different fix for this submitted by Roland Drier. It has been taken into my k.o/for-4.12-rc branch. I need you to check that his patch works for you and renders this patch no longer needed.
Doug, I've run into this with 4.9.30. The aforementioned patch fixes it in the 4.9 series, but also requires 24b43c996 as well. Can we get this fix into stable. If needed you can add me as tested-by. Tested-by: Robert LeBlanc <robert@leblancnet.us> ---------------- Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Wed, Jun 14, 2017 at 1:24 PM, Doug Ledford <dledford@redhat.com> wrote: > On Fri, 2017-06-09 at 16:19 +0530, Raju Rangoju wrote: >> The recent changes to addr6_resolve() to call ipv6 route lookup via >> the stub interface broke cxgb4/ipv6. If the source address is already >> resolved by ipv6_dst_lookup() then the check >> ipv6_addr_any(&fl6.saddr) >> would fail; consequently, copying saddr to the src_in buffer is >> omitted. >> >> This commit addresses the above issue by moving the copy code out of >> the ipv6_addr_any() block in addr6_resolve(). >> >> Signed-off-by: Raju Rangoju <rajur@chelsio.com> >> --- >> drivers/infiniband/core/addr.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/infiniband/core/addr.c >> b/drivers/infiniband/core/addr.c >> index 02971e239a18..c32477907765 100644 >> --- a/drivers/infiniband/core/addr.c >> +++ b/drivers/infiniband/core/addr.c >> @@ -454,11 +454,11 @@ static int addr6_resolve(struct sockaddr_in6 >> *src_in, >> &fl6.daddr, 0, &fl6.saddr); >> if (ret) >> goto put; >> - >> - src_in->sin6_family = AF_INET6; >> - src_in->sin6_addr = fl6.saddr; >> } >> >> + src_in->sin6_family = AF_INET6; >> + src_in->sin6_addr = fl6.saddr; >> + >> /* If there's a gateway and type of device not >> ARPHRD_INFINIBAND, we're >> * definitely in RoCE v2 (as RoCE v1 isn't routable) set the >> network >> * type accordingly. > > There was a different fix for this submitted by Roland Drier. It has > been taken into my k.o/for-4.12-rc branch. I need you to check that > his patch works for you and renders this patch no longer needed. > > -- > Doug Ledford <dledford@redhat.com> > GPG KeyID: B826A3330E572FDD > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2017-06-14 at 16:28 -0600, Robert LeBlanc wrote: > Doug, > > I've run into this with 4.9.30. The aforementioned patch fixes it in > the 4.9 series, but also requires 24b43c996 as well. Can we get this > fix into stable. If needed you can add me as tested-by. > > Tested-by: Robert LeBlanc <robert@leblancnet.us> While I don't doubt that this fixed the problem, the patch from Roland Drier looks more correct to me. As I've already taken Roland's patch, and it is Cc:ed for stable, it should be resolved already. I just need Raju to confirm this for me. > ---------------- > Robert LeBlanc > PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 > > > On Wed, Jun 14, 2017 at 1:24 PM, Doug Ledford <dledford@redhat.com> > wrote: > > > > On Fri, 2017-06-09 at 16:19 +0530, Raju Rangoju wrote: > > > > > > The recent changes to addr6_resolve() to call ipv6 route lookup > > > via > > > the stub interface broke cxgb4/ipv6. If the source address is > > > already > > > resolved by ipv6_dst_lookup() then the check > > > ipv6_addr_any(&fl6.saddr) > > > would fail; consequently, copying saddr to the src_in buffer is > > > omitted. > > > > > > This commit addresses the above issue by moving the copy code out > > > of > > > the ipv6_addr_any() block in addr6_resolve(). > > > > > > Signed-off-by: Raju Rangoju <rajur@chelsio.com> > > > --- > > > drivers/infiniband/core/addr.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/infiniband/core/addr.c > > > b/drivers/infiniband/core/addr.c > > > index 02971e239a18..c32477907765 100644 > > > --- a/drivers/infiniband/core/addr.c > > > +++ b/drivers/infiniband/core/addr.c > > > @@ -454,11 +454,11 @@ static int addr6_resolve(struct > > > sockaddr_in6 > > > *src_in, > > > &fl6.daddr, 0, > > > &fl6.saddr); > > > if (ret) > > > goto put; > > > - > > > - src_in->sin6_family = AF_INET6; > > > - src_in->sin6_addr = fl6.saddr; > > > } > > > > > > + src_in->sin6_family = AF_INET6; > > > + src_in->sin6_addr = fl6.saddr; > > > + > > > /* If there's a gateway and type of device not > > > ARPHRD_INFINIBAND, we're > > > * definitely in RoCE v2 (as RoCE v1 isn't routable) set > > > the > > > network > > > * type accordingly. > > > > There was a different fix for this submitted by Roland Drier. It > > has > > been taken into my k.o/for-4.12-rc branch. I need you to check > > that > > his patch works for you and renders this patch no longer needed. > > > > -- > > Doug Ledford <dledford@redhat.com> > > GPG KeyID: B826A3330E572FDD > > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 > > 2FDD > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > rdma" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Doug, Roland Drier's patch works for me, you could add me as Tested-by. -Thanks, -----Original Message----- From: Doug Ledford [mailto:dledford@redhat.com] Sent: 15 June 2017 05:43 To: Robert LeBlanc <robert@leblancnet.us> Cc: Raju Rangoju <rajur@chelsio.com>; linux-rdma <linux-rdma@vger.kernel.org>; SWise OGC <swise@opengridcomputing.com> Subject: Re: [PATCH 1/1] rdma: copy the saddr if it is already resolved On Wed, 2017-06-14 at 16:28 -0600, Robert LeBlanc wrote: > Doug, > > I've run into this with 4.9.30. The aforementioned patch fixes it in > the 4.9 series, but also requires 24b43c996 as well. Can we get this > fix into stable. If needed you can add me as tested-by. > > Tested-by: Robert LeBlanc <robert@leblancnet.us> While I don't doubt that this fixed the problem, the patch from Roland Drier looks more correct to me. As I've already taken Roland's patch, and it is Cc:ed for stable, it should be resolved already. I just need Raju to confirm this for me. > ---------------- > Robert LeBlanc > PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 > > > On Wed, Jun 14, 2017 at 1:24 PM, Doug Ledford <dledford@redhat.com> > wrote: > > > > On Fri, 2017-06-09 at 16:19 +0530, Raju Rangoju wrote: > > > > > > The recent changes to addr6_resolve() to call ipv6 route lookup > > > via the stub interface broke cxgb4/ipv6. If the source address is > > > already resolved by ipv6_dst_lookup() then the check > > > ipv6_addr_any(&fl6.saddr) > > > would fail; consequently, copying saddr to the src_in buffer is > > > omitted. > > > > > > This commit addresses the above issue by moving the copy code out > > > of the ipv6_addr_any() block in addr6_resolve(). > > > > > > Signed-off-by: Raju Rangoju <rajur@chelsio.com> > > > --- > > > drivers/infiniband/core/addr.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/infiniband/core/addr.c > > > b/drivers/infiniband/core/addr.c index 02971e239a18..c32477907765 > > > 100644 > > > --- a/drivers/infiniband/core/addr.c > > > +++ b/drivers/infiniband/core/addr.c > > > @@ -454,11 +454,11 @@ static int addr6_resolve(struct > > > sockaddr_in6 > > > *src_in, > > > &fl6.daddr, 0, &fl6.saddr); > > > if (ret) > > > goto put; > > > - > > > - src_in->sin6_family = AF_INET6; > > > - src_in->sin6_addr = fl6.saddr; > > > } > > > > > > + src_in->sin6_family = AF_INET6; > > > + src_in->sin6_addr = fl6.saddr; > > > + > > > /* If there's a gateway and type of device not > > > ARPHRD_INFINIBAND, we're > > > * definitely in RoCE v2 (as RoCE v1 isn't routable) set the > > > network > > > * type accordingly. > > > > There was a different fix for this submitted by Roland Drier. It > > has been taken into my k.o/for-4.12-rc branch. I need you to check > > that his patch works for you and renders this patch no longer > > needed. > > > > -- > > Doug Ledford <dledford@redhat.com> > > GPG KeyID: B826A3330E572FDD > > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > rdma" in the body of a message to majordomo@vger.kernel.org More > > majordomo info at http://vger.kernel.org/majordomo-info.html -- Doug Ledford <dledford@redhat.com> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Wed, Jun 14, 2017 at 6:12 PM, Doug Ledford <dledford@redhat.com> wrote: > On Wed, 2017-06-14 at 16:28 -0600, Robert LeBlanc wrote: >> Doug, >> >> I've run into this with 4.9.30. The aforementioned patch fixes it in >> the 4.9 series, but also requires 24b43c996 as well. Can we get this >> fix into stable. If needed you can add me as tested-by. >> >> Tested-by: Robert LeBlanc <robert@leblancnet.us> > > While I don't doubt that this fixed the problem, the patch from Roland > Drier looks more correct to me. As I've already taken Roland's patch, > and it is Cc:ed for stable, it should be resolved already. I just need > Raju to confirm this for me. Sorry, I meant to say that I tested Roland's patch and it fixes the issue for us. Thanks for getting this sent to stable. ---------------- Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-06-15 at 09:19 +0000, Raju Rangoju wrote: > Hi Doug, > > Roland Drier's patch works for me, you could add me as Tested-by. I've added a git notes entry for your testing. Thanks. > -Thanks, > > -----Original Message----- > From: Doug Ledford [mailto:dledford@redhat.com] > Sent: 15 June 2017 05:43 > To: Robert LeBlanc <robert@leblancnet.us> > Cc: Raju Rangoju <rajur@chelsio.com>; linux-rdma <linux-rdma@vger.ker > nel.org>; SWise OGC <swise@opengridcomputing.com> > Subject: Re: [PATCH 1/1] rdma: copy the saddr if it is already > resolved > > On Wed, 2017-06-14 at 16:28 -0600, Robert LeBlanc wrote: > > > > Doug, > > > > I've run into this with 4.9.30. The aforementioned patch fixes it > > in > > the 4.9 series, but also requires 24b43c996 as well. Can we get > > this > > fix into stable. If needed you can add me as tested-by. > > > > Tested-by: Robert LeBlanc <robert@leblancnet.us> > > While I don't doubt that this fixed the problem, the patch from > Roland Drier looks more correct to me. As I've already taken > Roland's patch, and it is Cc:ed for stable, it should be resolved > already. I just need Raju to confirm this for me. > > > > > ---------------- > > Robert LeBlanc > > PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 > > > > > > On Wed, Jun 14, 2017 at 1:24 PM, Doug Ledford <dledford@redhat.com> > > wrote: > > > > > > > > > On Fri, 2017-06-09 at 16:19 +0530, Raju Rangoju wrote: > > > > > > > > > > > > The recent changes to addr6_resolve() to call ipv6 route > > > > lookup > > > > via the stub interface broke cxgb4/ipv6. If the source address > > > > is > > > > already resolved by ipv6_dst_lookup() then the check > > > > ipv6_addr_any(&fl6.saddr) > > > > would fail; consequently, copying saddr to the src_in buffer > > > > is > > > > omitted. > > > > > > > > This commit addresses the above issue by moving the copy code > > > > out > > > > of the ipv6_addr_any() block in addr6_resolve(). > > > > > > > > Signed-off-by: Raju Rangoju <rajur@chelsio.com> > > > > --- > > > > drivers/infiniband/core/addr.c | 6 +++--- > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/infiniband/core/addr.c > > > > b/drivers/infiniband/core/addr.c index > > > > 02971e239a18..c32477907765 > > > > 100644 > > > > --- a/drivers/infiniband/core/addr.c > > > > +++ b/drivers/infiniband/core/addr.c > > > > @@ -454,11 +454,11 @@ static int addr6_resolve(struct > > > > sockaddr_in6 > > > > *src_in, > > > > &fl6.daddr, 0, > > > > &fl6.saddr); > > > > if (ret) > > > > goto put; > > > > - > > > > - src_in->sin6_family = AF_INET6; > > > > - src_in->sin6_addr = fl6.saddr; > > > > } > > > > > > > > + src_in->sin6_family = AF_INET6; > > > > + src_in->sin6_addr = fl6.saddr; > > > > + > > > > /* If there's a gateway and type of device not > > > > ARPHRD_INFINIBAND, we're > > > > * definitely in RoCE v2 (as RoCE v1 isn't routable) set > > > > the > > > > network > > > > * type accordingly. > > > > > > There was a different fix for this submitted by Roland > > > Drier. It > > > has been taken into my k.o/for-4.12-rc branch. I need you to > > > check > > > that his patch works for you and renders this patch no longer > > > needed. > > > > > > -- > > > Doug Ledford <dledford@redhat.com> > > > GPG KeyID: B826A3330E572FDD > > > > > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 > > > 2FDD > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux- > > > rdma" in the body of a message to majordomo@vger.kernel.org More > > > majordomo info at http://vger.kernel.org/majordomo-info.html > -- > Doug Ledford <dledford@redhat.com> > GPG KeyID: B826A3330E572FDD > > Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD >
On Thu, 2017-06-15 at 09:20 -0600, Robert LeBlanc wrote: > On Wed, Jun 14, 2017 at 6:12 PM, Doug Ledford <dledford@redhat.com> > wrote: > > > > On Wed, 2017-06-14 at 16:28 -0600, Robert LeBlanc wrote: > > > > > > Doug, > > > > > > I've run into this with 4.9.30. The aforementioned patch fixes it > > > in > > > the 4.9 series, but also requires 24b43c996 as well. Can we get > > > this > > > fix into stable. If needed you can add me as tested-by. > > > > > > Tested-by: Robert LeBlanc <robert@leblancnet.us> > > > > While I don't doubt that this fixed the problem, the patch from > > Roland > > Drier looks more correct to me. As I've already taken Roland's > > patch, > > and it is Cc:ed for stable, it should be resolved already. I just > > need > > Raju to confirm this for me. > > Sorry, I meant to say that I tested Roland's patch and it fixes the > issue for us. Thanks for getting this sent to stable. I've added a git notes entry for your testing. Thanks.
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c index 02971e239a18..c32477907765 100644 --- a/drivers/infiniband/core/addr.c +++ b/drivers/infiniband/core/addr.c @@ -454,11 +454,11 @@ static int addr6_resolve(struct sockaddr_in6 *src_in, &fl6.daddr, 0, &fl6.saddr); if (ret) goto put; - - src_in->sin6_family = AF_INET6; - src_in->sin6_addr = fl6.saddr; } + src_in->sin6_family = AF_INET6; + src_in->sin6_addr = fl6.saddr; + /* If there's a gateway and type of device not ARPHRD_INFINIBAND, we're * definitely in RoCE v2 (as RoCE v1 isn't routable) set the network * type accordingly.
The recent changes to addr6_resolve() to call ipv6 route lookup via the stub interface broke cxgb4/ipv6. If the source address is already resolved by ipv6_dst_lookup() then the check ipv6_addr_any(&fl6.saddr) would fail; consequently, copying saddr to the src_in buffer is omitted. This commit addresses the above issue by moving the copy code out of the ipv6_addr_any() block in addr6_resolve(). Signed-off-by: Raju Rangoju <rajur@chelsio.com> --- drivers/infiniband/core/addr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)