Re: [PATCH] link-local address fix for rdma_resolve_addr

Jason Gunthorpe
2009-10-21T23:08:45Z

On Wed, Oct 21, 2009 at 03:30:29PM -0700, David J. Wilder wrote:

> addr6_resolve_remote(). The second patch fixes the bugs in
> addr_resolve_local(). The 3d patch I am posting now for discussion.
>
> This patch, as Jason's suggested, moves the function of
> addr_resolve_local() into addr4_resolve_remote() and
> addr6_resolve_remote(). It eliminates the need for
> addr_resolve_local().

This looks exactly like what I was thinking of - have you tested this?

If it is OK, I'd make it the first in the series.

There were two things I was not sure about in my example.
1) Is 'init_net.loopback_dev' the correct reference for the loop device? Or
is it something like dev_net(rt->idev->dev)->loopback_dev ?

I'm sensing it may be the latter, but can't investigate right now
Donno much about this new namespace stuff really

2) Was rt->idev->dev the right choice for the ipv4 case? Or is it
rt->u.dst.dev ?

The TCP case kinda looks like
int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
tmp = ip_route_connect(&rt, nexthop, inet->saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_TCP,
inet->sport, usin->sin_port, sk, 1);
sk_setup_caps(sk, &rt->u.dst);

void sk_setup_caps(struct sock *sk, struct dst_entry *dst)
__sk_dst_set(sk, dst);

And all later things key off the sk_get_dst. So I'm thinking
that u.dst.dev might be correct.

I have no idea what the difference is though (can't look too hard
right now)

The main other fixup I see is to remove
ret = cma_bind_addr(id, src_addr, dst_addr);

>From rdma_resolve_addr and rely on the routing lookup in
addr_resolve_remote called by addr_resolve_ip to setup the bind device
from the routing lookup. (This is what I mentioned in my last email)

Which then lets you fixup the checking and handling of the
sin6_scopeid on the source address - and fixes the main other routing
difference against the TCP stack.

Thanks for working on this!

Jason