From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 3 02:38:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39A84F63; Fri, 3 Jan 2014 02:38:25 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17C1C1C9A; Fri, 3 Jan 2014 02:38:24 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,595,1384329600"; d="scan'208";a="134232804" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 02 Jan 2014 18:38:19 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.58]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 2 Jan 2014 18:38:19 -0800 From: "Gumpula, Suresh" To: Alfred Perlstein , Julian Elischer , "freebsd-hackers@freebsd.org" Subject: RE: Reference count race window Thread-Topic: Reference count race window Thread-Index: AQHPCA0ePlCdkUTb2Eq8swVe1xATjJpynbOA//98gUCAAJ/7AP//hPzA Date: Fri, 3 Jan 2014 02:38:18 +0000 Message-ID: References: <52C5ED3E.4020805@mu.org> <52C5F8A3.9000902@freebsd.org> <52C61088.3080703@mu.org> In-Reply-To: <52C61088.3080703@mu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 02:38:25 -0000 Hi Alfred, I agree that there could have been an extra/invalid crfree() which d= ecremented the count and looks valid crhold(acquire) from socket code p= anic'ed in my case. As per your suggestion if we=20 replace the assert with if condition in release, we will end up panicing= when the actual crfree() happens. But we may not be knowing who crfree'= ed() in the first and invalid place. Am I correct? I will try your sugge= stion. Can you please bit more explain your array trick ? Thanks Suresh -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Alfred Perlstein Sent: Thursday, January 02, 2014 8:21 PM To: Gumpula, Suresh; Julian Elischer; freebsd-hackers@freebsd.org Subject: Re: Reference count race window On 1/2/14, 3:53 PM, Gumpula, Suresh wrote: >>> Without changing the return-value semantics of refcount_acquire, we=20 >>> have introduced a panic if we detected a race as below. >>> static __inline void >>> refcount_acquire(volatile u_int *count) { >>> u_int old; >>> >>> old =3D atomic_fetchadd_int(count, 1); >>> if (old =3D=3D 0) { >>> panic("refcount_acquire race condition detected!\n"); >>> } >>>>>> so what is the stacktrace of the panic? > It's from the socket code calling crhold. It's a non debug build( NO IN= VARIANTS ) > > #4 0xffffffff80331d34 in panic (fmt=3D0xffffffff805c1e60=20 > "refcount_acquire race condition detected!\n") at=20 > ../../../../sys/kern/kern_shutdown.c:1009 > #5 0xffffffff80326662 in refcount_acquire (count=3D) at=20 > ../../../../sys/sys/refcount.h:65 > #6 crhold (cr=3D) at=20 > ../../../../sys/kern/kern_prot.c:1814 > #7 0xffffffff803aa0d9 in socreate (dom=3D,=20 > aso=3D0xffffff80345c1b00, type=3D, proto=3D0,=20 > cred=3D0xffffff0017d7aa00, td=3D0xffffff000b294410) at=20 > ../../../../sys/kern/uipc_socket.c:441 > #8 0xffffffff803b2e5c in socket (td=3D0xffffff000b294410,=20 > uap=3D0xffffff80345c1be0) at ../../../../sys/kern/uipc_syscalls.c:201 > #9 0xffffffff80539ecb in syscall (frame=3D0xffffff80345c1c80) at=20 > ../../../../sys/amd64/amd64/trap.c:1260 > If it's a non-debug build then how do you know that someone isn't incorrect= ly lowering the refcount? Please try some invariants or at least manually turn on the one KASSERT I m= entioned. Another trick would be to add a an array of char*+int for the last few plac= es that decremented, you can use the returned refcount as an index to that = array to track who may be doing the extra frees. -Alfred _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/l= istinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"