From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: xt_connlimit 20070625 Date: Thu, 28 Jun 2007 21:33:17 +0200 Message-ID: <46840CFD.5060706@trash.net> References: <467BAF07.6020502@trash.net> <467FA9CE.8000805@trash.net> <46840B9F.7080803@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Netfilter Developer Mailing List To: Jan Engelhardt Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Jan Engelhardt wrote: > On Jun 28 2007 21:27, Patrick McHardy wrote: > >>I though you would store the struct xt_connlimit_conn in the >>ct_extend area. > > > Ah, that was the big hint. Thank you. > I'll just put the pointer to xt_connlimit_data there. Just as easy. > > >>The only reason I can think of why you'd need >>the xt_connlimit_data is for the lock. So you could make the >>lock global (which I think is fine) or add a pointer to the >>data you need. > > > I'd hate to introduce such a lock, because it would make the _whole_ match > "singleprocessor-sticky". Use a rwlock or something lockless if you're worried about that. But that seems like a premature optimization, the time a single match needs should be very small anyway so its unlikely that we'll see contention.