Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Nov 2001 15:48:37 -0800
From:      Julian Elischer <julian@vicor-nb.com>
To:        current@freebsd.org, net@freebsd.org
Subject:   re-entrancy and the IP stack.
Message-ID:  <3BF5A5D5.3D408744@vicor-nb.com>

next in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF5A5D5.3D408744>