Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jun 2004 16:39:37 +0000
From:      Bosko Milekic <bmilekic@FreeBSD.org>
To:        Nate Lawson <nate@root.org>
Cc:        "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: cvs commit: src/sys/kern kern_proc.c
Message-ID:  <20040609163937.GA26656@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

Nate Lawson wrote:
>Bosko wrote:
>>     MEXT_REM_REF(m);  /* Atomic decrement of m->m_ext.ref_cnt */
>>     if (atomic_cmpset_int(m->m_ext.ref_cnt, 0, 1)) {
>>         /* Do the free here... */
>>     }
>>     return;
>
>This may have a race unless the refcount increment path is done correctly:
>
>1:atomic_int--
>1:atomic_cmpset_int == 0 (yes, get ready to free it)
>
>2:atomic_cmpset_int == 0 (yes, object was in process of teardown)
>2:create new object, refcount = 1
>
>This assumes it's ok to have two objects of the same type in existence at
>the same time also (one being torn down while the other is created).  Code
>that accesses an object must make sure it's locked separately.
>
>-Nate

  No, that's not true.  The scenario you describe cannot occur.  The code
  I posted prevents you from racing on teardown, so that you never have
  two threads tearing down the same object.  This is because the first
  one to get to the cmpset will see the refcount to be zero and set it
  up to 1 (atomically), so that the second thread will see it at 1 and
  not do the destruction/free as well.

  There is no race on the reference going back up once it's hit zero
  because that would imply that we (who have sent it to zero) are now
  somehow magically making it gain a reference.

  Think about it, there is no race above.

  -Bosko 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040609163937.GA26656>