Date: Mon, 3 Jun 2002 16:01:29 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Julian Elischer <julian@elischer.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <200206032301.g53N1To48300@arch20m.dellroad.org> In-Reply-To: <20020603184740.A19963@unixdaemons.com> "from Bosko Milekic at Jun 3, 2002 06:47:40 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic writes: > Secondly, this may not be as much of a problem as you may think. > Particularly if you consider the m_split() case, for example. For > example, if you're calling m_split() on an mbuf chain that may refer > to cluster(s) where none of the clusters has a ref. count greater than > 1 -- which is usually the case anyway -- then this is fine; since you > have posession of the chain referring to those clusters, and > presumably the chain isn't sitting in some queue somewhere (if it is, > you'd have to be under the protection of that queue anyway - splimp() > or whatever), then you're the only one who has posession of that The *chain* won't be sitting in a queue, but there may be a different mbuf in a queue somehwere that points to the same cluster. Since mid-level code only increments the ref count, I think the worst that can happen is the ref count is incorrectly too high, which could only cause a memory leak rather than a crash. There's not way for the ref count to be too low, or for the cluster to be free'd twice, because all decrements are protected by splimp(). However, once you start adding in custom code then we may not be so lucky.. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com 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?200206032301.g53N1To48300>