svn commit: r227791 - head/sys/netinet
glebius at FreeBSD.org
Wed Nov 23 15:13:36 UTC 2011
On Wed, Nov 23, 2011 at 06:53:05AM -0800, Qing Li wrote:
Q> > first I'd like to notice that we are speaking about obsoleted interfaces.
Q> Yup, that's why you don't see me commenting on your other commits around
Q> ia_netmask stuff, do you ?
Oops, I didn't notice that one. Sorry! Can you please resend it?
Q> > Back to your comments:
Q> > I have made a test case that proves, that usage of deleted address isn't
Q> > prevented when it is removed, but loopback route still exists.
Q> > The test is the following run a race between this program:
Q> > struct ifreq ifr;
Q> > int s;
Q> > bzero(&ifr, sizeof(struct ifreq));
Q> > strncpy(ifr.ifr_name, "igb1", sizeof ifr.ifr_name);
Q> > ifr.ifr_addr.sa_family = AF_INET;
Q> > ifr.ifr_addr.sa_len = sizeof(struct sockaddr_in);
Q> > ((struct sockaddr_in *)&ifr.ifr_addr)->sin_addr.s_addr = inet_addr("10.0.0.1");
Q> > s = socket(AF_INET, SOCK_DGRAM, 0);
Q> > for (;;)
Q> > ioctl(s, SIOCSIFADDR, &ifr);
Q> > And this script:
Q> > while (true); do nc -z 10.0.0.1 22 || echo Fail; done
Q> I am not sure if this test scenario is valid.
Q> The loopback route is wiped at line #853 and then quickly inserted back at
Q> line #936 because you are SIOCSIFADDR the same address over and over again.
But during the procedure there is a state when we do not have this address,
but still we receive traffic to it. That is the thing I don't like.
If you really insist on this, let's shift in_ifscrub() down below as it was.
Since it affects only obsoleted SIOCSIFADDR, I'd better just ignore that
behavior rather than stand on its incorrectness.
Totus tuus, Glebius.
More information about the svn-src-all