#
302054 |
|
21-Jun-2016 |
bz |
Get closer to a VIMAGE network stack teardown from top to bottom rather than removing the network interfaces first. This change is rather larger and convoluted as the ordering requirements cannot be separated.
Move the pfil(9) framework to SI_SUB_PROTO_PFIL, move Firewalls and related modules to their own SI_SUB_PROTO_FIREWALL. Move initialization of "physical" interfaces to SI_SUB_DRIVERS, move virtual (cloned) interfaces to SI_SUB_PSEUDO. Move Multicast to SI_SUB_PROTO_MC.
Re-work parts of multicast initialisation and teardown, not taking the huge amount of memory into account if used as a module yet.
For interface teardown we try to do as many of them as we can on SI_SUB_INIT_IF, but for some this makes no sense, e.g., when tunnelling over a higher layer protocol such as IP. In that case the interface has to go along (or before) the higher layer protocol is shutdown.
Kernel hhooks need to go last on teardown as they may be used at various higher layers and we cannot remove them before we cleaned up the higher layers.
For interface teardown there are multiple paths: (a) a cloned interface is destroyed (inside a VIMAGE or in the base system), (b) any interface is moved from a virtual network stack to a different network stack ("vmove"), or (c) a virtual network stack is being shut down. All code paths go through if_detach_internal() where we, depending on the vmove flag or the vnet state, make a decision on how much to shut down; in case we are destroying a VNET the individual protocol layers will cleanup their own parts thus we cannot do so again for each interface as we end up with, e.g., double-frees, destroying locks twice or acquiring already destroyed locks. When calling into protocol cleanups we equally have to tell them whether they need to detach upper layer protocols ("ulp") or not (e.g., in6_ifdetach()).
Provide or enahnce helper functions to do proper cleanup at a protocol rather than at an interface level.
Approved by: re (hrs) Obtained from: projects/vnet Reviewed by: gnn, jhb Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6747
|
#
251752 |
|
14-Jun-2013 |
lstewart |
Fix a major oversight in r251732 which causes non-VIMAGE kernels to trigger a KASSERT during TCP hhook registration at boot. Virtualised hook points only require extra housekeeping and sanity checking when "options VIMAGE" is present.
Reported by: bdrewery,jh,dhw Tested by: dhw MFC after: 1 week X-MFC with: 251732
|
#
251732 |
|
14-Jun-2013 |
lstewart |
Add support for non-virtualised hhook points, which are uniquely identified by type and id, as compared to virtualised hook points which are now uniquely identified by type, id and a vid (which for vimage is the pointer to the vnet that the hhook resides in).
All hhook_head structs for both virtualised and non-virtualised hook points coexist in hhook_head_list, and a separate list is maintained for hhook points within each vnet to simplify some vimage-related housekeeping.
Reviewed by: scottl MFC after: 1 week
|
#
216615 |
|
21-Dec-2010 |
lstewart |
- Introduce the Hhook (Helper Hook) KPI. The KPI is closely modelled on pfil(9), and in many respects can be thought of as a more generic superset of pfil. Hhook provides a way for kernel subsystems to export hook points that Khelp modules can hook to provide enhanced or new functionality to the kernel. The KPI has been designed to ensure hook points pose no noticeable overhead when no hook functions are registered.
- Introduce the Khelp (Kernel Helpers) KPI. Khelp provides a framework for managing Khelp modules, which indirectly use the Hhook KPI to register their hook functions with hook points of interest within the kernel. Khelp modules aim to provide a structured way to dynamically extend the kernel at runtime in an ABI preserving manner. Depending on the subsystem providing hook points, a Khelp module may be able to associate per-object data for maintaining relevant state between hook calls.
- pjd's Object Specific Data (OSD) KPI is used to manage the per-object data allocated to Khelp modules. Create a new "OSD_KHELP" OSD type for use by the Khelp framework.
- Bump __FreeBSD_version to 900028 to mark the introduction of the new KPIs.
In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: FreeBSD Foundation Reviewed by: bz, others along the way MFC after: 3 months
|