Date: Thu, 02 Jan 2014 17:21:12 -0800 From: Alfred Perlstein <bright@mu.org> To: "Gumpula, Suresh" <Suresh.Gumpula@netapp.com>, Julian Elischer <julian@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Reference count race window Message-ID: <52C61088.3080703@mu.org> In-Reply-To: <D29CB80EBA4DEA4D91181928AAF51538438C0DF8@SACEXCMBX04-PRD.hq.netapp.com> References: <D29CB80EBA4DEA4D91181928AAF51538438C0D8B@SACEXCMBX04-PRD.hq.netapp.com> <52C5ED3E.4020805@mu.org> <52C5F8A3.9000902@freebsd.org> <D29CB80EBA4DEA4D91181928AAF51538438C0DF8@SACEXCMBX04-PRD.hq.netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/2/14, 3:53 PM, Gumpula, Suresh wrote:
>>> Without changing the return-value semantics of refcount_acquire, we
>>> have introduced a panic if we detected a race as below.
>>> static __inline void
>>> refcount_acquire(volatile u_int *count) {
>>> u_int old;
>>>
>>> old = atomic_fetchadd_int(count, 1);
>>> if (old == 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 INVARIANTS )
>
> #4 0xffffffff80331d34 in panic (fmt=0xffffffff805c1e60 "refcount_acquire race condition detected!\n") at ../../../../sys/kern/kern_shutdown.c:1009
> #5 0xffffffff80326662 in refcount_acquire (count=<optimized out>) at ../../../../sys/sys/refcount.h:65
> #6 crhold (cr=<optimized out>) at ../../../../sys/kern/kern_prot.c:1814
> #7 0xffffffff803aa0d9 in socreate (dom=<optimized out>, aso=0xffffff80345c1b00, type=<optimized out>, proto=0, cred=0xffffff0017d7aa00, td=0xffffff000b294410)
> at ../../../../sys/kern/uipc_socket.c:441
> #8 0xffffffff803b2e5c in socket (td=0xffffff000b294410, uap=0xffffff80345c1be0) at ../../../../sys/kern/uipc_syscalls.c:201
> #9 0xffffffff80539ecb in syscall (frame=0xffffff80345c1c80) at ../../../../sys/amd64/amd64/trap.c:1260
>
If it's a non-debug build then how do you know that someone isn't
incorrectly lowering the refcount?
Please try some invariants or at least manually turn on the one KASSERT
I mentioned.
Another trick would be to add a an array of char*+int for the last few
places that decremented, you can use the returned refcount as an index
to that array to track who may be doing the extra frees.
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52C61088.3080703>