On Mon, 2017-07-31 at 09:30 +0200, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua <monis@xxxxxxxxxxxx> wrote: > > On Mon, Jul 31, 2017 at 9:50 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > --- a/include/rdma/ib_addr.h > > > +++ b/include/rdma/ib_addr.h > > > @@ -172,7 +172,8 @@ static inline int rdma_ip2gid(struct sockaddr *addr, union ib_gid *gid) > > > (struct in6_addr *)gid); > > > break; > > > case AF_INET6: > > > - memcpy(gid->raw, &((struct sockaddr_in6 *)addr)->sin6_addr, 16); > > > + *(struct in6_addr *)&gid->raw = > > > + ((struct sockaddr_in6 *)addr)->sin6_addr; > > > break; > > > default: > > > return -EINVAL; > > > > what happens if you replace 16 with sizeof(struct in6_addr)? > > Same thing: the problem is that gcc already knows the size of the structure we > pass in here, and it is in fact shorter. > > I also tried changing the struct sockaddr pointer to a sockaddr_storage pointer, > without success. Other approaches that do work are: > > - mark addr_event() as "noinline" to prevent gcc from seeing the true > size of the > inetaddr_event stack object in rdma_ip2gid(). I considered this a little ugly. > > - change inetaddr_event to put a larger structure on the stack, using > sockaddr_storage or sockaddr_in6. This would be less efficient. > > - define a union of sockaddr_in and sockaddr_in6, and use that as the argument > to rdma_ip2gid/rdma_gid2ip, and change all callers to use that union type. > This is probably the cleanest approach as it gets rid of a lot of questionable > type casts, but it's a relatively large patch and also slightly less > efficient as we have > to zero more stack storage in some cases. Hello Arnd, So inetaddr_event() assigns AF_INET so .sin_family and gcc warns about code that is only executed if .sin_family == AF_INET6? Since this warning is the result of incorrect interprocedural analysis by gcc, shouldn't this be reported as a bug to the gcc authors? Thanks, Bart.-- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
