[illumos-gate merge]

commit 2e25d8e1fe9b3743d7dec073fd05a9f95fbca2a7
    12225 normalize complex float names across compilers
commit f4b3fdc1b1ec48bd52b545ef80d866244e76d91b
    12291 python3.8 fails versioning check
commit 94494656088303cd79a8b970e5535468c5f0117d
    12307 Fix markup errors in mtx(3C)
commit c40d33be34d8bd92100aad1cfae8c1aaeee375d6
    12309 errors in section 9e of the manual
commit 0dc3799518631a169651844259f4357ece16ffa6
    12305 typos in dhcp man pages
commit d7ab8532a7a0f65d1c2b7bc3f45072f665860b20
    12236 getmembers_DN doesn't properly handle errors from __ns_ldap_dn2uid
    12240 nss_ldap does not properly look up group members by distinguished name
commit f5f3cbec075f8308da054292c7c7d96373c956ee
    12288 getfacl and setfacl could stand improvement
commit 5642709df07e9b3a809f898f938aac4fc9903255
    12211 loader: build with smatch fixes
commit 8b6e4188cd6fe49ddc2ff1e635b9c1538fbd5d48
    12303 nfs/nfs4_drc.h: No such file or directory
commit d3879c39d2a534146eaf46dc510b80678ea24023
    12181 zvol tests should avoid grep -w
    12281 zvol_swap_003_pos shouldn't use swapadd in cleanup
commit b0daad2a8784078aa662f966577891e83a581d3a
    12287 errors in audio utility man pages
commit dd50e0cc4cbe1474096300fe52e9855769c0d478
    11682 zpool iostat and status improvements
commit 3df9f0641f28754051d5e82c6457527cf4af1258
    12227 libctf incorrectly handles clang anonymous unions
commit 6d9e11ccb59a5d4ea2127e1791163333c4337a08
    12224 ctfconvert conv backend error missing newline
commit b40354493afafb9870e25372645af933e189b24f
    10931 BUILDPY2TOOLS and BUILDPY3TOOLS need to be documented in illumos.sh

	Conflicts:
	usr/src/uts/common/fs/zfs/zio.c
	usr/src/uts/common/fs/zfs/sys/zio.h

1 files changed, 6 insertions, 26 deletions

diff --git a/usr/src/man/man3c/cond_init.3c b/usr/src/man/man3c/cond_init.3c
index f54704de56..d90296e420 100644
--- a/usr/src/man/man3c/cond_init.3c
+++ b/usr/src/man/man3c/cond_init.3c
@@ -44,12 +44,11 @@
 .\" Copyright (c) 2001, The IEEE and The Open Group.  All Rights Reserved.
 .\" Copyright (c) 2007, Sun Microsystems, Inc.  All Rights Reserved.
 .\"
-.TH COND_INIT 3C "Jun 5, 2007"
+.TH COND_INIT 3C "February 15, 2020"
 .SH NAME
 cond_init, cond_wait, cond_timedwait, cond_reltimedwait, cond_signal,
 cond_broadcast, cond_destroy \- condition variables
 .SH SYNOPSIS
-.LP
 .nf
 cc -mt [ \fIflag\fR... ] \fIfile\fR... [ \fIlibrary\fR... ]
 #include <thread.h>
@@ -92,8 +91,6 @@ cc -mt [ \fIflag\fR... ] \fIfile\fR... [ \fIlibrary\fR... ]
 
 .SH DESCRIPTION
 .SS "Initialize"
-.sp
-.LP
 Condition variables and mutexes should be global. Condition variables that are
 allocated in writable memory can synchronize threads among processes if they
 are shared by the cooperating processes (see \fBmmap\fR(2)) and are initialized
@@ -119,7 +116,7 @@ initialization.
 .LP
 The \fBcond_init()\fR function initializes the condition variable pointed to by
 \fIcvp\fR. A condition variable can have several different types of behavior,
-specified by \fItype\fR. No current type uses  \fIarg\fR although a future type
+specified by \fItype\fR. No current type uses \fIarg\fR although a future type
 may specify additional behavior parameters with \fIarg\fR. The \fItype\fR
 argument c take one of the following values:
 .sp
@@ -128,7 +125,7 @@ argument c take one of the following values:
 \fB\fBUSYNC_THREAD\fR\fR
 .ad
 .RS 17n
-The condition variable can synchronize  threads only in this process. This is
+The condition variable can synchronize threads only in this process. This is
 the default.
 .RE
 
@@ -199,8 +196,6 @@ cond_init(&cvp, USYNC_PROCESS, NULL); /* initialize cv with
 .in -2
 
 .SS "Condition Wait"
-.sp
-.LP
 The condition wait interface allows a thread to wait for a condition and
 atomically release the associated mutex that it needs to hold to check the
 condition. The thread waits for another thread to make the condition true and
@@ -211,7 +206,7 @@ The \fBcond_wait()\fR function atomically releases the mutex pointed to by
 \fImp\fR and causes the calling thread to block on the condition variable
 pointed to by \fIcvp\fR. The blocked thread may be awakened by
 \fBcond_signal()\fR, \fBcond_broadcast()\fR, or when interrupted by delivery of
-a  \fBUNIX\fR signal or a \fBfork()\fR.
+a \fBUNIX\fR signal or a \fBfork()\fR.
 .sp
 .LP
 The \fBcond_wait()\fR, \fBcond_timedwait()\fR, and \fBcond_reltimedwait()\fR
@@ -222,8 +217,6 @@ attribute and has been left irrecoverable by the mutex's last owner. The
 functions return the appropriate error value if they fail to internally
 reacquire the mutex.
 .SS "Condition Signaling"
-.sp
-.LP
 A condition signal allows a thread to unblock a single thread waiting on the
 condition variable, whereas a condition broadcast allows a thread to unblock
 all threads waiting on the condition variable.
@@ -248,8 +241,6 @@ associated with the condition variable during their waits. If, however,
 predictable scheduling behavior is required, then that mutex should be locked
 by the thread prior to calling \fBcond_signal()\fR or \fBcond_broadcast()\fR.
 .SS "Destroy"
-.sp
-.LP
 The condition destroy functions destroy any state, but not the space,
 associated with the condition variable.
 .sp
@@ -258,13 +249,9 @@ The \fBcond_destroy()\fR function destroys any state associated with the
 condition variable pointed to by \fIcvp\fR. The space for storing the condition
 variable is not freed.
 .SH RETURN VALUES
-.sp
-.LP
 Upon successful completion, these functions return \fB0\fR. Otherwise, a
 non-zero value is returned to indicate the error.
 .SH ERRORS
-.sp
-.LP
 The \fBcond_timedwait()\fR and \fBcond_reltimedwait()\fR functions will fail
 if:
 .sp
@@ -313,7 +300,7 @@ mutex has not been acquired.
 \fB\fBEOWNERDEAD\fR\fR
 .ad
 .RS 19n
-The last owner of the mutex died while  holding the mutex, possibly leaving the
+The last owner of the mutex died while holding the mutex, possibly leaving the
 state it was protecting inconsistent. The mutex is now owned by the caller.
 .RE
 
@@ -342,11 +329,10 @@ to 1,000,000,000.
 .RE
 
 .SH EXAMPLES
-.LP
 \fBExample 1 \fRUse \fBcond_wait()\fR in a loop to test some condition.
 .sp
 .LP
-The \fBcond_wait()\fR functin is normally used in a loop testing some
+The \fBcond_wait()\fR function is normally used in a loop testing some
 condition, as follows:
 
 .sp
@@ -413,8 +399,6 @@ while (cond == FALSE) {
 .in -2
 
 .SH ATTRIBUTES
-.sp
-.LP
 See \fBattributes\fR(5) for descriptions of the following attributes:
 .sp
 
@@ -429,14 +413,10 @@ MT-Level	MT-Safe
 .TE
 
 .SH SEE ALSO
-.sp
-.LP
 \fBfork\fR(2), \fBmmap\fR(2), \fBsetitimer\fR(2), \fBshmop\fR(2),
 \fBmutex_init\fR(3C), \fBsignal\fR(3C), \fBattributes\fR(5),
 \fBcondition\fR(5), \fBmutex\fR(5), \fBstandards\fR(5)
 .SH NOTES
-.sp
-.LP
 If more than one thread is blocked on a condition variable, the order in which
 threads are unblocked is determined by the scheduling policy. When each thread,
 unblocked as a result of a \fBcond_signal()\fR or \fBcond_broadcast()\fR,