From owner-freebsd-net Mon Aug 28 12: 5:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id E3B8837B422; Mon, 28 Aug 2000 12:05:09 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7SJ4N906391; Mon, 28 Aug 2000 12:04:23 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma006386; Mon, 28 Aug 2000 12:04:12 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA70786; Mon, 28 Aug 2000 12:04:06 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008281904.MAA70786@bubba.whistle.com> Subject: Re: Proposal to clarify mbuf handling rules In-Reply-To: "from Bosko Milekic at Aug 28, 2000 02:06:08 pm" To: Bosko Milekic Date: Mon, 28 Aug 2000 12:04:06 -0700 (PDT) Cc: dwmalone@maths.tcd.ie, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ 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. > > 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 majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message