From owner-freebsd-net Mon Jun 3 15:33: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 9F78E37B403 for ; Mon, 3 Jun 2002 15:32:57 -0700 (PDT) Received: (qmail 22790 invoked from network); 3 Jun 2002 22:32:32 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 3 Jun 2002 22:32:32 -0000 Message-ID: <3CFBEE4D.80363D65@pipeline.ch> Date: Tue, 04 Jun 2002 00:31:41 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: Race condition with M_EXT ref count? References: <200206031913.g53JD7547163@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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? Yes, this looks dangerous. If you get hit by an interrupt the thing could change under you. Part of this has been discussed a couple of month ago in a thread about 64bit interface counter and atomic updates for (ref)counters in the network stack. Also patches implementing atomic counters for this purpose and performace numbers have been postet within that thread. The best would be to dig that up. I think the subject was along the lines of "64bit counters" or so. There are a couple of other places which look suspicious in similiar regard. There are some suspicius instances of direct rt_refcnt-- decrements. Normally this should be done via RTFREE() so that routes could end up with refcount zero without getting freed. Also sometimes the function rtfree() is called directly instead of the macro RTFREE as in the vast majority of the places. If time permits I'll look into these cases. -- Andre > 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-net" in the body of the message