From owner-svn-src-all@FreeBSD.ORG Wed Nov 23 15:13:36 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 763531065670; Wed, 23 Nov 2011 15:13:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id CB9608FC15; Wed, 23 Nov 2011 15:13:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pANFDY4V021769; Wed, 23 Nov 2011 19:13:34 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pANFDYRc021768; Wed, 23 Nov 2011 19:13:34 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Nov 2011 19:13:34 +0400 From: Gleb Smirnoff To: Qing Li Message-ID: <20111123151334.GC96616@FreeBSD.org> References: <201111211410.pALEAD9B046139@svn.freebsd.org> <20111121195439.GE96616@FreeBSD.org> <20111122154312.GL96616@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r227791 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 15:13:36 -0000 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> 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> > 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> > Q> > The test is the following run a race between this program: Q> > Q> > š š š šstruct ifreq ifr; Q> > š š š šint s; Q> > Q> > š š š šbzero(&ifr, sizeof(struct ifreq)); Q> > 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> > Q> > š š š šs = socket(AF_INET, SOCK_DGRAM, 0); Q> > Q> > š š š šfor (;;) Q> > š š š š š š š šioctl(s, SIOCSIFADDR, &ifr); Q> > Q> > And this script: Q> > Q> > š š š šwhile (true); do nc -z 10.0.0.1 22 || echo Fail; done Q> > Q> Q> I am not sure if this test scenario is valid. Q> 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.