[ note: trimming -current from the CC: list ]
Bosko Milekic writes:
> 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.
Sounds good.
By the way, MEXT_REM_REF() should be defined differently if INVARIANTS
is defined so it KASSERT's the reference count is > 0.
> 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.
Not sure what you mean here.. got an example?
> > Cleaning up this sounds like a good plan. It would be worth
> > getting Ian and Bosko involved if possible.
>
> 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.
Let's keep the discussion on freebsd-net.
Here's a proposed sequence of steps, at least to get started..
1. Implement your 1, 2, 3 above: add the flag and adjust the macros
2. Sprinkle code with const's and KASSERT()'s
3. Wait and see what blows up
4. Continue with my proposed changes
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
