From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 3 11:30:08 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A16491065672 for ; Mon, 3 Mar 2008 11:30:08 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 371568FC1F for ; Mon, 3 Mar 2008 11:30:08 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JW8rq-0000Ka-C6 for freebsd-ipfw@freebsd.org; Mon, 03 Mar 2008 11:30:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Mar 2008 11:30:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Mar 2008 11:30:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Mon, 3 Mar 2008 11:29:00 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 51 Message-ID: References: <20080302144939.GA23353@tin.it> <20080302151310.GB23353@tin.it> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Paolo Pisati User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 11:30:08 -0000 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]