Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Aug 2000 14:06:08 -0400 (EDT)
From:      Bosko Milekic <bmilekic@dsuper.net>
To:        David Malone <dwmalone@maths.tcd.ie>
Cc:        Archie Cobbs <archie@whistle.com>, freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject:   Re: Proposal to clarify mbuf handling rules
Message-ID:  <Pine.BSF.4.21.0008281340570.7945-100000@jehovah.technokratis.com>
In-Reply-To: <20000827230958.B10714@lanczos.maths.tcd.ie>

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

On Sun, 27 Aug 2000, David Malone wrote:

[...]
> (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).

	Thoughts:

1)	The mbuf should be marked read-only explicitly with a single
	additional M_FLAG.

	#define M_RDONLY	0x0x2000

2)	The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is
  equal to or greater than 2. This is unfortunate because an additional
  check would have to be introduced. <INPUT ALTERNATIVE HERE>

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.

  	As for the protocol routines that rely on the mbuf to be "read-only,"
  there may be other side-effects besides for this illegal sharing of
  multiple-reference ext_bufs that could result from the possibility of
  passing these "read-only mbufs" to them. This possibility should be
  investigated.

> Cleaning up this sounds like a good plan. It would be worth
> getting Ian and Bosko involved if possible.
> 
> 	David.

	Sure. If I remember correctly, it was Ian who initially brought this
  up. This is perhaps a 2-month old issue by now -- I, at the time, was
  busy with the referencing stuff as well as the allocator
  re-writing/playing around with (which I will have to continue once the
  direction of SMP is further cleared up - at least for this part of the
  code) - so I did not want to mix apples and oranges. I wonder if Ian has
  some code, though.

  	I have _some_ modifications regarding this already in my local tree but
  have not yet been able to roll over a diff as my monitor is presently
  broken (until the end of this week). In any case, how do you propose
  coordinating the work? This seems like a fairly straightforward change. 
  	I'm ready to put on hold whatever I'm doing right now in order
  to do this, but only if that's okay with you guys - I want to make sure
  that no efforts are being duplicated.

  Regards,
  Bosko.
  bmilekic@technokratis.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?Pine.BSF.4.21.0008281340570.7945-100000>