From owner-freebsd-current@FreeBSD.ORG Fri Aug 12 13:08:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2539106564A for ; Fri, 12 Aug 2011 13:08:45 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58CCF8FC0C for ; Fri, 12 Aug 2011 13:08:44 +0000 (UTC) Received: by gwb15 with SMTP id 15so864326gwb.13 for ; Fri, 12 Aug 2011 06:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tli/uzTu4UIyIJ24KOYdrpKu8tp+X3nCsqzNGLpXe0I=; b=plmCOtH973Phdc6EeLWO0xb5k3x0wOcmB3irksEqyv7+VMQi+O+/v5i8vcK6TdZK+n OxYqUw+8NXr6dXF7A1jrjME7gdrLVvW2RWcDyZvVSl1/7WdyVEZkmuxymNdqmkTtPtGg UfvXo+t6uOEogPjmgmF80Q3DEcQ3GUVWQfr98= MIME-Version: 1.0 Received: by 10.142.75.15 with SMTP id x15mr481072wfa.329.1313154522351; Fri, 12 Aug 2011 06:08:42 -0700 (PDT) Received: by 10.142.144.20 with HTTP; Fri, 12 Aug 2011 06:08:42 -0700 (PDT) In-Reply-To: References: <92B5D566-9816-4134-9358-2306D0F7DAFC@averesystems.com> <1312781293.2521.1.camel@srgsec> <1312960023.2614.12.camel@srgsec> Date: Fri, 12 Aug 2011 15:08:42 +0200 Message-ID: From: Svatopluk Kraus To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremiah Lott , Kevin Lo , Andrew Boyer , "freebsd-current@freebsd.org" Subject: Re: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:08:45 -0000 Hi, thank you very much for your review and related fixes. On Fri, Aug 12, 2011 at 3:48 AM, Li, Qing wrote: >> =A0I have no problem with loopback routes when I work with not >> point-to-point interfaces as I can NOT set same source address on >> them. However, if the interface is going down and up, then loopback >> route is deleted without checking IFA_RTSELF flag (it must be >> consistent! especially in kernel) and re-added regardless of >> "useloopback" setting. So, at least, a loopback route is installed >> even if useloopback is NOT allowed! >> > > =A0 I hope the question does not offend you, but you do know the history > =A0 behind IFA_RTSELF loopback route for each interface address, right ? > > =A0 The interface address loopback route is used for reaching the > =A0 interface address within the system after the L2/L3 separation > =A0 redesign, that's why "useloopback" setting is inapplicable. > > =A0 The check in various code paths may have a bit of consistency issue, > =A0 but "useloopback" setting does not apply here. In fact, I don't know the history, so you question is quite in place. I always try to find more about problems that I'm solving. However, sometimes it is not easy to find all things about an issue. Sometimes, I miss the ideas behind to figure out the issue in clear view. That's why I've started this discussion. So, maybe I'm not perfect, but I'm trying to learn. ;)) >> The bigger problem was with loopback routes on un-numbered >> interfaces. In in_ifinit(), when un-numbered interface is setting >> loopback route, then refcount on existing route is incremented and >> IFA_RTSELF flags is set on its address. This is done if and only if >> useloopback is set and interface is not IFF_LOOPBACK. It is OK. The >> rest is hacked somehow and I don't know why. >> > > =A0 The loopback route for the IFA should be installed unconditionally. > =A0 So the check in in_ifinit() for "V_useloopback" needs to be removed. It is clear now, but I don't know that when I was proposing the patch. I saw "V_useloopback" in in_ifinit(), so I put it to my patch too. >>> Unless you have a really good reason, other than code inspection, >>> and have a set of test cases, please leave this code alone for now. >> >> I have good reason, but I can hack kernel just for me only in worse >> scenario. However, I always try to minimalize the hacks count. >> > > =A0 You can hack the kernel however you see fit, but when you are > =A0 ready for a patch commit, please provide sufficient context and > =A0 problem description, and test cases whenever possible to make the > =A0 code review process effective. I understand. > =A0 Again, my only point is, since these areas are core to the networking > =A0 kernel, please test as many scenarios as possible, more than just you= r > =A0 specific setup. (I made this mistake myself sometimes.) I undestand and once again, thanks, Svata