Date: Mon, 28 Aug 2000 14:06:08 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: David Malone <dwmalone@maths.tcd.ie> Cc: Archie Cobbs <archie@whistle.com>, freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <Pine.BSF.4.21.0008281340570.7945-100000@jehovah.technokratis.com> In-Reply-To: <20000827230958.B10714@lanczos.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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. bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0008281340570.7945-100000>