[illumos-gate merge]

commit 94ddd0900a8838f62bba15e270649a42f4ef9f81
    8909 8585 can cause a use-after-free kernel panic
commit a8feb7338362ea067733d5dd40f4365dd99c4d31
    8910 man pages should refer to our Modular Debugger Guide

13 files changed, 259 insertions, 146 deletions

diff --git a/usr/src/man/man1/adb.1 b/usr/src/man/man1/adb.1
index 49c687ba21..08e5f05a0c 100644
--- a/usr/src/man/man1/adb.1
+++ b/usr/src/man/man1/adb.1
@@ -3,7 +3,7 @@
 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH ADB 1 "Nov 29, 2005"
+.TH ADB 1 "Dec 9, 2017"
 .SH NAME
 adb \- general-purpose debugger
 .SH SYNOPSIS
@@ -13,7 +13,6 @@ adb \- general-purpose debugger
 .fi
 
 .SH DESCRIPTION
-.sp
 .LP
 The \fBadb\fR utility is an interactive, general-purpose debugger. It can be
 used to examine files and provides a controlled environment for the execution
@@ -25,14 +24,16 @@ The \fBadb\fR utility is now implemented as a link to the \fBmdb\fR(1) utility.
 processes as well as the live operating system or operating system crash dumps.
 The new \fBmdb\fR(1) utility provides complete backwards compatibility with the
 existing syntax and features of \fBadb\fR, including support for processing
-\fBadb\fR macro files. The \fISolaris Modular Debugger Guide\fR and
-\fBmdb\fR(1) man page describes the features of \fBmdb\fR, including its
+\fBadb\fR macro files. The \fIModular Debugger Guide\fR and
+\fBmdb\fR(1) man page describe the features of \fBmdb\fR, including its
 \fBadb\fR compatibility mode. This mode will be activated by default when the
 \fBadb\fR link is executed.
 .SH SEE ALSO
-.sp
 .LP
 \fBmdb\fR(1), \fBattributes\fR(5)
 .sp
 .LP
-\fISolaris Modular Debugger Guide\fR
+\fIModular Debugger Guide\fR:
+.sp
+.LP
+https://illumos.org/books/mdb/
diff --git a/usr/src/man/man1/kmdb.1 b/usr/src/man/man1/kmdb.1
index c688045b59..29d69c1d46 100644
--- a/usr/src/man/man1/kmdb.1
+++ b/usr/src/man/man1/kmdb.1
@@ -3,12 +3,11 @@
 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH KMDB 1 "May 3, 2007"
+.TH KMDB 1 "Dec 9, 2017"
 .SH NAME
 kmdb \- in situ kernel debugger
 .SH SYNOPSIS
 .SS "Boot-time Loading"
-.sp
 .LP
 SPARC
 .LP
@@ -36,7 +35,6 @@ x86
 .fi
 
 .SH DESCRIPTION
-.sp
 .LP
 \fBkmdb\fR is an interactive kernel debugger which implements the user
 interface and functionality of \fBmdb\fR(1) in a live kernel context.
@@ -49,9 +47,8 @@ This man page describes the features and functionality that are unique to
 \fBkmdb\fR or different in \fBkmdb\fR as compared to \fBmdb\fR(1). For more
 information on \fBmdb\fR(1) or further details on the features and
 functionality implemented by \fBkmdb\fR, see the \fBmdb\fR(1) man page and the
-\fISolaris Modular Debugger Guide\fR.
+\fIModular Debugger Guide\fR.
 .SS "Loading and Unloading"
-.sp
 .ne 2
 .na
 \fBBoot-time Loading\fR
@@ -107,7 +104,6 @@ the value of the \fBTERM\fR environment variable unless overridden by the
 .RE
 
 .SS "Debugger Entry"
-.sp
 .LP
 Debugger entry can be requested explicitly or implicitly. Implicit entry,
 encountered when breakpoints or other execution control features are used, is
@@ -147,7 +143,6 @@ set nopanicdebug = 1
 This can be useful if you want to keep \fBkmdb\fR loaded, but always want a
 panic to trigger a crash dump without entering the debugger.
 .SS "Execution Control"
-.sp
 .LP
 For the most part, the execution control facilities provided by \fBkmdb\fR for
 the kernel mirror those provided by the \fBmdb\fR(1) process target.
@@ -161,7 +156,6 @@ size, and type of watchpoints allowed. The \fB::wp\fR command does not allow a
 watchpoint to be created if it is incompatible with the watchpoints supported
 by the hardware.
 .SS "Debugger modules (dmods)"
-.sp
 .LP
 As with \fBmdb\fR(1), \fBkmdb\fR is installed with a number of
 subsystem-specific debugger modules, or dmods. The dmods are loaded and
@@ -176,7 +170,6 @@ is complete, the system is stopped and the debugger is automatically
 re-entered. For a dmod load, processing is completed when the load of a
 requested dmod succeeds or fails. Status messages are provided in either case.
 .SS "Processor-specific functionality"
-.sp
 .LP
 Some functionality is specific to an individual processor type. An example of
 such functionality is the branch tracing provided by various x86 processors.
@@ -188,14 +181,12 @@ Even though the debugger might provide support for a given processor type, the
 support is not exposed until the kernel has progressed to the point at which
 processor identification has completed.
 .SS "Kernel Macros"
-.sp
 .LP
 The debugger provides access to a set of macros that are precompiled into the
 debugger. Only the precompiled macros are available . Unlike with \fBmdb\fR(1),
 the \fB$< dcmd\fR may not be used to load macros from arbitrary locations. Use
 the \fB$M\fR command to list the available macros.
 .SS "Built-in dcmds"
-.sp
 .LP
 This section lists dcmds that are unique to \fBkmdb\fR or those with behavior
 that differs in \fBkmdb\fR as compared to \fBmdb\fR(1).
@@ -438,7 +429,6 @@ callback string. If the string contains meta-characters, it must be quoted.
 .RE
 
 .SH ATTRIBUTES
-.sp
 .LP
 See \fBattributes\fR(5) for descriptions of the following attributes:
 .sp
@@ -454,20 +444,17 @@ Interface Stability	Evolving
 .TE
 
 .SH SEE ALSO
-.sp
 .LP
-\fBmdb\fR(1), \fBboot\fR(1M), \fBdumpadm\fR(1M), \fBkernel\fR(1M),
+\fBkbd\fR(1), \fBmdb\fR(1), \fBboot\fR(1M), \fBdumpadm\fR(1M), \fBkernel\fR(1M),
 \fBsystem\fR(4), \fBattributes\fR(5)
 .sp
 .LP
-\fISolaris Modular Debugger Guide\fR
-.SS "SPARC Only"
+\fIModular Debugger Guide\fR:
 .sp
 .LP
-\fBkbd\fR(1)
+https://illumos.org/books/mdb/
 .SH NOTES
 .SS "Limitations on Memory Available to the Debugger"
-.sp
 .LP
 The memory region available to the debugger is allocated when the debugger is
 loaded, and is fixed at that point. If dcmds attempt to allocate more memory
@@ -476,7 +463,6 @@ attempt to recover gracefully from an out-of-memory situation, but may be
 unable to, and may be forced to terminate the system. This constraint is
 especially acute on 32-bit x86 systems.
 .SS "Performance Impact"
-.sp
 .LP
 System performance will be negatively impacted by the loading of \fBkmdb\fR, as
 the debugger will consume kernel memory and other limited system resources.
diff --git a/usr/src/man/man1/mdb.1 b/usr/src/man/man1/mdb.1
index a9a7ff4e31..c388fadfcd 100644
--- a/usr/src/man/man1/mdb.1
+++ b/usr/src/man/man1/mdb.1
@@ -4,7 +4,7 @@
 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH MDB 1 "May 13, 2017"
+.TH MDB 1 "Dec 9, 2017"
 .SH NAME
 mdb \- modular debugger
 .SH SYNOPSIS
@@ -21,7 +21,7 @@ mdb \- modular debugger
 The \fBmdb\fR utility is an extensible utility for low-level debugging and
 editing of the live operating system, operating system crash dumps, user
 processes, user process core dumps, and object files. For a more detailed
-description of \fBmdb\fR features, refer to the manual, \fISolaris Modular
+description of \fBmdb\fR features, refer to the \fIModular
 Debugger Guide\fR.
 .sp
 .LP
@@ -64,7 +64,7 @@ executes the corresponding dcmds. Each dcmd can also accept a list of string or
 numerical arguments, as shown in the syntax description below. \fBmdb\fR
 contains a set of built-in dcmds, described below, that are always available.
 You can also extend the capabilities of \fBmdb\fR itself by writing your own
-dcmds, as described in the \fISolaris Modular Debugger Guide\fR.
+dcmds, as described in the \fIModular Debugger Guide\fR.
 .sp
 .LP
 A \fIwalker\fR is a set of routines that describe how to walk, or iterate,
@@ -79,16 +79,16 @@ A debugger module, or \fIdmod\fR (pronounced dee-mod), is a dynamically loaded
 library containing a set of dcmds and walkers. During initialization, \fBmdb\fR
 attempts to load dmods corresponding to the load objects present in the target.
 You can subsequently load or unload dmods at any time while running \fBmdb\fR.
-\fBmdb\fR ships with a set of standard dmods for debugging the Solaris kernel.
-The \fISolaris Modular Debugger Guide\fR contains more information on
+\fBmdb\fR ships with a set of standard dmods for debugging the kernel.
+The \fIModular Debugger Guide\fR contains more information on
 developing your own debugger modules.
 .sp
 .LP
 A \fImacro file\fR is a text file containing a set of commands to execute.
 Macro files are typically used to automate the process of displaying a simple
 data structure. \fBmdb\fR provides complete backward compatibility for the
-execution of macro files written for \fBadb\fR(1), and the Solaris installation
-includes a set of macro files for debugging the Solaris kernel that can be used
+execution of macro files written for \fBadb\fR(1), and illumos
+includes a set of macro files for debugging the kernel that can be used
 with either tool.
 .SS "Syntax"
 .LP
@@ -726,7 +726,7 @@ in the target's virtual address space. A target can support multiple symbol
 tables including, but not limited to, a primary executable symbol table, a
 primary dynamic symbol table, a run-time link-editor symbol table, and standard
 and dynamic symbol tables for each of a number of load objects (such as shared
-libraries in a user process, or kernel modules in the Solaris kernel). The
+libraries in a user process, or kernel modules in the kernel). The
 target typically searches the primary executable's symbol tables first, and
 then one or more of the other symbol tables. Notice that \fBELF\fR symbol
 tables only contain entries for external, global, and static symbols; automatic
@@ -1551,9 +1551,9 @@ to the corresponding named variable.
 .sp
 .LP
 The \fBmdb\fR kernel target exports the virtual address of the corresponding
-internal thread structure as the identifier for a given thread. The \fISolaris
-Modular Debugger Guide\fR provides more information on debugging support for
-threads in the Solaris kernel. The \fBmdb\fR process target provides proper
+internal thread structure as the identifier for a given thread. The \fIModular
+Debugger Guide\fR provides more information on debugging support for
+threads in the kernel. The \fBmdb\fR process target provides proper
 support for examination of multi-threaded user processes that use the native
 \fBlwp_*\fR interfaces, \fB/usr/lib/libthread.so\fR or
 \fB/usr/lib/lwp/libthread.so\fR. When debugging a live user process, \fBmdb\fR
@@ -3663,7 +3663,7 @@ List the external data buffers exported by the current target. External data
 buffers represent information associated with the target that can not be
 accessed through standard target facilities (that is, an address space, symbol
 table, or register set). These buffers can be consumed by dcmds; for more
-information, refer to the \fISolaris Modular Debugger Guide\fR.
+information, refer to the \fIModular Debugger Guide\fR.
 .RE
 
 .sp
@@ -4421,7 +4421,7 @@ Interface Stability	Evolving
 
 .SH SEE ALSO
 .LP
-\fBadb\fR(1), \fBcmdtool\fR(1), \fBgcore\fR(1), \fBproc\fR(1), \fBpgrep\fR(1),
+\fBadb\fR(1), \fBgcore\fR(1), \fBproc\fR(1), \fBpgrep\fR(1),
 \fBps\fR(1), \fBstty\fR(1), \fBtruss\fR(1), \fBuname\fR(1), \fBcoreadm\fR(1M),
 \fBdumpadm\fR(1M), \fBlargefile\fR(5), \fBsavecore\fR(1M), \fBexec\fR(2),
 \fBfork\fR(2), \fB_lwp_self\fR(2), \fBpipe\fR(2), \fBvfork\fR(2),
@@ -4434,7 +4434,10 @@ Interface Stability	Evolving
 \fILinker and Libraries Guide\fR
 .sp
 .LP
-\fISolaris Modular Debugger Guide\fR
+\fIModular Debugger Guide\fR:
+.sp
+.LP
+https://illumos.org/books/mdb/
 .SH WARNINGS
 .SS "Use of the Error Recovery Mechanism"
 .LP
@@ -4466,8 +4469,8 @@ Solaris 9, text sections and read-only data are included in core files by
 default. Users can configure their processes to exclude that information from
 core files using \fBcoreadm\fR(1M). Thus, the information presented by
 \fBmdb\fR for those core files can not match the data that was present at the
-time the process dumped core. Core files from Solaris x86 systems can not be
-examined on Solaris SPARC systems, and vice-versa.
+time the process dumped core. Core files from x86 systems can not be
+examined on SPARC systems, and vice-versa.
 .SS "Limitations on Examining Crash Dump Files"
 .LP
 Crash dumps from Solaris 7 and earlier releases can only be examined with the
@@ -4475,8 +4478,8 @@ aid of the libkvm from the corresponding operating system release. If a crash
 dump from one operating system release is examined using the dmods from a
 different operating system release, changes in the kernel implementation can
 prevent some dcmds or walkers from working properly. \fBmdb\fR issues a warning
-message if it detects this condition. Crash dumps from Solaris x86 systems can
-not be examined on Solaris SPARC systems, and vice-versa.
+message if it detects this condition. Crash dumps from x86 systems can
+not be examined on SPARC systems, and vice-versa.
 .SS "Relationship Between 32-bit and 64-bit Debugger"
 .LP
 \fBmdb\fR provides support for debugging both 32-bit and 64-bit programs. Once
@@ -4563,10 +4566,10 @@ left stopped and abandoned using the \fB::release\fR \fB-a\fR option.
 The \fB::list\fR, \fB::offsetof\fR, \fB::print\fR, and \fB::sizeof\fR dcmds
 require that one or more load objects contain compressed symbolic debugging
 information suitable for use with \fBmdb\fR. This information is currently only
-available for certain Solaris kernel modules.
+available for certain kernel modules.
 .SS "Developer Information"
 .LP
-The \fISolaris Modular Debugger Guide\fR provides a more detailed description
+The \fIModular Debugger Guide\fR provides a more detailed description
 of \fBmdb\fR features, as well as information for debugger module developers.
 .sp
 .LP
diff --git a/usr/src/man/man1m/kadb.1m b/usr/src/man/man1m/kadb.1m
index eb60061636..25a2089f0e 100644
--- a/usr/src/man/man1m/kadb.1m
+++ b/usr/src/man/man1m/kadb.1m
@@ -3,7 +3,7 @@
 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH KADB 1M "Jul 2, 2004"
+.TH KADB 1M "Dec 9, 2017"
 .SH NAME
 kadb \- a kernel debugger
 .SH SYNOPSIS
@@ -20,7 +20,6 @@ kadb \- a kernel debugger
 .fi
 
 .SH DESCRIPTION
-.sp
 .LP
 \fBkadb\fR, an interactive kernel debugger, has been replaced by \fBkmdb\fR(1).
 For backwards compatibility, the methods used to load \fBkadb\fR will be
@@ -36,10 +35,9 @@ differences between \fBmdb\fR and \fBkmdb\fR. This man page describes the major
 changes and incompatibilities between \fBkadb\fR and \fBkmdb\fR.
 .sp
 .LP
-Consult the \fISolaris Modular Debugger Guide\fR for a detailed description of
+Consult the \fIModular Debugger Guide\fR for a detailed description of
 both \fBmdb\fR and \fBkmdb\fR.
 .SS "Major changes"
-.sp
 .LP
 This section briefly lists the major differences between \fBkadb\fR and
 \fBkmdb\fR. It is not intended to be exhaustive.
@@ -72,13 +70,12 @@ been changed.
 .RE
 
 .SS "Significant Incompatibilities"
-.sp
 .LP
 This section lists the significant features that have changed incompatibly
 between \fBkadb\fR and \fBkmdb\fR(1). It is not intended to be exhaustive. All
 \fBkmdb\fR(1) commands referenced here are fully described in the \fBkmdb\fR(1)
-man page. A description as well as examples can be found in the \fISolaris
-Modular Debugger Guide\fR.
+man page. A description as well as examples can be found in the \fIModular
+Debugger Guide\fR.
 .sp
 .ne 2
 .na
@@ -117,9 +114,11 @@ port sizes supported by \fBkadb\fR.
 .RE
 
 .SH SEE ALSO
-.sp
 .LP
 \fBadb\fR(1), \fBmdb\fR(1), \fBkmdb\fR(1), \fBattributes\fR(5)
 .sp
 .LP
-\fISolaris Modular Debugger Guide\fR
+\fIModular Debugger Guide\fR:
+.sp
+.LP
+https://illumos.org/books/mdb/
diff --git a/usr/src/man/man3malloc/umem_alloc.3malloc b/usr/src/man/man3malloc/umem_alloc.3malloc
index d8680ca083..4ef98da14f 100644
--- a/usr/src/man/man3malloc/umem_alloc.3malloc
+++ b/usr/src/man/man3malloc/umem_alloc.3malloc
@@ -4,7 +4,7 @@
 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH UMEM_ALLOC 3MALLOC "Mar 24, 2008"
+.TH UMEM_ALLOC 3MALLOC "Dec 9, 2017"
 .SH NAME
 umem_alloc, umem_zalloc, umem_free, umem_nofail_callback \- fast, scalable
 memory allocation
@@ -63,7 +63,6 @@ cc [ \fIflag \&.\|.\|.\fR ] \fIfile\fR\&.\|.\|. \fB-lumem\fR [ \fIlibrary \&.\|.
 .fi
 
 .SH DESCRIPTION
-.sp
 .LP
 The \fBumem_alloc()\fR function returns a pointer to a block of \fIsize\fR
 bytes suitably aligned for any variable type. The initial contents of memory
@@ -109,8 +108,8 @@ callback with \fBUMEM_CALLBACK_EXIT\fR(\fIstatus\fR), one will call
 .ie t \(bu
 .el o
 invoking a context-changing function (\fBsetcontext\fR(2)) or a non-local jump
-(\fBlongjmp\fR(3C) or \fBsiglongjmp\fR(3C), or ending the current thread of
-control (\fBthr_exit\fR(3C) or \fBpthread_exit\fR(3C). The application is
+(\fBlongjmp\fR(3C) or \fBsiglongjmp\fR(3C)), or ending the current thread of
+control (\fBthr_exit\fR(3C) or \fBpthread_exit\fR(3C)). The application is
 responsible for any necessary cleanup. The state of \fBlibumem\fR remains
 consistent.
 .RE
@@ -147,7 +146,6 @@ The \fBmalloc()\fR, \fBcalloc()\fR, \fBfree()\fR, \fBmemalign()\fR,
 \fBmalloc\fR(3C). The \fBlibumem\fR library provides these functions for
 backwards-compatibility with the standard functions.
 .SH ENVIRONMENT VARIABLES
-.sp
 .LP
 See \fBumem_debug\fR(3MALLOC) for environment variables that effect the
 debugging features of the \fBlibumem\fR library.
@@ -350,7 +348,6 @@ if (status == NULL) {
 .in -2
 
 .SH ATTRIBUTES
-.sp
 .LP
 See \fBattributes\fR(5) for descriptions of the following attributes:
 .sp
@@ -374,7 +371,6 @@ Standard	See below.
 For \fBmalloc()\fR, \fBcalloc()\fR, \fBfree()\fR, \fBrealloc()\fR, and
 \fBvalloc()\fR, see \fBstandards\fR(5).
 .SH SEE ALSO
-.sp
 .LP
 \fBexit\fR(2), \fBmmap\fR(2), \fBsbrk\fR(2), \fBbsdmalloc\fR(3MALLOC),
 \fBlibumem\fR(3LIB), \fBlongjmp\fR(3C), \fBmalloc\fR(3C),
@@ -384,10 +380,12 @@ For \fBmalloc()\fR, \fBcalloc()\fR, \fBfree()\fR, \fBrealloc()\fR, and
 \fBstandards\fR(5)
 .sp
 .LP
-\fISolaris Modular Debugger Guide\fR
-.SH WARNINGS
+\fIModular Debugger Guide\fR:
 .sp
 .LP
+https://illumos.org/books/mdb/
+.SH WARNINGS
+.LP
 Any of the following can cause undefined results:
 .RS +4
 .TP
@@ -421,7 +419,6 @@ Performing \fBUMEM_NOFAIL\fR allocations from an \fBatexit\fR(3C) handler.
 If the \fBUMEM_NOFAIL\fR callback performs \fBUMEM_NOFAIL\fR allocations,
 infinite recursion can occur.
 .SH NOTES
-.sp
 .LP
 The following list compares the features of the \fBmalloc\fR(3C),
 \fBbsdmalloc\fR(3MALLOC), \fBmalloc\fR(3MALLOC), \fBmtmalloc\fR(3MALLOC) , and
diff --git a/usr/src/man/man3malloc/umem_debug.3malloc b/usr/src/man/man3malloc/umem_debug.3malloc
index 9d308f2156..89fda62a80 100644
--- a/usr/src/man/man3malloc/umem_debug.3malloc
+++ b/usr/src/man/man3malloc/umem_debug.3malloc
@@ -3,7 +3,7 @@
 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
-.TH UMEM_DEBUG 3MALLOC "Jul 26, 2002"
+.TH UMEM_DEBUG 3MALLOC "Dec 9, 2017"
 .SH NAME
 umem_debug \- debugging features of the umem library
 .SH SYNOPSIS
@@ -14,7 +14,6 @@ umem_debug \- debugging features of the umem library
 .fi
 
 .SH DESCRIPTION
-.sp
 .LP
 The \fBlibumem\fR library provides debugging features that detect memory leaks,
 buffer overruns, multiple frees, use of uninitialized data, use of freed data,
@@ -26,7 +25,6 @@ When the library detects an error, it writes a description of the error to an
 internal buffer that is readable with the \fB::umem_status\fR \fBmdb\fR(1)
 \fIdcmd\fR and then calls \fBabort\fR(3C).
 .SH ENVIRONMENT VARIABLES
-.sp
 .ne 2
 .na
 \fB\fBUMEM_DEBUG\fR\fR
@@ -168,7 +166,6 @@ cannot be allocated.
 .RE
 
 .SH ATTRIBUTES
-.sp
 .LP
 See \fBattributes\fR(5) for descriptions of the following attributes:
 .sp
@@ -186,21 +183,21 @@ MT-Level	MT-Safe
 .TE
 
 .SH SEE ALSO
-.sp
 .LP
 \fBmdb\fR(1), \fBabort\fR(3C), \fBsignal\fR(3C),
 \fBumem_cache_create\fR(3MALLOC), \fBattributes\fR(5)
 .sp
 .LP
-\fISolaris Modular Debugger Guide\fR
-.SH WARNINGS
+\fIModular Debugger Guide\fR:
 .sp
 .LP
+https://illumos.org/books/mdb/
+.SH WARNINGS
+.LP
 When \fBlibumem\fR aborts the process using \fBabort\fR(3C), any existing
 signal handler for \fBSIGABRT\fR is called. If the signal handler performs
 allocations, undefined behavior can result.
 .SH NOTES
-.sp
 .LP
 Some of the debugging features work only for allocations smaller than 16
 kilobytes in size. Allocations larger than 16 kilobytes could have reduced
diff --git a/usr/src/pkg/manifests/system-test-zfstest.mf b/usr/src/pkg/manifests/system-test-zfstest.mf
index b955be4edb..91405accea 100644
--- a/usr/src/pkg/manifests/system-test-zfstest.mf
+++ b/usr/src/pkg/manifests/system-test-zfstest.mf
@@ -2346,6 +2346,7 @@ file path=opt/zfs-tests/tests/functional/slog/slog_011_neg mode=0555
 file path=opt/zfs-tests/tests/functional/slog/slog_012_neg mode=0555
 file path=opt/zfs-tests/tests/functional/slog/slog_013_pos mode=0555
 file path=opt/zfs-tests/tests/functional/slog/slog_014_pos mode=0555
+file path=opt/zfs-tests/tests/functional/slog/slog_015_neg mode=0555
 file path=opt/zfs-tests/tests/functional/snapshot/cleanup mode=0555
 file path=opt/zfs-tests/tests/functional/snapshot/clone_001_pos mode=0555
 file path=opt/zfs-tests/tests/functional/snapshot/deadlist_lock mode=0555
diff --git a/usr/src/test/zfs-tests/tests/functional/slog/slog_015_neg.ksh b/usr/src/test/zfs-tests/tests/functional/slog/slog_015_neg.ksh
new file mode 100644
index 0000000000..952c135a9a
--- /dev/null
+++ b/usr/src/test/zfs-tests/tests/functional/slog/slog_015_neg.ksh
@@ -0,0 +1,73 @@
+#!/bin/ksh -p
+#
+# This file and its contents are supplied under the terms of the
+# Common Development and Distribution License ("CDDL"), version 1.0.
+# You may only use this file in accordance with the terms of version
+# 1.0 of the CDDL.
+#
+# A full copy of the text of the CDDL should have accompanied this
+# source.  A copy of the CDDL is also available via the Internet at
+# http://www.illumos.org/license/CDDL.
+#
+
+#
+# Copyright (c) 2017 by Delphix. All rights reserved.
+#
+
+. $STF_SUITE/tests/functional/slog/slog.kshlib
+
+#
+# DESCRIPTION:
+#	Concurrent sync writes with log offline/online works.
+#
+# STRATEGY:
+#	1. Configure "zfs_commit_timeout_pct"
+#	2. Create pool with a log device.
+#	3. Concurrently do the following:
+#	   3.1. Perform 8K sync writes
+#	   3.2. Perform log offline/online commands
+#	4. Loop to test with growing "zfs_commit_timout_pct" values.
+#
+
+verify_runnable "global"
+
+function cleanup
+{
+	#
+	# Wait for any of the writes and/or zpool commands that were
+	# kicked off in the background to complete. On failure, we may
+	# enter this function without previously waiting for them.
+	#
+	wait
+
+	mdb -kwe "zfs_commit_timeout_pct/Z $ORIG_TIMEOUT"
+
+	poolexists $TESTPOOL && zpool destroy -f $TESTPOOL
+}
+
+ORIG_TIMEOUT=$(mdb -ke "zfs_commit_timeout_pct/J" | tail -1 | awk '{print $NF}')
+log_onexit cleanup
+
+for PCT in 0 1 2 4 8 16 32 64 128 256 512 1024; do
+	log_must mdb -kwe "zfs_commit_timeout_pct/Z $PCT"
+
+	log_must zpool create $TESTPOOL $VDEV log $SDEV
+
+	for i in {1..10}; do
+		log_must fio --rw write --sync 1 --directory "/$TESTPOOL" \
+		    --bs 8K --size 8K --name slog-test
+	done &
+
+	for i in {1..10}; do
+		log_must zpool offline $TESTPOOL $SDEV
+		log_must verify_slog_device $TESTPOOL $SDEV 'OFFLINE'
+		log_must zpool online $TESTPOOL $SDEV
+		log_must verify_slog_device $TESTPOOL $SDEV 'ONLINE'
+	done &
+
+	wait
+
+	log_must zpool destroy -f $TESTPOOL
+done
+
+log_pass "Concurrent writes with slog offline/online works."
diff --git a/usr/src/uts/common/fs/zfs/sys/zil.h b/usr/src/uts/common/fs/zfs/sys/zil.h
index 1f1298e8c6..31d5e8276c 100644
--- a/usr/src/uts/common/fs/zfs/sys/zil.h
+++ b/usr/src/uts/common/fs/zfs/sys/zil.h
@@ -417,6 +417,7 @@ extern void	zil_itx_destroy(itx_t *itx);
 extern void	zil_itx_assign(zilog_t *zilog, itx_t *itx, dmu_tx_t *tx);
 
 extern void	zil_commit(zilog_t *zilog, uint64_t oid);
+extern void	zil_commit_impl(zilog_t *zilog, uint64_t oid);
 
 extern int	zil_vdev_offline(const char *osname, void *txarg);
 extern int	zil_claim(struct dsl_pool *dp,
diff --git a/usr/src/uts/common/fs/zfs/sys/zil_impl.h b/usr/src/uts/common/fs/zfs/sys/zil_impl.h
index 543ba1ee1e..af71cab7f1 100644
--- a/usr/src/uts/common/fs/zfs/sys/zil_impl.h
+++ b/usr/src/uts/common/fs/zfs/sys/zil_impl.h
@@ -37,13 +37,38 @@ extern "C" {
 #endif
 
 /*
- * Possbile states for a given lwb structure. An lwb will start out in
- * the "closed" state, and then transition to the "opened" state via a
- * call to zil_lwb_write_open(). After the lwb is "open", it can
- * transition into the "issued" state via zil_lwb_write_issue(). After
- * the lwb's zio completes, and the vdev's are flushed, the lwb will
- * transition into the "done" state via zil_lwb_write_done(), and the
- * structure eventually freed.
+ * Possbile states for a given lwb structure.
+ *
+ * An lwb will start out in the "closed" state, and then transition to
+ * the "opened" state via a call to zil_lwb_write_open(). When
+ * transitioning from "closed" to "opened" the zilog's "zl_issuer_lock"
+ * must be held.
+ *
+ * After the lwb is "opened", it can transition into the "issued" state
+ * via zil_lwb_write_issue(). Again, the zilog's "zl_issuer_lock" must
+ * be held when making this transition.
+ *
+ * After the lwb's zio completes, and the vdev's are flushed, the lwb
+ * will transition into the "done" state via zil_lwb_write_done(). When
+ * transitioning from "issued" to "done", the zilog's "zl_lock" must be
+ * held, *not* the "zl_issuer_lock".
+ *
+ * The zilog's "zl_issuer_lock" can become heavily contended in certain
+ * workloads, so we specifically avoid acquiring that lock when
+ * transitioning an lwb from "issued" to "done". This allows us to avoid
+ * having to acquire the "zl_issuer_lock" for each lwb ZIO completion,
+ * which would have added more lock contention on an already heavily
+ * contended lock.
+ *
+ * Additionally, correctness when reading an lwb's state is often
+ * acheived by exploiting the fact that these state transitions occur in
+ * this specific order; i.e. "closed" to "opened" to "issued" to "done".
+ *
+ * Thus, if an lwb is in the "closed" or "opened" state, holding the
+ * "zl_issuer_lock" will prevent a concurrent thread from transitioning
+ * that lwb to the "issued" state. Likewise, if an lwb is already in the
+ * "issued" state, holding the "zl_lock" will prevent a concurrent
+ * thread from transitioning that lwb to the "done" state.
  */
 typedef enum {
     LWB_STATE_CLOSED,
diff --git a/usr/src/uts/common/fs/zfs/sys/zio.h b/usr/src/uts/common/fs/zfs/sys/zio.h
index 281b2a678d..9c2beafaa6 100644
--- a/usr/src/uts/common/fs/zfs/sys/zio.h
+++ b/usr/src/uts/common/fs/zfs/sys/zio.h
@@ -558,7 +558,6 @@ extern enum zio_checksum zio_checksum_dedup_select(spa_t *spa,
 extern enum zio_compress zio_compress_select(spa_t *spa,
     enum zio_compress child, enum zio_compress parent);
 
-extern void zio_cancel(zio_t *zio);
 extern void zio_suspend(spa_t *spa, zio_t *zio);
 extern int zio_resume(spa_t *spa);
 extern void zio_resume_wait(spa_t *spa);
diff --git a/usr/src/uts/common/fs/zfs/zil.c b/usr/src/uts/common/fs/zfs/zil.c
index 42c571b107..910e53237c 100644
--- a/usr/src/uts/common/fs/zfs/zil.c
+++ b/usr/src/uts/common/fs/zfs/zil.c
@@ -503,7 +503,7 @@ zil_alloc_lwb(zilog_t *zilog, blkptr_t *bp, boolean_t slog, uint64_t txg)
 
 	ASSERT(!MUTEX_HELD(&lwb->lwb_vdev_lock));
 	ASSERT(avl_is_empty(&lwb->lwb_vdev_tree));
-	ASSERT(list_is_empty(&lwb->lwb_waiters));
+	VERIFY(list_is_empty(&lwb->lwb_waiters));
 
 	return (lwb);
 }
@@ -513,31 +513,13 @@ zil_free_lwb(zilog_t *zilog, lwb_t *lwb)
 {
 	ASSERT(MUTEX_HELD(&zilog->zl_lock));
 	ASSERT(!MUTEX_HELD(&lwb->lwb_vdev_lock));
-	ASSERT(list_is_empty(&lwb->lwb_waiters));
-
-	if (lwb->lwb_state == LWB_STATE_OPENED) {
-		avl_tree_t *t = &lwb->lwb_vdev_tree;
-		void *cookie = NULL;
-		zil_vdev_node_t *zv;
-
-		while ((zv = avl_destroy_nodes(t, &cookie)) != NULL)
-			kmem_free(zv, sizeof (*zv));
-
-		ASSERT3P(lwb->lwb_root_zio, !=, NULL);
-		ASSERT3P(lwb->lwb_write_zio, !=, NULL);
-
-		zio_cancel(lwb->lwb_root_zio);
-		zio_cancel(lwb->lwb_write_zio);
-
-		lwb->lwb_root_zio = NULL;
-		lwb->lwb_write_zio = NULL;
-	} else {
-		ASSERT3S(lwb->lwb_state, !=, LWB_STATE_ISSUED);
-	}
-
+	VERIFY(list_is_empty(&lwb->lwb_waiters));
 	ASSERT(avl_is_empty(&lwb->lwb_vdev_tree));
 	ASSERT3P(lwb->lwb_write_zio, ==, NULL);
 	ASSERT3P(lwb->lwb_root_zio, ==, NULL);
+	ASSERT3U(lwb->lwb_max_txg, <=, spa_syncing_txg(zilog->zl_spa));
+	ASSERT(lwb->lwb_state == LWB_STATE_CLOSED ||
+	    lwb->lwb_state == LWB_STATE_DONE);
 
 	/*
 	 * Clear the zilog's field to indicate this lwb is no longer
@@ -884,6 +866,12 @@ zil_commit_waiter_skip(zil_commit_waiter_t *zcw)
 static void
 zil_commit_waiter_link_lwb(zil_commit_waiter_t *zcw, lwb_t *lwb)
 {
+	/*
+	 * The lwb_waiters field of the lwb is protected by the zilog's
+	 * zl_lock, thus it must be held when calling this function.
+	 */
+	ASSERT(MUTEX_HELD(&lwb->lwb_zilog->zl_lock));
+
 	mutex_enter(&zcw->zcw_lock);
 	ASSERT(!list_link_active(&zcw->zcw_node));
 	ASSERT3P(zcw->zcw_lwb, ==, NULL);
@@ -1349,8 +1337,10 @@ zil_lwb_commit(zilog_t *zilog, itx_t *itx, lwb_t *lwb)
 	 * For more details, see the comment above zil_commit().
 	 */
 	if (lrc->lrc_txtype == TX_COMMIT) {
+		mutex_enter(&zilog->zl_lock);
 		zil_commit_waiter_link_lwb(itx->itx_private, lwb);
 		itx->itx_private = NULL;
+		mutex_exit(&zilog->zl_lock);
 		return (lwb);
 	}
 
@@ -1958,16 +1948,54 @@ zil_process_commit_list(zilog_t *zilog)
 			    zilog_t *, zilog, itx_t *, itx);
 		}
 
-		/*
-		 * This is inherently racy and may result in us writing
-		 * out a log block for a txg that was just synced. This
-		 * is ok since we'll end cleaning up that log block the
-		 * next time we call zil_sync().
-		 */
 		boolean_t synced = txg <= spa_last_synced_txg(spa);
 		boolean_t frozen = txg > spa_freeze_txg(spa);
 
-		if (!synced || frozen) {
+		/*
+		 * If the txg of this itx has already been synced out, then
+		 * we don't need to commit this itx to an lwb. This is
+		 * because the data of this itx will have already been
+		 * written to the main pool. This is inherently racy, and
+		 * it's still ok to commit an itx whose txg has already
+		 * been synced; this will result in a write that's
+		 * unnecessary, but will do no harm.
+		 *
+		 * With that said, we always want to commit TX_COMMIT itxs
+		 * to an lwb, regardless of whether or not that itx's txg
+		 * has been synced out. We do this to ensure any OPENED lwb
+		 * will always have at least one zil_commit_waiter_t linked
+		 * to the lwb.
+		 *
+		 * As a counter-example, if we skipped TX_COMMIT itx's
+		 * whose txg had already been synced, the following
+		 * situation could occur if we happened to be racing with
+		 * spa_sync:
+		 *
+		 * 1. we commit a non-TX_COMMIT itx to an lwb, where the
+		 *    itx's txg is 10 and the last synced txg is 9.
+		 * 2. spa_sync finishes syncing out txg 10.
+		 * 3. we move to the next itx in the list, it's a TX_COMMIT
+		 *    whose txg is 10, so we skip it rather than committing
+		 *    it to the lwb used in (1).
+		 *
+		 * If the itx that is skipped in (3) is the last TX_COMMIT
+		 * itx in the commit list, than it's possible for the lwb
+		 * used in (1) to remain in the OPENED state indefinitely.
+		 *
+		 * To prevent the above scenario from occuring, ensuring
+		 * that once an lwb is OPENED it will transition to ISSUED
+		 * and eventually DONE, we always commit TX_COMMIT itx's to
+		 * an lwb here, even if that itx's txg has already been
+		 * synced.
+		 *
+		 * Finally, if the pool is frozen, we _always_ commit the
+		 * itx.  The point of freezing the pool is to prevent data
+		 * from being written to the main pool via spa_sync, and
+		 * instead rely solely on the ZIL to persistently store the
+		 * data; i.e.  when the pool is frozen, the last synced txg
+		 * value can't be trusted.
+		 */
+		if (frozen || !synced || lrc->lrc_txtype == TX_COMMIT) {
 			if (lwb != NULL) {
 				lwb = zil_lwb_commit(zilog, itx, lwb);
 			} else if (lrc->lrc_txtype == TX_COMMIT) {
@@ -1975,22 +2003,6 @@ zil_process_commit_list(zilog_t *zilog)
 				zil_commit_waiter_link_nolwb(
 				    itx->itx_private, &nolwb_waiters);
 			}
-		} else if (lrc->lrc_txtype == TX_COMMIT) {
-			ASSERT3B(synced, ==, B_TRUE);
-			ASSERT3B(frozen, ==, B_FALSE);
-
-			/*
-			 * If this is a commit itx, then there will be a
-			 * thread that is either: already waiting for
-			 * it, or soon will be waiting.
-			 *
-			 * This itx has already been committed to disk
-			 * via spa_sync() so we don't bother committing
-			 * it to an lwb. As a result, we cannot use the
-			 * lwb zio callback to signal the waiter and
-			 * mark it as done, so we must do that here.
-			 */
-			zil_commit_waiter_skip(itx->itx_private);
 		}
 
 		list_remove(&zilog->zl_itx_commit_list, itx);
@@ -2092,7 +2104,6 @@ zil_commit_writer(zilog_t *zilog, zil_commit_waiter_t *zcw)
 {
 	ASSERT(!MUTEX_HELD(&zilog->zl_lock));
 	ASSERT(spa_writeable(zilog->zl_spa));
-	ASSERT0(zilog->zl_suspend);
 
 	mutex_enter(&zilog->zl_issuer_lock);
 
@@ -2171,10 +2182,24 @@ zil_commit_waiter_timeout(zilog_t *zilog, zil_commit_waiter_t *zcw)
 	ASSERT3P(lwb, ==, zcw->zcw_lwb);
 
 	/*
-	 * We've already checked this above, but since we hadn't
-	 * acquired the zilog's zl_issuer_lock, we have to perform this
-	 * check a second time while holding the lock. We can't call
+	 * We've already checked this above, but since we hadn't acquired
+	 * the zilog's zl_issuer_lock, we have to perform this check a
+	 * second time while holding the lock.
+	 *
+	 * We don't need to hold the zl_lock since the lwb cannot transition
+	 * from OPENED to ISSUED while we hold the zl_issuer_lock. The lwb
+	 * _can_ transition from ISSUED to DONE, but it's OK to race with
+	 * that transition since we treat the lwb the same, whether it's in
+	 * the ISSUED or DONE states.
+	 *
+	 * The important thing, is we treat the lwb differently depending on
+	 * if it's ISSUED or OPENED, and block any other threads that might
+	 * attempt to issue this lwb. For that reason we hold the
+	 * zl_issuer_lock when checking the lwb_state; we must not call
 	 * zil_lwb_write_issue() if the lwb had already been issued.
+	 *
+	 * See the comment above the lwb_state_t structure definition for
+	 * more details on the lwb states, and locking requirements.
 	 */
 	if (lwb->lwb_state == LWB_STATE_ISSUED ||
 	    lwb->lwb_state == LWB_STATE_DONE)
@@ -2264,7 +2289,6 @@ zil_commit_waiter(zilog_t *zilog, zil_commit_waiter_t *zcw)
 	ASSERT(!MUTEX_HELD(&zilog->zl_lock));
 	ASSERT(!MUTEX_HELD(&zilog->zl_issuer_lock));
 	ASSERT(spa_writeable(zilog->zl_spa));
-	ASSERT0(zilog->zl_suspend);
 
 	mutex_enter(&zcw->zcw_lock);
 
@@ -2569,6 +2593,12 @@ zil_commit(zilog_t *zilog, uint64_t foid)
 		return;
 	}
 
+	zil_commit_impl(zilog, foid);
+}
+
+void
+zil_commit_impl(zilog_t *zilog, uint64_t foid)
+{
 	/*
 	 * Move the "async" itxs for the specified foid to the "sync"
 	 * queues, such that they will be later committed (or skipped)
@@ -2981,7 +3011,22 @@ zil_suspend(const char *osname, void **cookiep)
 	zilog->zl_suspending = B_TRUE;
 	mutex_exit(&zilog->zl_lock);
 
-	zil_commit(zilog, 0);
+	/*
+	 * We need to use zil_commit_impl to ensure we wait for all
+	 * LWB_STATE_OPENED and LWB_STATE_ISSUED lwb's to be committed
+	 * to disk before proceeding. If we used zil_commit instead, it
+	 * would just call txg_wait_synced(), because zl_suspend is set.
+	 * txg_wait_synced() doesn't wait for these lwb's to be
+	 * LWB_STATE_DONE before returning.
+	 */
+	zil_commit_impl(zilog, 0);
+
+	/*
+	 * Now that we've ensured all lwb's are LWB_STATE_DONE, we use
+	 * txg_wait_synced() to ensure the data from the zilog has
+	 * migrated to the main pool before calling zil_destroy().
+	 */
+	txg_wait_synced(zilog->zl_dmu_pool, 0);
 
 	zil_destroy(zilog, B_FALSE);
 
diff --git a/usr/src/uts/common/fs/zfs/zio.c b/usr/src/uts/common/fs/zfs/zio.c
index 6dbba83ee1..e4d4b15dd1 100644
--- a/usr/src/uts/common/fs/zfs/zio.c
+++ b/usr/src/uts/common/fs/zfs/zio.c
@@ -1721,20 +1721,6 @@ zio_reexecute(zio_t *pio)
 }
 
 void
-zio_cancel(zio_t *zio)
-{
-	/*
-	 * Disallow cancellation of a zio that's already been issued.
-	 */
-	VERIFY3P(zio->io_executor, ==, NULL);
-
-	zio->io_pipeline = ZIO_INTERLOCK_PIPELINE;
-	zio->io_done = NULL;
-
-	zio_nowait(zio);
-}
-
-void
 zio_suspend(spa_t *spa, zio_t *zio)
 {
 	if (spa_get_failmode(spa) == ZIO_FAILURE_MODE_PANIC)