From owner-freebsd-net Tue Dec 12 20:15:18 2000 From owner-freebsd-net@FreeBSD.ORG Tue Dec 12 20:15:16 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id DCFF037B400 for ; Tue, 12 Dec 2000 20:15:15 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5H001JDNTE56@field.videotron.net> for net@freebsd.org; Tue, 12 Dec 2000 23:15:14 -0500 (EST) Date: Tue, 12 Dec 2000 23:16:24 -0500 (EST) From: Bosko Milekic Subject: Re: need mbuf generic free() hook In-reply-to: <20001212042447.E16205@fw.wintelcom.net> To: Alfred Perlstein Cc: net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred, You've brought this up before. This looks familiar to your earlier post(s) regarding how to "abuse m_ext." Mind you, I may be mistaken, but that would be because this isn't being made awfully clear. Earlier you talked about forcing a custom free routine to be called even in the case of mbuf clusters, and we devised a way. Are you suggesting now to have a custom free routine called when your mbuf is freed (i.e. even when it is a non-M_EXT mbuf?) If that's so, I would urge you to re-examine the code because doing something like that would be generally wrong. I say "generally" because I'm always open to exceptions, as you know. So please clarify. On Tue, 12 Dec 2000, Alfred Perlstein wrote: > Ok, so I'm trying to rid FreeBSD of the unp_gc() junk in uipc_usrreq.c > I just realized why I'm leaking file descriptors: > > Only mbufs with external storage can have a 'free' function, the > problem is that for the most part when passing a single fd I'm only > using a single mbuf to pass my data around, my ext_free routine is > probably never called, and on top of that I'm probably corrupting > my mbuf by using it when I shouldn't be. > > This is terrible, what should be a simple free() hook is now my > worst nightmare. A couple of options come to mind: > > a) always have a free hook, the extra if (m->m_freehook != NULL) > check can't be that expensive. > b) a macro to make an mbuf into an mbuf cluster that points to itself, > it should check to see if it has enough room to shuffle the data > and return an error if it can't accomidate both the data and the > expanded mbug header. > > I like 'a' but would be willing to deal with 'b' as we've never > had a need for this, although that would mean copying about the > size of an mbuf in the worst case when a subsystem needs this > facility. > > Suggestions? Comments? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message