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

Reply via email to