From owner-freebsd-net Mon Sep 4 18:50:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 1503C37B424 for ; Mon, 4 Sep 2000 18:50:25 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0E00E3M4X16O@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 4 Sep 2000 21:46:13 -0400 (EDT) Date: Mon, 04 Sep 2000 21:49:33 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I wrote: > Okay, I will post *something* by this upcoming Monday (long weekend > here!). > > Later, > > Bosko Milekic > bmilekic@technokratis.com Well, I almost have a presentable diff (I was a little sidetracked this weekend). I noticed a little problem in m_pulldown(), though. If we have a reference count of exactly 1, we're okay because that count will never increase throughout our use of sharedcluster (after we set it). The reason is that in order to increase the reference count, we need to have posession of another mbuf referring to the same ext buf as well, and since the count is exactly 1, we know that won't happen until we let go of our mbuf. So if we set sharedcluster to 0, we're deffinately sure that it's writable. However, we may end up with a ref count greater than 1, and set sharedcluster to 1, which means that it's not writable - but throughout our use of sharedcluster, the ref count may drop to 1 and we may become writable. This will only happen during a free of an mbuf referring to the same ext buf, which may or may not happen from within an interrupt. Thus, there is no practical way to block it from happening. But it's not too big of a deal; it would have been more damaging if the behavior was inverse. Comments, anyone? (I'll give you guys an initial patch soon, so that you can apply it, and make whatever modifications you need to). Cheers, Bosko Milekic bmilekic@technokratis.com On-Line TODO: http://www.technokratis.com/~bmilekic/index.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message