Date: Mon, 04 Sep 2000 21:49:33 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: David Malone <dwmalone@maths.tcd.ie> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal to clarify mbuf handling rules Message-ID: <Pine.BSF.4.21.0009042101390.3711-100000@jehovah.technokratis.com> In-Reply-To: <Pine.BSF.4.21.0009011335340.1476-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009042101390.3711-100000>