Date: Mon, 3 Mar 2008 11:29:00 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-ipfw@freebsd.org Subject: Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? Message-ID: <slrnfsno7r.c8a.vadim_nuclight@hostel.avtf.net> References: <20080302144939.GA23353@tin.it> <20080302151310.GB23353@tin.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnfsno7r.c8a.vadim_nuclight>