From owner-freebsd-net Mon Aug 28 13:42:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 5FC6637B422 for ; Mon, 28 Aug 2000 13:42:11 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7SKfT407522; Mon, 28 Aug 2000 13:41:29 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma007516; Mon, 28 Aug 2000 13:41:21 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id NAA71818; Mon, 28 Aug 2000 13:41:16 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008282041.NAA71818@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: <200008282046.aa01881@salmon.maths.tcd.ie> "from Ian Dowse at Aug 28, 2000 08:46:20 pm" To: Ian Dowse Date: Mon, 28 Aug 2000 13:41:16 -0700 (PDT) Cc: bmilekic@dsuper.net, dwmalone@maths.tcd.ie, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ian Dowse writes: > >3) The flag should be removed in _MEXTFREE only if that first > > MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), > > the new ref_cnt is exactly 1. > > > > I'm pretty sure that this way, the subsystem will take care of the > > read-onlyness itself pretty transparently, so that relevant code can > > simply check for the M_RDONLY bit. (2) is questionable. > > This is good, but the M_RDONLY flag should only be used as an > indication that the underlying ext_buf must never be written to. > Hence the mbuf system should never modify this flag (except of > course to clear it when the mbuf is returned to the free pool). > > Point (3) above would clear the M_RDONLY flag on a sendfile sf_buf > when the reference count becomes 1; this is not the desired effect. > > Another way of looking at the M_RDONLY flag is as an indication > that the underlying ext_buf does _not_ follow cluster semantics; > cluster semantics being defined as 'it is safe to write if the > reference count is exactly 1'. > > However, the idea of caching the value of the expression: > > if (m->m_flags & M_EXT) != 0 && > (MEXT_IS_REF(m) || (m->m_flags & M_RDONLY))) { > /* data is read only */ > } > > in a flag is nice, but if implemented, that would have to be a > separate flag to the above M_RDONLY. So there are really three possibilities: (a) The mbuf data should not be written to under any circumstances. even if it is a cluster mbuf and the reference count becomes 1. (b) The mbuf data may be written to. This implies that if this mbuf is a cluster, then the reference count is 1. (c) The mbuf data may not be written to, BUT if it is a cluster mbuf and the reference count decreases to 1, then it may then be written to. Maybe we should have two flags M_RDONLY and M_WRITABLE, with these four possibilities: (m->m_flags & (M_RDONLY|M_WRITABLE)) == M_RDONLY -> case (a) above (m->m_flags & (M_RDONLY|M_WRITABLE)) == M_WRITABLE -> case (b) above (m->m_flags & (M_RDONLY|M_WRITABLE)) == 0 -> case (c) above (m->m_flags & (M_RDONLY|M_WRITABLE)) == (M_RDONLY|M_WRITABLE) -> Invalid comibination, kernel panic! Invariants: - If the mbuf is not a cluster mbuf then case (b) MUST hold - If case (a) then the mbuf MUST be a cluster mbuf - If case (c) then the mbuf MUST be a cluster mbuf - Never both M_RDONLY and M_WRITABLE set at the same time -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message