cvs commit: src/sys/kern kern_proc.c

[Bosko Milekic]

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