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-current" 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>