Date: Mon, 3 Jun 2002 22:53:33 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Archie Cobbs <archie@dellroad.org>, Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <200206040553.g545rXH49446@arch20m.dellroad.org> In-Reply-To: <20020603193651.A29296@unixdaemons.com> "from Bosko Milekic at Jun 3, 2002 07:36:51 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. > > I did say "if the refcount is exactly 1" !!!! (which is often the > case in there). Oops, sorry.. right, if the ref count is one there can be no race. > > 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. > > No, the worse case is that it is too low. > > increment: > > read > inc > write > > two increments, unprotected: Yes, you are right.. I was thinking that mbuf's were only free'd in interrupt handlers rather than allocated. If they are also allocated then the double-free race happens. We cannot assume that they aren't so this is indeed a more serious, if rare, bug. Re: the -stable patch. I agree we need a more general MFC/cleanup of some of the mbuf improvements from -current into -stable. If I find time perhaps I'll do that as well, but in a separate patch. For the present time, I'll commit this once 4.6-REL is done. Thanks for your comments. -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?200206040553.g545rXH49446>