Messages in this thread | | | From | Josef Bacik <> | Subject | Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression | Date | Wed, 13 Sep 2017 20:11:09 +0000 |
| |
> On Sep 13, 2017, at 12:46 PM, Chuck Ebbert <cebbert.lkml@gmail.com> wrote: > > On Wed, 13 Sep 2017 17:28:25 +0000 > Josef Bacik <jbacik@fb.com> wrote: > >> Sorry I thought I had made this other fix, can you apply this on top >> of the other one and try that? I have more things to try if this >> doesn’t work, sorry you are playing go between, but I want to make >> sure I know _which_ fix actually fixes the problem, and then clean up >> in followup patches. Thanks, >> >> Josef >> >> On 9/13/17, 8:45 AM, "Laura Abbott" <labbott@redhat.com> wrote: >> >> On 09/12/2017 04:12 PM, Josef Bacik wrote: >>> First I’m super sorry for the top post, I’m at plumbers and I >>> forgot to upload my muttrc to my new cloud instance, so I’m screwed >>> using outlook. >>> >>> I have a completely untested, uncompiled patch that I think will >>> fix the problem, would you mind giving it a go? Thanks, >>> >>> Josef >> >> Thanks for the quick turnaround. Unfortunately, the problem is still >> reproducible according to the reporter. >> >> Thanks, >> Laura > > I am confused by the patch that originally caused this: > > if (sk->sk_family == AF_INET6) > return ipv6_rcv_saddr_equal(&sk->sk_v6_rcv_saddr, > - &sk2->sk_v6_rcv_saddr, > + inet6_rcv_saddr(sk2), > sk->sk_rcv_saddr, > sk2->sk_rcv_saddr, > > Shouldn't the first argument also be changed to use inet6_rcv_saddr()?
No we know sk is IPv6 so it's alright to use directly. Thanks,
Josef
| |