Date: Sun, 27 Aug 2000 23:09:58 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <20000827230958.B10714@lanczos.maths.tcd.ie> In-Reply-To: <200008272125.OAA66159@bubba.whistle.com>; from archie@whistle.com on Sun, Aug 27, 2000 at 02:25:55PM -0700 References: <200008272125.OAA66159@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote:
> Each mbuf may be either a normal mbuf or a cluster mbuf (if the
> mbuf flags contains M_EXT). Cluster mbufs point to an entire page
> of memory, and this page of memory may be shared by more than one
> cluster mbuf (see m_copypacket()).
Clusters are currently 2048 bytes in size - which I don't think it
a page on the alpha or the i386. (Not that this is really important).
> his effectively makes the mbuf
> data read-only, because a change to one mbuf affects all of the
> mbufs, not just the one you're working on. There have been (and
> still are) several FreeBSD bugs because of this subtlety.
>
> A test for an mbuf being "read-only" is:
>
> if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) ...
You should also check that it's really a cluster you're looking
at:
if ((m->m_flags & M_EXT) != 0 &&
(MEXT_IS_REF(m) || (m)->m_ext.ext_free != NULL)) {
/* data is read only */
}
(This is why the flag I was talking about in the other mail
would be useful for spotting other cases where the storage
may be writable, even if it's not a cluster).
Cleaning up this sounds like a good plan. It would be worth
getting Ian and Bosko involved if possible.
David.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000827230958.B10714>