rcu_read_lock_bh_held(9) [centos man page]

RCU_READ_LOCK_BH_HEL(9) 					   Driver Basics					   RCU_READ_LOCK_BH_HEL(9)

NAME

       rcu_read_lock_bh_held - might we be in RCU-bh read-side critical section?

SYNOPSIS

       int rcu_read_lock_bh_held(void);

ARGUMENTS

       void
	   no arguments

DESCRIPTION

       Check for bottom half being disabled, which covers both the CONFIG_PROVE_RCU and not cases. Note that if someone uses rcu_read_lock_bh, but
       then later enables BH, lockdep (if enabled) will show the situation. This is useful for debug checks in functions that require that they be
       called within an RCU read-side critical section.

       Check debug_lockdep_rcu_enabled to prevent false positives during boot.

       Note that rcu_read_lock is disallowed if the CPU is either idle or offline from an RCU perspective, so check for those as well.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   RCU_READ_LOCK_BH_HEL(9)

CRITICAL_ENTER(9)					   BSD Kernel Developer's Manual					 CRITICAL_ENTER(9)

NAME

     critical_enter, critical_exit -- enter and exit a critical region

SYNOPSIS

     #include <sys/param.h>
     #include <sys/systm.h>

     void
     critical_enter(void);

     void
     critical_exit(void);

DESCRIPTION

     These functions are used to prevent preemption in a critical region of code.  All that is guaranteed is that the thread currently executing
     on a CPU will not be preempted.  Specifically, a thread in a critical region will not migrate to another CPU while it is in a critical
     region.  The current CPU may still trigger faults and exceptions during a critical section; however, these faults are usually fatal.

     The critical_enter() and critical_exit() functions manage a per-thread counter to handle nested critical sections.  If a thread is made
     runnable that would normally preempt the current thread while the current thread is in a critical section, then the preemption will be
     deferred until the current thread exits the outermost critical section.

     Note that these functions are not required to provide any inter-CPU synchronization, data protection, or memory ordering guarantees and thus
     should not be used to protect shared data structures.

     These functions should be used with care as an infinite loop within a critical region will deadlock the CPU.  Also, they should not be inter-
     locked with operations on mutexes, sx locks, semaphores, or other synchronization primitives.  One exception to this is that spin mutexes
     include a critical section, so in certain cases critical sections may be interlocked with spin mutexes.

HISTORY

     These functions were introduced in FreeBSD 5.0.

BSD
								  October 5, 2005							       BSD