Reference count race window

Alfred Perlstein bright at mu.org
Fri Jan 3 01:21:18 UTC 2014


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



More information about the freebsd-hackers mailing list