Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Jun 2001 16:07:36 -0400
From:      Bosko Milekic <bmilekic@technokratis.com>
To:        Hajimu UMEMOTO <ume@mahoroba.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/netinet ip_output.c
Message-ID:  <20010612160736.A42834@technokratis.com>
In-Reply-To: <20010613.045416.125862267.ume@mahoroba.org>; from ume@mahoroba.org on Wed, Jun 13, 2001 at 04:54:16AM %2B0900
References:  <200106111838.f5BIcCJ05392@freefall.freebsd.org> <20010611152724.A33314@technokratis.com> <20010613.045416.125862267.ume@mahoroba.org>

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

On Wed, Jun 13, 2001 at 04:54:16AM +0900, Hajimu UMEMOTO wrote:
>>	Furthermore, the other change to sys/sys/mbuf.h and friends had to do
>>with moving a check from m_free() to the more general MFREE() macro. The check
>>itself bloats the macro (increasing the size of the kernel). Normally, I would
>>not object but from the surrounding comments it appears that it is possible
>>to fix the problem _properly_. The comment claims that the check is there
>>because there is still code that doesn't call M_PULLUP() properly. As opposed
>>to bloating the allocation/free code with the bogus check, how difficult would
>>it be to ensure that M_PULLUP() is called properly?
>  
> Since KAME code is writtenin in this form, restoring check from
> MFREE() to m_free() may have risk.

	Oh yeah, I'm fully aware of that. I know that in the present state of
affairs, the check in MFREE is necessary to ensure no problems down the line.
That's why I don't propose moving it back to m_free() (as you noted, that
wouldn't cover all the calls), but I was rather inquiring on how difficult it
would be on completely removing it and fixing the problem where it really is.
	For instance, the comment above the added code is as follows:

	"we do need to check non-first mbuf for m_aux, since some of the
	 existing code does not call M_PREPEND properly.
	 (example: call to bpf_mtap from drivers)"

	My question was how difficult would it be to actually fix the code that
does not call M_PREPEND correctly so that it calls M_PREPEND correctly and so
that we would no longer require the added check in M_FREE? If it's not too
complicated, I'm willing to do the work.
 
> --
> Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
> ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@{,jp.}FreeBSD.org
> http://www.imasy.org/~ume/

	Thanks for the reply, and thank you for promptly clearing up mbstat.

Regards,
-- 
 Bosko Milekic
 bmilekic@technokratis.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010612160736.A42834>