freebsd-skq

Go to file

Andriy Gapon 0a682531f4 3746 ZRLs are racy

illumos/illumos-gate@260af64db7
260af64db7

https://www.illumos.org/issues/3746
  From the original change log:
  It was possible for a reference to be added even with the lock held, and
  for references added just after a lock release to be lost.
  This bug was also independently found and reported in wesunsolve.net
  issues 6985013 6995524.
  In zrl_add(), always use an atomic operation to update the refcount.
  The mutex in the ZRL only guarantees that wakeups occur for waiters on the
  lock. It offers no protection against concurrent updates of the refcount.
  The only refcount transition that is safe to perform without an atomic
  operation is from ZRL_LOCKED back to 0, since this can only be performed
  by the thread which has the ZRL locked.

Authored by: Will Andrews <will@freebsd.org>
Reviewed by: Boris Protopopov <bprotopopov@hotmail.com>
Reviewed by: Pavel Zakharov <pavel.zakha@gmail.com>
Reviewed by: Yuri Pankov <yuri.pankov@gmail.com>
Reviewed by: Justin T. Gibbs <gibbs@scsiguy.com>
Approved by: Matt Ahrens <mahrens@delphix.com>
Author: Youzhong Yang <yyang@mathworks.com>

2016-10-27 07:11:31 +00:00

cmd

7297 clear() on llquantize aggregation causes dtrace to exit

2016-08-26 20:51:09 +00:00

common

6447 handful of nvpair cleanups

2016-07-12 12:05:58 +00:00

head

5066 remove support for non-ANSI compilation

2014-08-20 06:29:42 +00:00

lib

7297 clear() on llquantize aggregation causes dtrace to exit