Date: Wed, 20 Oct 2004 01:12:24 +0200 From: Andre Oppermann <andre@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netinet ip_divert.c Message-ID: <41759F58.F8E5D82F@freebsd.org> References: <Pine.NEB.3.96L.1041019185325.81058N-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Wed, 20 Oct 2004, Andre Oppermann wrote: > > > Robert Watson wrote: > > > > > > On Wed, 20 Oct 2004, Andre Oppermann wrote: > > > > > > > Hmm... I'll take a look at those attempts and see what I can come up > > > > with to get some general solution for the protocol cases. The approach > > > > of callout_drain() looks promising though. > > > > > > BTW, it looks like the divert pcb zone uses UMA_ZONE_NOFREE so that the > > > memory is type-stable (presumably in particular for the sysctl), so all > > > memory allocated by the divert module for pcbs is likely leaked on unload. > > > I'm beginning to think we should just block unload for divert and solve > > > the unload problem another day for another protocol... > > > > It is indeed an oversight by me not to uma_zdestroy() the zone on > > unload. The sysctl handler uses normal malloc. > > If it's like other instances of type-stable storage, it's so that weak > consistency can be used by the monitoring sysctl in order to avoid > allocating lots of memory and/or suspending operation while monitoring > takes place. Other instances of type-stable storage in the socket code > and network stack rely on the "chain'o'pcbs" list pointers not being > cleared on allocation and free. Sigh... What a mess... In the IPDIVERT case the sysctl can be protected with a separate (non-adaptive) mutex. We only unload if there are no open sockets, the protocol is unloaded so there should be no cases where weak list pointers are used. I am out of the office tomorrow doing consulting work. I may have time to check into this discussion again tomorrow evening or otherwise on Thursday. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41759F58.F8E5D82F>