Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 May 2002 12:54:39 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        Archie Cobbs <archie@dellroad.org>, freebsd-net@FreeBSD.ORG
Subject:   Re: m_split() considered harmful
Message-ID:  <Pine.BSF.4.21.0205311243460.29361-100000@InterJet.elischer.org>
In-Reply-To: <20020531145938.A71219@unixdaemons.com>

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


On Fri, 31 May 2002, Bosko Milekic wrote:

> 
>   I don't remember why the ext_size here was this originally (as you
>   mention, it was imported that way), but it certainly seems bogus and
>   you catching it now is hopefully going to solve some really wierd and
>   difficult-to-debug problems we've had involving mbufs over the years.
> 
It was imported from FreeBSD-1.x by rod.

The size argument was for two reasons.
1/ to allow the M_LEADINGSPACE and M_TRAILINGSPACE calculations
to be done if it was a single reference object.
2/ to allow the free function (in the case of non cluster external
objects) to know what sized object they had in the case that they needed
this information.


I know because I added it, because I needed to do both of these at TRW in
'90-'95 under MACH/BSD and when I moved the code to FreeBSD1.x it cam
along.. there was no M_LEADINGSPACE/M_TRAILINGSPACE macro at that time..
I did it in my code explicitly.

It was not used in standard code because only in my own protocol stack
did I know that the damned object was not shared and writable..
This has improved with time..

Having the size set to 0 however stopped users from hitting
cases where the WRITABILITY of the ext objext has not been correctly 
tracked as it always returns "not enough space" (sometimes -ve).

If we change this we need to audit the WRITABILTY..
e.g. it is not checked in M_TRAILINGSPACE

Julian


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.0205311243460.29361-100000>