Print this page
9249 System crash dump to NVME not working
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
Reviewed by: Evan Layton <evan.layton@nexenta.com>
Reviewed by: Rick McNeal <rick.mcneal@nexenta.com>
Reviewed by: Ryan Zezeski <rpz@joyent.com>
@@ -1,125 +1,104 @@
SEMAPHORE(9F) Kernel Functions for Drivers SEMAPHORE(9F)
-
-
NAME
- semaphore, sema_init, sema_destroy, sema_p, sema_p_sig, sema_v,
- sema_tryp - semaphore functions
+ semaphore, sema_init, sema_destroy, sema_p, sema_p_sig, sema_v, sema_tryp
+ - semaphore functions
SYNOPSIS
#include <sys/ksynch.h>
-
-
- void sema_init(ksema_t *sp, uint_t val, char *name, ksema_type_t type,
+ void
+ sema_init(ksema_t *sp, uint_t val, char *name, ksema_type_t type,
void *arg);
+ void
+ sema_destroy(ksema_t *sp);
- void sema_destroy(ksema_t *sp);
+ void
+ sema_p(ksema_t *sp);
+ void
+ sema_v(ksema_t *sp);
- void sema_p(ksema_t *sp);
+ int
+ sema_p_sig(ksema_t *sp);
+ int
+ sema_tryp(ksema_t *sp);
- void sema_v(ksema_t *sp);
-
-
- int sema_p_sig(ksema_t *sp);
-
-
- int sema_tryp(ksema_t *sp);
-
-
INTERFACE LEVEL
- Solaris DDI specific (Solaris DDI).
+ illumos DDI specific (illumos DDI).
PARAMETERS
- sp
- A pointer to a semaphore, type ksema_t.
+ sp A pointer to a semaphore, type ksema_t.
+ val Initial value for semaphore.
- val
- Initial value for semaphore.
-
-
- name
- Descriptive string. This is obsolete and should be NULL.
+ name Descriptive string. This is obsolete and should be NULL.
(Non-NULL strings are legal, but they are a waste of kernel
memory.)
-
- type
- Variant type of the semaphore. Currently, only SEMA_DRIVER is
+ type Variant type of the semaphore. Currently, only SEMA_DRIVER is
supported.
+ arg Type-specific argument; should be NULL.
- arg
- Type-specific argument; should be NULL.
-
-
DESCRIPTION
These functions implement counting semaphores as described by Dijkstra.
A semaphore has a value which is atomically decremented by sema_p() and
atomically incremented by sema_v(). The value must always be greater
than or equal to zero. If sema_p() is called and the value is zero, the
calling thread is blocked until another thread performs a sema_v()
operation on the semaphore.
-
Semaphores are initialized by calling sema_init(). The argument, val,
gives the initial value for the semaphore. The semaphore storage is
provided by the caller but more may be dynamically allocated, if
necessary, by sema_init(). For this reason, sema_destroy() should be
called before deallocating the storage containing the semaphore.
-
The sema_p_sig() function decrements the semaphore, as does sema_p().
- However, if the semaphore value is zero, sema_p_sig() will return
- without decrementing the value if a signal (that is, from kill(2)) is
- pending for the thread.
+ However, if the semaphore value is zero, sema_p_sig() will return without
+ decrementing the value if a signal (that is, from kill(2)) is pending for
+ the thread.
+ The sema_tryp() function will decrement the semaphore value only if it is
+ greater than zero, and will not block.
- The sema_tryp() function will decrement the semaphore value only if it
- is greater than zero, and will not block.
-
-RETURN VALUES
- 0
- sema_tryp() could not decrement the semaphore value because it was
- zero.
-
-
- 1
- sema_p_sig() was not able to decrement the semaphore value and
- detected a pending signal.
-
-
CONTEXT
These functions can be called from user, interrupt, or kernel context,
- except for sema_init() and sema_destroy(), which can be called from
- user or kernel context only. None of these functions can be called from
- a high-level interrupt context. In most cases, sema_v() and sema_p()
+ except for sema_init() and sema_destroy(), which can be called from user
+ or kernel context only. None of these functions can be called from a
+ high-level interrupt context. In most cases, sema_v() and sema_p()
should not be called from any interrupt context.
-
If sema_p() is used from interrupt context, lower-priority interrupts
- will not be serviced during the wait. This means that if the thread
- that will eventually perform the sema_v() becomes blocked on anything
- that requires the lower-priority interrupt, the system will hang.
+ will not be serviced during the wait. This means that if the thread that
+ will eventually perform the sema_v() becomes blocked on anything that
+ requires the lower-priority interrupt, the system will hang.
+ For example, the thread that will perform the sema_v() may need to first
+ allocate memory. This memory allocation may require waiting for paging
+ I/O to complete, which may require a lower-priority disk or network
+ interrupt to be serviced. In general, situations like this are hard to
+ predict, so it is advisable to avoid waiting on semaphores or condition
+ variables in an interrupt context.
- For example, the thread that will perform the sema_v() may need to
- first allocate memory. This memory allocation may require waiting for
- paging I/O to complete, which may require a lower-priority disk or
- network interrupt to be serviced. In general, situations like this are
- hard to predict, so it is advisable to avoid waiting on semaphores or
- condition variables in an interrupt context.
+ Similar to many other synchronization mechanisms, semaphores should not
+ be used in any code path that requires synchronization while handling
+ system panic, at which time many of the semaphore operations become no-
+ ops.
+RETURN VALUES
+ 0 sema_tryp() could not decrement the semaphore value because it
+ was zero.
+
+ 1 sema_p_sig() was not able to decrement the semaphore value and
+ detected a pending signal.
+
SEE ALSO
kill(2), condvar(9F), mutex(9F)
-
Writing Device Drivers
-
-
- May 7, 1997 SEMAPHORE(9F)
+illumos July 30, 2018 illumos