2005-01-06 23:35:40 +00:00
|
|
|
/*-
|
1994-05-24 10:09:53 +00:00
|
|
|
* Copyright (c) 1982, 1986, 1993
|
|
|
|
|
* The Regents of the University of California. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
* 4. Neither the name of the University nor the names of its contributors
|
|
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
|
* without specific prior written permission.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* @(#)uipc_domain.c 8.2 (Berkeley) 10/18/93
|
|
|
|
|
*/
|
|
|
|
|
|
2003-06-11 00:56:59 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
|
1994-05-24 10:09:53 +00:00
|
|
|
#include <sys/param.h>
|
2002-05-31 11:52:35 +00:00
|
|
|
#include <sys/socket.h>
|
|
|
|
|
#include <sys/protosw.h>
|
1994-05-24 10:09:53 +00:00
|
|
|
#include <sys/domain.h>
|
2006-04-21 09:25:40 +00:00
|
|
|
#include <sys/eventhandler.h>
|
2002-05-20 05:41:09 +00:00
|
|
|
#include <sys/mbuf.h>
|
2002-05-31 11:52:35 +00:00
|
|
|
#include <sys/kernel.h>
|
2003-09-01 05:01:55 +00:00
|
|
|
#include <sys/lock.h>
|
|
|
|
|
#include <sys/mutex.h>
|
1998-05-15 20:11:40 +00:00
|
|
|
#include <sys/socketvar.h>
|
1994-05-24 10:09:53 +00:00
|
|
|
#include <sys/systm.h>
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
#include <sys/vimage.h>
|
2002-03-20 04:09:59 +00:00
|
|
|
#include <vm/uma.h>
|
1994-05-24 10:09:53 +00:00
|
|
|
|
1995-08-28 09:19:25 +00:00
|
|
|
/*
|
|
|
|
|
* System initialization
|
|
|
|
|
*
|
2001-12-08 04:20:54 +00:00
|
|
|
* Note: domain initialization takes place on a per domain basis
|
|
|
|
|
* as a result of traversing a SYSINIT linker set. Most likely,
|
|
|
|
|
* each domain would want to call DOMAIN_SET(9) itself, which
|
|
|
|
|
* would cause the domain to be added just after domaininit()
|
|
|
|
|
* is called during startup.
|
1995-08-28 09:19:25 +00:00
|
|
|
*
|
2001-12-08 04:20:54 +00:00
|
|
|
* See DOMAIN_SET(9) for details on its use.
|
1995-08-28 09:19:25 +00:00
|
|
|
*/
|
|
|
|
|
|
2002-03-19 21:25:46 +00:00
|
|
|
static void domaininit(void *);
|
2008-03-16 10:58:09 +00:00
|
|
|
SYSINIT(domain, SI_SUB_PROTO_DOMAIN, SI_ORDER_FIRST, domaininit, NULL);
|
1995-08-28 09:19:25 +00:00
|
|
|
|
2004-11-30 22:38:37 +00:00
|
|
|
static void domainfinalize(void *);
|
|
|
|
|
SYSINIT(domainfin, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_FIRST, domainfinalize,
|
2008-03-16 10:58:09 +00:00
|
|
|
NULL);
|
2004-11-30 22:38:37 +00:00
|
|
|
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
static vnet_attach_fn net_init_domain;
|
Introduce an infrastructure for dismantling vnet instances.
Vnet modules and protocol domains may now register destructor
functions to clean up and release per-module state. The destructor
mechanisms can be triggered by invoking "vimage -d", or a future
equivalent command which will be provided via the new jail framework.
While this patch introduces numerous placeholder destructor functions,
many of those are currently incomplete, thus leaking memory or (even
worse) failing to stop all running timers. Many of such issues are
already known and will be incrementaly fixed over the next weeks in
smaller incremental commits.
Apart from introducing new fields in structs ifnet, domain, protosw
and vnet_net, which requires the kernel and modules to be rebuilt, this
change should have no impact on nooptions VIMAGE builds, since vnet
destructors can only be called in VIMAGE kernels. Moreover,
destructor functions should be in general compiled in only in
options VIMAGE builds, except for kernel modules which can be safely
kldunloaded at run time.
Bump __FreeBSD_version to 800097.
Reviewed by: bz, julian
Approved by: rwatson, kib (re), julian (mentor)
2009-06-08 17:15:40 +00:00
|
|
|
#ifdef VIMAGE
|
|
|
|
|
static vnet_detach_fn net_detach_domain;
|
|
|
|
|
#endif
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
|
2000-11-27 22:52:31 +00:00
|
|
|
static struct callout pffast_callout;
|
|
|
|
|
static struct callout pfslow_callout;
|
|
|
|
|
|
2002-03-19 21:25:46 +00:00
|
|
|
static void pffasttimo(void *);
|
|
|
|
|
static void pfslowtimo(void *);
|
1994-05-24 10:09:53 +00:00
|
|
|
|
2003-09-01 05:01:55 +00:00
|
|
|
struct domain *domains; /* registered protocol domains */
|
2004-11-30 22:38:37 +00:00
|
|
|
int domain_init_status = 0;
|
2009-01-04 19:22:53 +00:00
|
|
|
static struct mtx dom_mtx; /* domain list lock */
|
2003-09-02 20:59:23 +00:00
|
|
|
MTX_SYSINIT(domain, &dom_mtx, "domain list", MTX_DEF);
|
1995-05-11 00:13:26 +00:00
|
|
|
|
2004-10-19 15:13:30 +00:00
|
|
|
/*
|
|
|
|
|
* Dummy protocol specific user requests function pointer array.
|
|
|
|
|
* All functions return EOPNOTSUPP.
|
|
|
|
|
*/
|
|
|
|
|
struct pr_usrreqs nousrreqs = {
|
2004-11-08 14:44:54 +00:00
|
|
|
.pru_accept = pru_accept_notsupp,
|
|
|
|
|
.pru_attach = pru_attach_notsupp,
|
|
|
|
|
.pru_bind = pru_bind_notsupp,
|
|
|
|
|
.pru_connect = pru_connect_notsupp,
|
|
|
|
|
.pru_connect2 = pru_connect2_notsupp,
|
|
|
|
|
.pru_control = pru_control_notsupp,
|
|
|
|
|
.pru_disconnect = pru_disconnect_notsupp,
|
|
|
|
|
.pru_listen = pru_listen_notsupp,
|
|
|
|
|
.pru_peeraddr = pru_peeraddr_notsupp,
|
|
|
|
|
.pru_rcvd = pru_rcvd_notsupp,
|
|
|
|
|
.pru_rcvoob = pru_rcvoob_notsupp,
|
|
|
|
|
.pru_send = pru_send_notsupp,
|
|
|
|
|
.pru_sense = pru_sense_null,
|
|
|
|
|
.pru_shutdown = pru_shutdown_notsupp,
|
|
|
|
|
.pru_sockaddr = pru_sockaddr_notsupp,
|
|
|
|
|
.pru_sosend = pru_sosend_notsupp,
|
|
|
|
|
.pru_soreceive = pru_soreceive_notsupp,
|
|
|
|
|
.pru_sopoll = pru_sopoll_notsupp,
|
2004-10-19 15:13:30 +00:00
|
|
|
};
|
|
|
|
|
|
Build on Jeff Roberson's linker-set based dynamic per-CPU allocator
(DPCPU), as suggested by Peter Wemm, and implement a new per-virtual
network stack memory allocator. Modify vnet to use the allocator
instead of monolithic global container structures (vinet, ...). This
change solves many binary compatibility problems associated with
VIMAGE, and restores ELF symbols for virtualized global variables.
Each virtualized global variable exists as a "reference copy", and also
once per virtual network stack. Virtualized global variables are
tagged at compile-time, placing the in a special linker set, which is
loaded into a contiguous region of kernel memory. Virtualized global
variables in the base kernel are linked as normal, but those in modules
are copied and relocated to a reserved portion of the kernel's vnet
region with the help of a the kernel linker.
Virtualized global variables exist in per-vnet memory set up when the
network stack instance is created, and are initialized statically from
the reference copy. Run-time access occurs via an accessor macro, which
converts from the current vnet and requested symbol to a per-vnet
address. When "options VIMAGE" is not compiled into the kernel, normal
global ELF symbols will be used instead and indirection is avoided.
This change restores static initialization for network stack global
variables, restores support for non-global symbols and types, eliminates
the need for many subsystem constructors, eliminates large per-subsystem
structures that caused many binary compatibility issues both for
monitoring applications (netstat) and kernel modules, removes the
per-function INIT_VNET_*() macros throughout the stack, eliminates the
need for vnet_symmap ksym(2) munging, and eliminates duplicate
definitions of virtualized globals under VIMAGE_GLOBALS.
Bump __FreeBSD_version and update UPDATING.
Portions submitted by: bz
Reviewed by: bz, zec
Discussed with: gnn, jamie, jeff, jhb, julian, sam
Suggested by: peter
Approved by: re (kensmith)
2009-07-14 22:48:30 +00:00
|
|
|
#ifdef VIMAGE
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
vnet_modinfo_t vnet_domain_modinfo = {
|
|
|
|
|
.vmi_id = VNET_MOD_DOMAIN,
|
|
|
|
|
.vmi_name = "domain",
|
Introduce an infrastructure for dismantling vnet instances.
Vnet modules and protocol domains may now register destructor
functions to clean up and release per-module state. The destructor
mechanisms can be triggered by invoking "vimage -d", or a future
equivalent command which will be provided via the new jail framework.
While this patch introduces numerous placeholder destructor functions,
many of those are currently incomplete, thus leaking memory or (even
worse) failing to stop all running timers. Many of such issues are
already known and will be incrementaly fixed over the next weeks in
smaller incremental commits.
Apart from introducing new fields in structs ifnet, domain, protosw
and vnet_net, which requires the kernel and modules to be rebuilt, this
change should have no impact on nooptions VIMAGE builds, since vnet
destructors can only be called in VIMAGE kernels. Moreover,
destructor functions should be in general compiled in only in
options VIMAGE builds, except for kernel modules which can be safely
kldunloaded at run time.
Bump __FreeBSD_version to 800097.
Reviewed by: bz, julian
Approved by: rwatson, kib (re), julian (mentor)
2009-06-08 17:15:40 +00:00
|
|
|
.vmi_iattach = net_init_domain,
|
|
|
|
|
.vmi_idetach = net_detach_domain,
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
2004-11-11 19:19:54 +00:00
|
|
|
static void
|
|
|
|
|
protosw_init(struct protosw *pr)
|
|
|
|
|
{
|
|
|
|
|
struct pr_usrreqs *pu;
|
|
|
|
|
|
|
|
|
|
pu = pr->pr_usrreqs;
|
|
|
|
|
KASSERT(pu != NULL, ("protosw_init: %ssw[%d] has no usrreqs!",
|
|
|
|
|
pr->pr_domain->dom_name,
|
|
|
|
|
(int)(pr - pr->pr_domain->dom_protosw)));
|
|
|
|
|
|
2008-12-25 11:32:38 +00:00
|
|
|
/*
|
|
|
|
|
* Protocol switch methods fall into three categories: mandatory,
|
|
|
|
|
* mandatory but protosw_init() provides a default, and optional.
|
|
|
|
|
*
|
|
|
|
|
* For true protocols (i.e., pru_attach != NULL), KASSERT truly
|
|
|
|
|
* mandatory methods with no defaults, and initialize defaults for
|
|
|
|
|
* other mandatory methods if the protocol hasn't defined an
|
|
|
|
|
* implementation (NULL function pointer).
|
|
|
|
|
*/
|
|
|
|
|
#if 0
|
|
|
|
|
if (pu->pru_attach != NULL) {
|
|
|
|
|
KASSERT(pu->pru_abort != NULL,
|
|
|
|
|
("protosw_init: %ssw[%d] pru_abort NULL",
|
|
|
|
|
pr->pr_domain->dom_name,
|
|
|
|
|
(int)(pr - pr->pr_domain->dom_protosw)));
|
|
|
|
|
KASSERT(pu->pru_send != NULL,
|
|
|
|
|
("protosw_init: %ssw[%d] pru_send NULL",
|
|
|
|
|
pr->pr_domain->dom_name,
|
|
|
|
|
(int)(pr - pr->pr_domain->dom_protosw)));
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2004-11-11 19:19:54 +00:00
|
|
|
#define DEFAULT(foo, bar) if ((foo) == NULL) (foo) = (bar)
|
|
|
|
|
DEFAULT(pu->pru_accept, pru_accept_notsupp);
|
2008-12-23 01:23:09 +00:00
|
|
|
DEFAULT(pu->pru_bind, pru_bind_notsupp);
|
2004-11-11 19:19:54 +00:00
|
|
|
DEFAULT(pu->pru_connect, pru_connect_notsupp);
|
|
|
|
|
DEFAULT(pu->pru_connect2, pru_connect2_notsupp);
|
|
|
|
|
DEFAULT(pu->pru_control, pru_control_notsupp);
|
2008-12-23 01:23:09 +00:00
|
|
|
DEFAULT(pu->pru_disconnect, pru_disconnect_notsupp);
|
2004-11-11 19:19:54 +00:00
|
|
|
DEFAULT(pu->pru_listen, pru_listen_notsupp);
|
2008-12-23 01:23:09 +00:00
|
|
|
DEFAULT(pu->pru_peeraddr, pru_peeraddr_notsupp);
|
2004-11-11 19:19:54 +00:00
|
|
|
DEFAULT(pu->pru_rcvd, pru_rcvd_notsupp);
|
|
|
|
|
DEFAULT(pu->pru_rcvoob, pru_rcvoob_notsupp);
|
|
|
|
|
DEFAULT(pu->pru_sense, pru_sense_null);
|
2008-12-23 01:23:09 +00:00
|
|
|
DEFAULT(pu->pru_shutdown, pru_shutdown_notsupp);
|
|
|
|
|
DEFAULT(pu->pru_sockaddr, pru_sockaddr_notsupp);
|
soreceive_generic(), and sopoll_generic(). Add new functions sosend(),
soreceive(), and sopoll(), which are wrappers for pru_sosend,
pru_soreceive, and pru_sopoll, and are now used univerally by socket
consumers rather than either directly invoking the old so*() functions
or directly invoking the protocol switch method (about an even split
prior to this commit).
This completes an architectural change that was begun in 1996 to permit
protocols to provide substitute implementations, as now used by UDP.
Consumers now uniformly invoke sosend(), soreceive(), and sopoll() to
perform these operations on sockets -- in particular, distributed file
systems and socket system calls.
Architectural head nod: sam, gnn, wollman
2006-07-24 15:20:08 +00:00
|
|
|
DEFAULT(pu->pru_sosend, sosend_generic);
|
|
|
|
|
DEFAULT(pu->pru_soreceive, soreceive_generic);
|
|
|
|
|
DEFAULT(pu->pru_sopoll, sopoll_generic);
|
2004-11-11 19:19:54 +00:00
|
|
|
#undef DEFAULT
|
|
|
|
|
if (pr->pr_init)
|
|
|
|
|
(*pr->pr_init)();
|
|
|
|
|
}
|
|
|
|
|
|
1999-01-21 00:26:41 +00:00
|
|
|
/*
|
|
|
|
|
* Add a new protocol domain to the list of supported domains
|
2004-10-19 15:13:30 +00:00
|
|
|
* Note: you cant unload it again because a socket may be using it.
|
1999-01-21 00:26:41 +00:00
|
|
|
* XXX can't fail at this time.
|
|
|
|
|
*/
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
static int
|
|
|
|
|
net_init_domain(const void *arg)
|
1999-01-21 00:26:41 +00:00
|
|
|
{
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
const struct domain *dp = arg;
|
2003-09-01 05:01:55 +00:00
|
|
|
struct protosw *pr;
|
1999-01-21 00:26:41 +00:00
|
|
|
|
|
|
|
|
if (dp->dom_init)
|
|
|
|
|
(*dp->dom_init)();
|
2004-11-11 19:19:54 +00:00
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
protosw_init(pr);
|
1999-01-21 00:26:41 +00:00
|
|
|
/*
|
2003-03-07 22:47:32 +00:00
|
|
|
* update global information about maximums
|
1999-01-21 00:26:41 +00:00
|
|
|
*/
|
|
|
|
|
max_hdr = max_linkhdr + max_protohdr;
|
|
|
|
|
max_datalen = MHLEN - max_hdr;
|
2006-02-18 17:16:18 +00:00
|
|
|
if (max_datalen < 1)
|
|
|
|
|
panic("%s: max_datalen < 1", __func__);
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
return (0);
|
1999-01-21 00:26:41 +00:00
|
|
|
}
|
|
|
|
|
|
Introduce an infrastructure for dismantling vnet instances.
Vnet modules and protocol domains may now register destructor
functions to clean up and release per-module state. The destructor
mechanisms can be triggered by invoking "vimage -d", or a future
equivalent command which will be provided via the new jail framework.
While this patch introduces numerous placeholder destructor functions,
many of those are currently incomplete, thus leaking memory or (even
worse) failing to stop all running timers. Many of such issues are
already known and will be incrementaly fixed over the next weeks in
smaller incremental commits.
Apart from introducing new fields in structs ifnet, domain, protosw
and vnet_net, which requires the kernel and modules to be rebuilt, this
change should have no impact on nooptions VIMAGE builds, since vnet
destructors can only be called in VIMAGE kernels. Moreover,
destructor functions should be in general compiled in only in
options VIMAGE builds, except for kernel modules which can be safely
kldunloaded at run time.
Bump __FreeBSD_version to 800097.
Reviewed by: bz, julian
Approved by: rwatson, kib (re), julian (mentor)
2009-06-08 17:15:40 +00:00
|
|
|
#ifdef VIMAGE
|
|
|
|
|
/*
|
|
|
|
|
* Detach / free a domain instance.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
net_detach_domain(const void *arg)
|
|
|
|
|
{
|
|
|
|
|
const struct domain *dp = arg;
|
|
|
|
|
struct protosw *pr;
|
|
|
|
|
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
if (pr->pr_destroy)
|
|
|
|
|
(*pr->pr_destroy)();
|
|
|
|
|
if (dp->dom_destroy)
|
|
|
|
|
(*dp->dom_destroy)();
|
|
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
1999-01-21 00:26:41 +00:00
|
|
|
/*
|
|
|
|
|
* Add a new protocol domain to the list of supported domains
|
2004-10-19 15:13:30 +00:00
|
|
|
* Note: you cant unload it again because a socket may be using it.
|
1999-01-21 00:26:41 +00:00
|
|
|
* XXX can't fail at this time.
|
|
|
|
|
*/
|
1999-04-26 08:56:09 +00:00
|
|
|
void
|
|
|
|
|
net_add_domain(void *data)
|
1999-01-21 00:26:41 +00:00
|
|
|
{
|
1999-04-26 08:56:09 +00:00
|
|
|
struct domain *dp;
|
1999-01-21 00:26:41 +00:00
|
|
|
|
1999-04-26 08:56:09 +00:00
|
|
|
dp = (struct domain *)data;
|
2003-09-01 05:01:55 +00:00
|
|
|
mtx_lock(&dom_mtx);
|
1999-01-21 00:26:41 +00:00
|
|
|
dp->dom_next = domains;
|
|
|
|
|
domains = dp;
|
2004-11-30 22:38:37 +00:00
|
|
|
|
|
|
|
|
KASSERT(domain_init_status >= 1,
|
|
|
|
|
("attempt to net_add_domain(%s) before domaininit()",
|
|
|
|
|
dp->dom_name));
|
|
|
|
|
#ifndef INVARIANTS
|
2004-12-02 15:47:15 +00:00
|
|
|
if (domain_init_status < 1)
|
2004-11-30 22:38:37 +00:00
|
|
|
printf("WARNING: attempt to net_add_domain(%s) before "
|
|
|
|
|
"domaininit()\n", dp->dom_name);
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef notyet
|
|
|
|
|
KASSERT(domain_init_status < 2,
|
|
|
|
|
("attempt to net_add_domain(%s) after domainfinalize()",
|
|
|
|
|
dp->dom_name));
|
|
|
|
|
#else
|
2004-12-02 15:47:15 +00:00
|
|
|
if (domain_init_status >= 2)
|
2004-11-30 22:38:37 +00:00
|
|
|
printf("WARNING: attempt to net_add_domain(%s) after "
|
|
|
|
|
"domainfinalize()\n", dp->dom_name);
|
|
|
|
|
#endif
|
2003-09-01 05:01:55 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
Build on Jeff Roberson's linker-set based dynamic per-CPU allocator
(DPCPU), as suggested by Peter Wemm, and implement a new per-virtual
network stack memory allocator. Modify vnet to use the allocator
instead of monolithic global container structures (vinet, ...). This
change solves many binary compatibility problems associated with
VIMAGE, and restores ELF symbols for virtualized global variables.
Each virtualized global variable exists as a "reference copy", and also
once per virtual network stack. Virtualized global variables are
tagged at compile-time, placing the in a special linker set, which is
loaded into a contiguous region of kernel memory. Virtualized global
variables in the base kernel are linked as normal, but those in modules
are copied and relocated to a reserved portion of the kernel's vnet
region with the help of a the kernel linker.
Virtualized global variables exist in per-vnet memory set up when the
network stack instance is created, and are initialized statically from
the reference copy. Run-time access occurs via an accessor macro, which
converts from the current vnet and requested symbol to a per-vnet
address. When "options VIMAGE" is not compiled into the kernel, normal
global ELF symbols will be used instead and indirection is avoided.
This change restores static initialization for network stack global
variables, restores support for non-global symbols and types, eliminates
the need for many subsystem constructors, eliminates large per-subsystem
structures that caused many binary compatibility issues both for
monitoring applications (netstat) and kernel modules, removes the
per-function INIT_VNET_*() macros throughout the stack, eliminates the
need for vnet_symmap ksym(2) munging, and eliminates duplicate
definitions of virtualized globals under VIMAGE_GLOBALS.
Bump __FreeBSD_version and update UPDATING.
Portions submitted by: bz
Reviewed by: bz, zec
Discussed with: gnn, jamie, jeff, jhb, julian, sam
Suggested by: peter
Approved by: re (kensmith)
2009-07-14 22:48:30 +00:00
|
|
|
#ifdef VIMAGE
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
vnet_mod_register_multi(&vnet_domain_modinfo, dp, dp->dom_name);
|
|
|
|
|
#else
|
1999-04-26 08:56:09 +00:00
|
|
|
net_init_domain(dp);
|
Introduce vnet module registration / initialization framework with
dependency tracking and ordering enforcement.
With this change, per-vnet initialization functions introduced with
r190787 are no longer directly called from traditional initialization
functions (which cc in most cases inlined to pre-r190787 code), but are
instead registered via the vnet framework first, and are invoked only
after all prerequisite modules have been initialized. In the long run,
this framework should allow us to both initialize and dismantle
multiple vnet instances in a correct order.
The problem this change aims to solve is how to replay the
initialization sequence of various network stack components, which
have been traditionally triggered via different mechanisms (SYSINIT,
protosw). Note that this initialization sequence was and still can be
subtly different depending on whether certain pieces of code have been
statically compiled into the kernel, loaded as modules by boot
loader, or kldloaded at run time.
The approach is simple - we record the initialization sequence
established by the traditional mechanisms whenever vnet_mod_register()
is called for a particular vnet module. The vnet_mod_register_multi()
variant allows a single initializer function to be registered multiple
times but with different arguments - currently this is only used in
kern/uipc_domain.c by net_add_domain() with different struct domain *
as arguments, which allows for protosw-registered initialization
routines to be invoked in a correct order by the new vnet
initialization framework.
For the purpose of identifying vnet modules, each vnet module has to
have a unique ID, which is statically assigned in sys/vimage.h.
Dynamic assignment of vnet module IDs is not supported yet.
A vnet module may specify a single prerequisite module at registration
time by filling in the vmi_dependson field of its vnet_modinfo struct
with the ID of the module it depends on. Unless specified otherwise,
all vnet modules depend on VNET_MOD_NET (container for ifnet list head,
rt_tables etc.), which thus has to and will always be initialized
first. The framework will panic if it detects any unresolved
dependencies before completing system initialization. Detection of
unresolved dependencies for vnet modules registered after boot
(kldloaded modules) is not provided.
Note that the fact that each module can specify only a single
prerequisite may become problematic in the long run. In particular,
INET6 depends on INET being already instantiated, due to TCP / UDP
structures residing in INET container. IPSEC also depends on INET,
which will in turn additionally complicate making INET6-only kernel
configs a reality.
The entire registration framework can be compiled out by turning on the
VIMAGE_GLOBALS kernel config option.
Reviewed by: bz
Approved by: julian (mentor)
2009-04-11 05:58:58 +00:00
|
|
|
#endif
|
1994-05-24 10:09:53 +00:00
|
|
|
}
|
|
|
|
|
|
2006-04-21 09:25:40 +00:00
|
|
|
static void
|
|
|
|
|
socket_zone_change(void *tag)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
uma_zone_set_max(socket_zone, maxsockets);
|
|
|
|
|
}
|
|
|
|
|
|
1995-08-28 09:19:25 +00:00
|
|
|
/* ARGSUSED*/
|
|
|
|
|
static void
|
1999-01-21 00:26:41 +00:00
|
|
|
domaininit(void *dummy)
|
1994-05-24 10:09:53 +00:00
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
|
1998-05-15 20:11:40 +00:00
|
|
|
/*
|
|
|
|
|
* Before we do any setup, make sure to initialize the
|
2002-03-20 04:09:59 +00:00
|
|
|
* zone allocator we get struct sockets from.
|
1998-05-15 20:11:40 +00:00
|
|
|
*/
|
2002-03-20 04:09:59 +00:00
|
|
|
socket_zone = uma_zcreate("socket", sizeof(struct socket), NULL, NULL,
|
|
|
|
|
NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
|
2002-03-20 05:30:58 +00:00
|
|
|
uma_zone_set_max(socket_zone, maxsockets);
|
2006-04-21 09:25:40 +00:00
|
|
|
EVENTHANDLER_REGISTER(maxsockets_change, socket_zone_change, NULL,
|
|
|
|
|
EVENTHANDLER_PRI_FIRST);
|
1998-05-15 20:11:40 +00:00
|
|
|
|
1999-01-21 00:26:41 +00:00
|
|
|
if (max_linkhdr < 16) /* XXX */
|
|
|
|
|
max_linkhdr = 16;
|
|
|
|
|
|
2007-07-27 11:59:57 +00:00
|
|
|
callout_init(&pffast_callout, CALLOUT_MPSAFE);
|
|
|
|
|
callout_init(&pfslow_callout, CALLOUT_MPSAFE);
|
2000-11-27 22:52:31 +00:00
|
|
|
|
2004-11-30 22:38:37 +00:00
|
|
|
mtx_lock(&dom_mtx);
|
|
|
|
|
KASSERT(domain_init_status == 0, ("domaininit called too late!"));
|
|
|
|
|
domain_init_status = 1;
|
|
|
|
|
mtx_unlock(&dom_mtx);
|
1994-05-24 10:09:53 +00:00
|
|
|
}
|
|
|
|
|
|
2004-11-30 22:38:37 +00:00
|
|
|
/* ARGSUSED*/
|
|
|
|
|
static void
|
|
|
|
|
domainfinalize(void *dummy)
|
|
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
|
2004-11-30 22:38:37 +00:00
|
|
|
mtx_lock(&dom_mtx);
|
|
|
|
|
KASSERT(domain_init_status == 1, ("domainfinalize called too late!"));
|
|
|
|
|
domain_init_status = 2;
|
|
|
|
|
mtx_unlock(&dom_mtx);
|
2004-12-09 11:47:30 +00:00
|
|
|
|
|
|
|
|
callout_reset(&pffast_callout, 1, pffasttimo, NULL);
|
|
|
|
|
callout_reset(&pfslow_callout, 1, pfslowtimo, NULL);
|
2004-11-30 22:38:37 +00:00
|
|
|
}
|
1995-08-28 09:19:25 +00:00
|
|
|
|
1994-05-24 10:09:53 +00:00
|
|
|
struct protosw *
|
2007-05-16 20:41:08 +00:00
|
|
|
pffindtype(int family, int type)
|
1994-05-24 10:09:53 +00:00
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr;
|
1994-05-24 10:09:53 +00:00
|
|
|
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
if (dp->dom_family == family)
|
|
|
|
|
goto found;
|
|
|
|
|
return (0);
|
|
|
|
|
found:
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
if (pr->pr_type && pr->pr_type == type)
|
|
|
|
|
return (pr);
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct protosw *
|
2007-05-16 20:41:08 +00:00
|
|
|
pffindproto(int family, int protocol, int type)
|
1994-05-24 10:09:53 +00:00
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr;
|
1994-05-24 10:09:53 +00:00
|
|
|
struct protosw *maybe = 0;
|
|
|
|
|
|
|
|
|
|
if (family == 0)
|
|
|
|
|
return (0);
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
if (dp->dom_family == family)
|
|
|
|
|
goto found;
|
|
|
|
|
return (0);
|
|
|
|
|
found:
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) {
|
|
|
|
|
if ((pr->pr_protocol == protocol) && (pr->pr_type == type))
|
|
|
|
|
return (pr);
|
|
|
|
|
|
|
|
|
|
if (type == SOCK_RAW && pr->pr_type == SOCK_RAW &&
|
|
|
|
|
pr->pr_protocol == 0 && maybe == (struct protosw *)0)
|
|
|
|
|
maybe = pr;
|
|
|
|
|
}
|
|
|
|
|
return (maybe);
|
|
|
|
|
}
|
|
|
|
|
|
2004-10-19 15:13:30 +00:00
|
|
|
/*
|
|
|
|
|
* The caller must make sure that the new protocol is fully set up and ready to
|
|
|
|
|
* accept requests before it is registered.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2007-05-16 20:41:08 +00:00
|
|
|
pf_proto_register(int family, struct protosw *npr)
|
2004-10-19 15:13:30 +00:00
|
|
|
{
|
|
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr, *fpr;
|
|
|
|
|
|
|
|
|
|
/* Sanity checks. */
|
|
|
|
|
if (family == 0)
|
|
|
|
|
return (EPFNOSUPPORT);
|
|
|
|
|
if (npr->pr_type == 0)
|
|
|
|
|
return (EPROTOTYPE);
|
|
|
|
|
if (npr->pr_protocol == 0)
|
|
|
|
|
return (EPROTONOSUPPORT);
|
|
|
|
|
if (npr->pr_usrreqs == NULL)
|
|
|
|
|
return (ENXIO);
|
|
|
|
|
|
|
|
|
|
/* Try to find the specified domain based on the family. */
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
if (dp->dom_family == family)
|
|
|
|
|
goto found;
|
|
|
|
|
return (EPFNOSUPPORT);
|
|
|
|
|
|
|
|
|
|
found:
|
|
|
|
|
/* Initialize backpointer to struct domain. */
|
|
|
|
|
npr->pr_domain = dp;
|
|
|
|
|
fpr = NULL;
|
|
|
|
|
|
2004-10-23 18:52:06 +00:00
|
|
|
/*
|
|
|
|
|
* Protect us against races when two protocol registrations for
|
|
|
|
|
* the same protocol happen at the same time.
|
|
|
|
|
*/
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_lock(&dom_mtx);
|
2004-10-23 18:52:06 +00:00
|
|
|
|
2004-10-19 15:13:30 +00:00
|
|
|
/* The new protocol must not yet exist. */
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) {
|
|
|
|
|
if ((pr->pr_type == npr->pr_type) &&
|
2004-10-23 18:52:06 +00:00
|
|
|
(pr->pr_protocol == npr->pr_protocol)) {
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
2004-10-19 15:13:30 +00:00
|
|
|
return (EEXIST); /* XXX: Check only protocol? */
|
2004-10-23 18:52:06 +00:00
|
|
|
}
|
2004-10-19 15:13:30 +00:00
|
|
|
/* While here, remember the first free spacer. */
|
|
|
|
|
if ((fpr == NULL) && (pr->pr_protocol == PROTO_SPACER))
|
|
|
|
|
fpr = pr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If no free spacer is found we can't add the new protocol. */
|
2004-10-23 18:52:06 +00:00
|
|
|
if (fpr == NULL) {
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
2004-10-19 15:13:30 +00:00
|
|
|
return (ENOMEM);
|
2004-10-23 18:52:06 +00:00
|
|
|
}
|
2004-10-19 15:13:30 +00:00
|
|
|
|
|
|
|
|
/* Copy the new struct protosw over the spacer. */
|
|
|
|
|
bcopy(npr, fpr, sizeof(*fpr));
|
|
|
|
|
|
2004-10-23 18:52:06 +00:00
|
|
|
/* Job is done, no more protection required. */
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
2004-10-23 18:52:06 +00:00
|
|
|
|
2004-10-19 15:13:30 +00:00
|
|
|
/* Initialize and activate the protocol. */
|
2004-11-11 19:19:54 +00:00
|
|
|
protosw_init(fpr);
|
2004-10-19 15:13:30 +00:00
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The caller must make sure the protocol and its functions correctly shut down
|
|
|
|
|
* all sockets and release all locks and memory references.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2007-05-16 20:41:08 +00:00
|
|
|
pf_proto_unregister(int family, int protocol, int type)
|
2004-10-19 15:13:30 +00:00
|
|
|
{
|
|
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr, *dpr;
|
|
|
|
|
|
|
|
|
|
/* Sanity checks. */
|
|
|
|
|
if (family == 0)
|
|
|
|
|
return (EPFNOSUPPORT);
|
|
|
|
|
if (protocol == 0)
|
|
|
|
|
return (EPROTONOSUPPORT);
|
|
|
|
|
if (type == 0)
|
|
|
|
|
return (EPROTOTYPE);
|
|
|
|
|
|
|
|
|
|
/* Try to find the specified domain based on the family type. */
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
if (dp->dom_family == family)
|
|
|
|
|
goto found;
|
|
|
|
|
return (EPFNOSUPPORT);
|
|
|
|
|
|
|
|
|
|
found:
|
|
|
|
|
dpr = NULL;
|
|
|
|
|
|
2004-10-23 18:52:06 +00:00
|
|
|
/* Lock out everyone else while we are manipulating the protosw. */
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_lock(&dom_mtx);
|
2004-10-23 18:52:06 +00:00
|
|
|
|
2004-10-19 15:13:30 +00:00
|
|
|
/* The protocol must exist and only once. */
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++) {
|
|
|
|
|
if ((pr->pr_type == type) && (pr->pr_protocol == protocol)) {
|
2004-10-23 18:52:06 +00:00
|
|
|
if (dpr != NULL) {
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
2004-10-19 15:13:30 +00:00
|
|
|
return (EMLINK); /* Should not happen! */
|
2004-10-23 18:52:06 +00:00
|
|
|
} else
|
2004-10-19 15:13:30 +00:00
|
|
|
dpr = pr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Protocol does not exist. */
|
2004-10-23 18:52:06 +00:00
|
|
|
if (dpr == NULL) {
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
2004-10-19 15:13:30 +00:00
|
|
|
return (EPROTONOSUPPORT);
|
2004-10-23 18:52:06 +00:00
|
|
|
}
|
2004-10-19 15:13:30 +00:00
|
|
|
|
|
|
|
|
/* De-orbit the protocol and make the slot available again. */
|
|
|
|
|
dpr->pr_type = 0;
|
|
|
|
|
dpr->pr_domain = dp;
|
|
|
|
|
dpr->pr_protocol = PROTO_SPACER;
|
|
|
|
|
dpr->pr_flags = 0;
|
|
|
|
|
dpr->pr_input = NULL;
|
|
|
|
|
dpr->pr_output = NULL;
|
|
|
|
|
dpr->pr_ctlinput = NULL;
|
|
|
|
|
dpr->pr_ctloutput = NULL;
|
|
|
|
|
dpr->pr_init = NULL;
|
|
|
|
|
dpr->pr_fasttimo = NULL;
|
|
|
|
|
dpr->pr_slowtimo = NULL;
|
|
|
|
|
dpr->pr_drain = NULL;
|
|
|
|
|
dpr->pr_usrreqs = &nousrreqs;
|
|
|
|
|
|
2004-10-23 18:52:06 +00:00
|
|
|
/* Job is done, not more protection required. */
|
2009-01-04 19:22:53 +00:00
|
|
|
mtx_unlock(&dom_mtx);
|
2004-10-23 18:52:06 +00:00
|
|
|
|
2004-10-19 15:13:30 +00:00
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
1994-05-25 09:21:21 +00:00
|
|
|
void
|
2007-05-16 20:41:08 +00:00
|
|
|
pfctlinput(int cmd, struct sockaddr *sa)
|
1994-05-24 10:09:53 +00:00
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr;
|
1994-05-24 10:09:53 +00:00
|
|
|
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
if (pr->pr_ctlinput)
|
1995-12-16 02:14:44 +00:00
|
|
|
(*pr->pr_ctlinput)(cmd, sa, (void *)0);
|
1994-05-24 10:09:53 +00:00
|
|
|
}
|
|
|
|
|
|
2001-06-11 12:39:29 +00:00
|
|
|
void
|
2007-05-16 20:41:08 +00:00
|
|
|
pfctlinput2(int cmd, struct sockaddr *sa, void *ctlparam)
|
2001-06-11 12:39:29 +00:00
|
|
|
{
|
|
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr;
|
|
|
|
|
|
|
|
|
|
if (!sa)
|
|
|
|
|
return;
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next) {
|
|
|
|
|
/*
|
|
|
|
|
* the check must be made by xx_ctlinput() anyways, to
|
|
|
|
|
* make sure we use data item pointed to by ctlparam in
|
|
|
|
|
* correct way. the following check is made just for safety.
|
|
|
|
|
*/
|
|
|
|
|
if (dp->dom_family != sa->sa_family)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
if (pr->pr_ctlinput)
|
|
|
|
|
(*pr->pr_ctlinput)(cmd, sa, ctlparam);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
1995-11-16 19:00:27 +00:00
|
|
|
static void
|
2007-05-16 20:41:08 +00:00
|
|
|
pfslowtimo(void *arg)
|
1994-05-24 10:09:53 +00:00
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr;
|
1994-05-24 10:09:53 +00:00
|
|
|
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
if (pr->pr_slowtimo)
|
|
|
|
|
(*pr->pr_slowtimo)();
|
2000-11-27 22:52:31 +00:00
|
|
|
callout_reset(&pfslow_callout, hz/2, pfslowtimo, NULL);
|
1994-05-24 10:09:53 +00:00
|
|
|
}
|
|
|
|
|
|
1995-11-16 19:00:27 +00:00
|
|
|
static void
|
2007-05-16 20:41:08 +00:00
|
|
|
pffasttimo(void *arg)
|
1994-05-24 10:09:53 +00:00
|
|
|
{
|
2007-05-16 20:41:08 +00:00
|
|
|
struct domain *dp;
|
|
|
|
|
struct protosw *pr;
|
1994-05-24 10:09:53 +00:00
|
|
|
|
|
|
|
|
for (dp = domains; dp; dp = dp->dom_next)
|
|
|
|
|
for (pr = dp->dom_protosw; pr < dp->dom_protoswNPROTOSW; pr++)
|
|
|
|
|
if (pr->pr_fasttimo)
|
|
|
|
|
(*pr->pr_fasttimo)();
|
2000-11-27 22:52:31 +00:00
|
|
|
callout_reset(&pffast_callout, hz/5, pffasttimo, NULL);
|
1994-05-24 10:09:53 +00:00
|
|
|
}
|
