From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 01:40:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 508A416A400 for ; Mon, 5 Mar 2007 01:40:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 14B8013C4B5 for ; Mon, 5 Mar 2007 01:40:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C1FD61F4E80; Sun, 4 Mar 2007 20:40:29 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sun, 04 Mar 2007 20:40:29 -0500 X-Sasl-enc: TxSGZrvlgundEiLhNbur6mGCnLvIwBaJ0RYwr3C/d3Z+ 1173058829 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 1BE221B255; Sun, 4 Mar 2007 20:40:27 -0500 (EST) Message-ID: <45EB750A.90105@incunabulum.net> Date: Mon, 05 Mar 2007 01:40:26 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Yar Tikhiy References: <45E8B964.2090200@incunabulum.net> <20070303215359.GB40430@comp.chem.msu.su> <45EA0756.2000107@incunabulum.net> <20070304070458.GG40430@comp.chem.msu.su> In-Reply-To: <20070304070458.GG40430@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2007 01:40:30 -0000 Yar Tikhiy wrote: > > Now I see your point, thanks! Well, at least in theory, the driver > shouldn't call ether_input() if the interface isn't running. OTOH, > the interface shouldn't be getting traffic if it's !UP. However, > I suspect that not all drivers handle IFF_UP fully or even can do > it at all due to hardware limitations. As I understand it, in an > ideal world a !UP interface should be deaf and dumb and not interfering > in any way with the network still connected to it physically. > Therefore discarding inbound traffic from a !UP interface may be a > necessary workaround, but it may not be enough. All that boils > down to this: The IFF_UP check in ether_input() is more to a sanity > check than to the way for IFF_UP to work. Therefore we can add the > IFF_DRV_RUNNING sanity check there, too, for completeness. > Thanks for your explanation. I'm still not sure I understand why IFF_DRV_RUNNING should be checked for in ether_input(). There is a pretty clear reason for checking for IFF_UP in ether_input(); an interface which is configured administratively down should not be bringing traffic into the stack, regardless of whether it is a hardware device or a pseudo-device. IFF_UP has been in since 4.2BSD; it is more or less integral to how the BSD network stack operates. There are situations in which a pseudo-device or hardware device could incorrectly call ether_input() with such traffic. Reading , IFF_DRV_RUNNING is documented as meaning 'resources are allocated for this device'. Surely such a check is redundant and not relevant to the operation of ether_input()? As far as I can tell it is similar to the old meaning of IFF_RUNNING, and there are legitimate situations in which the hardware or its queues may have stopped processing temporarily whilst the interface may be administratively up (and thus accepting traffic). Please correct me if I'm wrong or point out situations where it's important IFF_DRV_RUNNING state is checked outside of a driver. Sorry if I seem obtuse, but I'm sure I'm missing some detail here. Regards, BMS