Re: ipfw initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?
On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote: The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a large range, so if the existing code does not have races, you can safely move the non-leaf modules (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) without breaking anything. fine, i did this. is it MFCable? bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Current problem reports assigned to freebsd-ipfw@FreeBSD.org
Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores recv/xmit/via any (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem 15 problems total. Non-critical problems S Tracker Resp. Description a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] ipfw fwd sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] [request] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields 27 problems total. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?
Hi Paolo Pisati!
On Sun, 2 Mar 2008 16:13:10 +0100; Paolo Pisati wrote about 'Re: ipfw
initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?':
i just found out that depending on a KLD doesn't imply any
initialization order, thus depending on a lock initialized in the ipfw
init path is _really_ a bad idea from another KLD init path (see
ip_fw_nat.c::ipfw_nat_init()).
A fix would be to move ipfw init priority from SI_ORDER_ANY to
SI_ORDER_MIDDLE, but i guess there are side effects that i'm
unaware in this modification...
On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how
to build stuff that relies on it without opening race conditions:
see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and
rule configuration paths.
as the problem arises only during ip_fw_nat initialization, another
viable solution would be to fix ipfw_nat_init() this way:
static void
ipfw_nat_init(void)
{
-IPFW_WLOCK(layer3_chain);
/* init ipfw hooks */
-ipfw_nat_ptr = ipfw_nat;
ipfw_nat_cfg_ptr = ipfw_nat_cfg;
ipfw_nat_del_ptr = ipfw_nat_del;
ipfw_nat_get_cfg_ptr = ipfw_nat_get_cfg;
ipfw_nat_get_log_ptr = ipfw_nat_get_log;
-IPFW_WUNLOCK(layer3_chain);
+ ipfw_nat_ptr = ipfw_nat;
ifaddr_event_tag = EVENTHANDLER_REGISTER(ifaddr_event,
ifaddr_change,
NULL, EVENTHANDLER_PRI_ANY);
}
avoid grabbing the lock at all during init, and exploit orders of
hooks initialization: as the presence of ipfw_nat in ipfw is checked
via ipfw_nat_ptr, i can narrow/close the race window initializing
ipfw_nat_ptr at the end of the function, but can i trust the order of
variables assignment? i guess no without some sort of memory barriers,
and are memory barriers available in all archs? and are memory
barriers enough?
Oh, just another pitfall of non-clean ipfw/ipfw nat modules separation and
layer3_chain. I knew that there are must be another ones :-)
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?
On Mon, Mar 03, 2008 at 11:17:19AM +0100, Paolo Pisati wrote: On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote: The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a large range, so if the existing code does not have races, you can safely move the non-leaf modules (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) without breaking anything. fine, i did this. is it MFCable? i think so, the SI_ORDER_* definitions are the same at least down to RELENG_6, which is the lowest release we probably care about. cheers luigi ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
