Updated: 2022/Sep/29

Please read Privacy Policy. It's for your privacy.

KERNEL_LOCK(9)             Kernel Developer's Manual            KERNEL_LOCK(9)

     KERNEL_LOCK - compatibility with legacy uniprocessor code

     #include <sys/systm.h>

     KERNEL_LOCK(int nlocks, struct lwp *l);

     KERNEL_UNLOCK_ONE(struct lwp *l);

     KERNEL_UNLOCK_ALL(struct lwp *l, int *nlocksp);

     KERNEL_UNLOCK_LAST(struct lwp *l);


     The KERNEL_LOCK facility serves to gradually transition software from the
     kernel's legacy uniprocessor execution model, where the kernel runs on
     only a single CPU and never in parallel on multiple CPUs, to a
     multiprocessor system.

     New code should not use KERNEL_LOCK.  KERNEL_LOCK is meant only for
     gradual transition of NetBSD to natively MP-safe code, which uses
     mutex(9) or other locking(9) facilities to synchronize between threads
     and interrupt handlers.  Use of KERNEL_LOCK hurts system performance and
     responsiveness.  This man page exists only to document the legacy API in
     order to make it easier to transition away from.

     The kernel lock, sometimes also known as `giant lock' or `big lock', is a
     recursive exclusive spin-lock that can be held by a CPU at any interrupt
     priority level and is dropped while sleeping.  This means:

     recursive      If a CPU already holds the kernel lock, it can be acquired
                    again and again, as long as it is released an equal number
                    of times.

     exclusive      Only one CPU at a time can hold the kernel lock.

     spin-lock      When one CPU holds the kernel lock and another CPU wants
                    to hold it, the second CPU `spins', i.e., repeatedly
                    executes instructions to see if the kernel lock is
                    available yet, until the first CPU releases it.  During
                    this time, no other threads can run on the spinning CPU.

                    This means holding the kernel lock for long periods of
                    time, such as nontrivial computation, must be avoided.
                    Under LOCKDEBUG kernels, holding the kernel lock for too
                    long can lead to `spinout' crashes.

     held by a CPU  The kernel lock is held by a CPU, not by a process,
                    kthread, LWP, or interrupt handler.  It may be shared by a
                    kthread LWP and several softint LWPs at the same time, for
                    example, if the softints interrupted the thread on a CPU.

     any interrupt priority level
                    The kernel lock does not block interrupts; subsystems
                    running with the kernel lock use spl(9) to synchronize
                    with interrupt handlers.

                    Interrupt handlers that are not marked MP-safe are always
                    run with the kernel lock.  If the interrupt arrives on a
                    CPU where the kernel lock is already held, it is simply
                    taken again recursively on interrupt entry and released to
                    its original recursion depth on interrupt exit.

     dropped while sleeping
                    Any time the kernel sleeps to let other threads run, for
                    any reason including tsleep(9) or condvar(9) or even
                    adaptive mutex(9) locks, it releases the kernel lock
                    before going to sleep and then reacquires it afterward.

                    This means, for instance, that although data structures
                    accessed only under the kernel lock won't be changed
                    before the sleep, they may be changed by another thread
                    during the sleep.  For example, the following program may
                    crash on an assertion failure because the sleep in
                    mutex_enter(9) can allow another CPU to run and change the
                    global variable x:

                            KERNEL_LOCK(1, NULL);
                            x = 42;
                            KASSERT(x == 42);

                    This means simply introducing calls to mutex_enter(9) and
                    mutex_exit(9) can break kernel-locked assumptions.
                    Subsystems need to be consistently converted from
                    KERNEL_LOCK and spl(9) to mutex(9), condvar(9), etc.;
                    mixing mutex(9) and KERNEL_LOCK usually doesn't work.

     Holding the kernel lock does not prevent other code from running on other
     CPUs at the same time.  It only prevents other kernel-locked code from
     running on other CPUs at the same time.

     KERNEL_LOCK(nlocks, l)
           Acquire nlocks recursive levels of kernel lock.

           If the kernel lock is already held by another CPU, spins until it
           can be acquired by this one.  If the kernel lock is already held by
           this CPU, records the kernel lock recursion depth and returns

           Most of the time nlocks is 1, but code that deliberately releases
           all of the kernel locks held by the current CPU in order to sleep
           and later reacquire the same number of kernel locks will pass a
           value of nlocks obtained from KERNEL_UNLOCK_ALL().

           Release one level of the kernel lock.  Equivalent to
           KERNEL_UNLOCK(1, l, NULL).

     KERNEL_UNLOCK_ALL(l, nlocksp)
           Store the kernel lock recursion depth at nlocksp and release all
           recursive levels of the kernel lock.

           This is often used inside logic implementing sleep, around a call
           to mi_switch(9), so that the same number of recursive kernel locks
           can be reacquired afterward once the thread is reawoken:

                   int nlocks;

                   KERNEL_UNLOCK_ALL(l, &nlocks);
                   ... mi_switch(l) ...
                   KERNEL_LOCK(nlocks, l);

           Release the kernel lock, which must be held at exactly one level.

           This is normally used at the end of a non-MP-safe thread, which was
           known to have started with exactly one level of the kernel lock,
           and is now about to exit.

           True if the kernel lock is held.

           To be used only in diagnostic assertions with KASSERT(9).

     The legacy argument l must be NULL or curlwp, which mean the same thing.

     Some NetBSD kernel abstractions execute caller-specified functions with
     the kernel lock held by default, for compatibility with legacy code, but
     can be explicitly instructed not to hold the kernel lock by passing an
     MP-safe flag:

        callout(9), CALLOUT_MPSAFE

        kfilter_register(9) and knote(9), FILTEROPS_MPSAFE

        kthread(9), KTHREAD_MPSAFE

        pci_intr(9), PCI_INTR_MPSAFE

        scsipi(9), SCSIPI_ADAPT_MPSAFE

        softint(9), SOFTINT_MPSAFE

        usbdi(9) pipes, USBD_MPSAFE

        usbdi(9) tasks, USB_TASKQ_MPSAFE

        vnode(9), VV_MPSAFE

        workqueue(9), WQ_MPSAFE

     The following NetBSD subsystems are still kernel-locked and need re-
     engineering to take advantage of parallelism on multiprocessor systems:

        ata(4), atapi(4), wd(4)



        most of the network stack by default, unless the option NET_MPSAFE is


     All interrupt handlers at IPL_VM, or lower (spl(9)) run with the kernel
     lock on most ports.

     locking(9), mutex(9), spl(9)

NetBSD 9.99                    February 13, 2022                   NetBSD 9.99