From owner-freebsd-net Fri Nov 16 15:48:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id 6AFE337B416; Fri, 16 Nov 2001 15:48:37 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 2A9721B219; Fri, 16 Nov 2001 15:48:37 -0800 (PST) Message-ID: <3BF5A5D5.3D408744@vicor-nb.com> Date: Fri, 16 Nov 2001 15:48:37 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org Subject: re-entrancy and the IP stack. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org For work related erasons I've been in the IP stack (basically just IP actually) recently. It's obvious that there are re-entrancy problems there. Here are two examples.. Routed packets: a packet that is routed, uses a single static 'route' entry... (In ip_input.c) Right next to it is a sockaddr_in that is used by outgoing icmp packets. static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; struct route ipforward_rt; Obviously there cannot be more than one packet being routed at a time, and no more than one ICMP packet being generated at a time. As another example, the ipfw code uses a couple of static variables too, in the 'fwd' code amongst other places.. What is needed is obviously a 'per packet' storage location for those things, defined in a "per protocol family" manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. The netgraph code already has a simialr mechanism, in that data is always (optionally) accompanied by a metadata structure, the format of which is predefined in such a way that allows extensibility and transparency. What I would like to do is to combine these two methods: i.e. use the extensible format, embedded in a specially marked mbuf, prepended onto the packets (or post-pended?). The format of the data within the mbuf should have the following characteristics: 1/ It should identify the interface that defines that data, (so that modules can identify their own metadata/information) 2/ It should define in a standard way, its size. 3/ Metadata from several modules should be capable of being added to a packet at the same time, either by adding more mbufs or by adding more self-identifying data to an already existing mbuf. 4/ Registered modules should be called to "disarm" their metadata if the packet is deleted.. Metadata should be able to indicate if it needs to be disarmed or can be just freed. An example for data needed in IP packets: [sizeof(struct route)][IP-ID]["Forwarding Route" ID][struct route] [sizeof(struct sockaddr_in)][IP_ID]["Dest-addr" ID][struct sockaddr_in] [sizeof(struct sockaddr_in)][IP_ID]["Fwd-destaddr" ID][struct sockaddr_in] These would be packed in a MT_PROTOSTORAGE mbuf and prepended to packets being routeds or forwarded, (or whatever) so that each packet would carry with it whatever information was needed to be handled correctly. It could also (for example) be handed to a 3rd party module (e.g. a firewall) which could queue the packet (or similar) and not have to worry about losing 'hidden' state being held elsewhere. Any comments? (obviously we'd have to educate code to skip or ignore these packets if they didn't have any use for them.) But we are going to need to do something like this to make some of the code re-entrant eventually! Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message