Date: Mon, 03 Jun 2002 15:43:01 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Archie Cobbs <archie@dellroad.org>, freebsd-net@freebsd.org, smp@freebsd.org Subject: Re: Race condition with M_EXT ref count? Message-ID: <3CFBF0F5.21A7EC1B@mindspring.com> References: <Pine.BSF.4.21.0206031225070.43219-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > this is YET ANOTHER case for the Atomic reference counting ABI that > jhb has been talking about... No, they're not. They occur on m_copym, m_copypacket, and m_split. In practice, these are called seperately in the down and up path, and this isn't a problem (in the up path, SPLNET runs at the call to splx(), and in the down-path, the objects that are the target of the operations are/should_be locked). This sounds like a Netgraph related problem associated with the use of a kernel thread. All three of these operations can result in an allocation, and the allocation requires that the operation that calss it set splimp (comments in the same file). If this is a threaded case (e.g. -current, not 4.5/4.6 or earlier), then you would probably be saved by some of the work that Jeffrey Hsu and John Mini have done recently. For 4.5 and 4.6, it really should not be a problem (I think). -- Terry > > On Mon, 3 Jun 2002, Archie Cobbs wrote: > > > This is a question about M_EXT mbuf reference counts in FreeBSD-stable. > > > > There are several instances in kern/uipc_mbuf.c that add a reference > > to an M_EXT mbuf by either incrementing the entry in the mclrefcnt[] > > array or invoking the "custom" ext_ref routine. > > > > However, it seems that these instances are all broken because they > > don't wrap these operations within splimp()... > > > > Isn't the following C statement *not* atomic? > > > > mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > > > > And isn't access to mclrefcnt[] supposed to be protected by splimp()? > > Note: MCLFREE() *does* set splimp() before decrementing M_EXT ref counts. > > > > Therefore, isn't there a race condition wrt. the M_EXT reference counts? > > > > The functions which fail to set splimp() before adding a reference are: > > > > m_copym() > > m_copypacket() > > m_split() > > > > Thanks for any comments/clarification on this subject.. > > > > -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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFBF0F5.21A7EC1B>