Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2000 23:16:24 -0500 (EST)
From:      Bosko Milekic <bmilekic@technokratis.com>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        net@freebsd.org
Subject:   Re: need mbuf generic free() hook
Message-ID:  <Pine.BSF.4.21.0012122312270.23680-100000@jehovah.technokratis.com>
In-Reply-To: <20001212042447.E16205@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help

  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012122312270.23680-100000>