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).


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

> 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to