ipfw cached ucred patch

Andre Oppermann andre at freebsd.org
Wed Jun 2 14:23:08 PDT 2004


Christian S.J. Peron wrote:
> On  2 Jun 2004 Andre Oppermann wrote:
> 
>>Christian S.J. Peron wrote:
>>
>>>All,
>>>
>>>Currently, when you have any rules which contain UID/GID
>>>constraints, ipfw will lock the pcb hash and do a lookup
>>>to find the pcb associated with that packet -- 
>>>One for each constraint.
>>>
>>>I have written a patch in attempt to minimize the impact
>>>of PCB related lookups for these type of firewall rules.
>>>
>>>This patch will have the following effects on firewalls which
>>>contain UID/GID constraints:
>>>
>>>o Greatly reduce the locking contention associated
>>>  with PCB lookups.
>>>
>>>o Increase the performance of firewall in general by making
>>>  PCB lookups O(1) rather than O(n) (where n represents
>>>  number of UID/GID constraints in the ruleset)
>>>
>>>It would be greatly appriciated if people who are running ipfw
>>>rules sets containing UID/GID constraints tested this patch
>>>and reported any success or failures.
>>>
>>>The patch can be downloaded from:
>>>
>>>http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch
>>
>>You can optimize it even further by directly copying the uid/gid
>>from the ucred while you hold the INP_LOCK.  There is no need to
>>hold on to the entire ucred.  It should be sufficient to do the
>>ucred lookup only once per packet in the ipfw code.  If you don't
>>find an INPCB for the packet you'll do a negative lookup for every
>>uid/gid rule.
> 
> I thought about this to, however in order to implement GID contraints
> properly, we need to use groupmember(9) which requires the
> entire cr_groups[16] located in the ucred. I thought it was more
> elegant and cheaper to avoid the memcpy(sizeof(gid_t) * NGROUPS)
> and stick with the mutex.

I see.  Hmmm...  Actually I'm only concerned that someone later
misses a crfree() call and starts to leak ucred structures.  ipfw
is not the first place you are going to look for it.  The more you
can keep together in one place the better it is.  This kind
of error has already happend once with the initial implementation
of verrevpath in ifpw.  The fuction did not correctly do the ref-
counting leading to a hefty rtentry leak.

-- 
Andre



More information about the freebsd-ipfw mailing list