From owner-freebsd-current  Sun Aug 27 15:10:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP
	id 56BBF37B424; Sun, 27 Aug 2000 15:09:59 -0700 (PDT)
Received: from lanczos.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa16803@salmon>; 27 Aug 2000 23:09:58 +0100 (BST)
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>
References: <200008272125.OAA66159@bubba.whistle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200008272125.OAA66159@bubba.whistle.com>; from archie@whistle.com on Sun, Aug 27, 2000 at 02:25:55PM -0700
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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