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.
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
