Date: Mon, 28 Aug 2000 13:41:16 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: bmilekic@dsuper.net, dwmalone@maths.tcd.ie, freebsd-net@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <200008282041.NAA71818@bubba.whistle.com> In-Reply-To: <200008282046.aa01881@salmon.maths.tcd.ie> "from Ian Dowse at Aug 28, 2000 08:46:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008282041.NAA71818>