Synchronous analysis of spin lock in Linux kernel __linux

<linux kernel design and implementation >6-7-8 chapter about spin lock synchronization in the proposed
The use of spin locks in operations in the lower half of the interrupt processing is especially necessary: the lower half process and the process context share data, because the processing of the lower part can preempt the process context code.
Therefore, the process context should prohibit the execution of the lower half before adding a lock to the shared data, and then allow the execution of the lower part to unlock.
The following for this point of attention points of personal understanding, the level of limited hope passing the great God can leave valuable comments Thank you ~
1. First look at the definition of In_interrupt ():
#define IN_INTERRUPT () (Irq_count ())
#define IRQ_COUNT () (Preempt_count () & (Hardirq_mask | Softirq_mask \
| Nmi_mask))

2. Look again at the definition of Preempt_count ():
#define PREEMPT_COUNT () (Current_thread_info ()->preempt_count)
Preempt_count is divided into 4 domains: nmi-hardirq-softirq-preempt The entire field is related to preemption. When the preempt_count!=0 ban steals,
Otherwise allow steals

3. The above mentioned spin lock, look at the operation of the spin lock
Spin_lock (spinlock_t* Lock)
{
Raw_spin_lock (&lock->rlock);
}
Raw_spin_lock (raw_spinlock_t* Lock)
{
Preemption related,
Preempt_disable ();
Lock bus operation on x86
Do_raw_spin_lock (lock);
}
Preempt_disable ()->inc_preempt_count ()->add_preempt_count (1)->
#define Add_preempt_count (val) \
do{\
Preempt_count () + + (val); \
while (0);
Execute Preempt_count () + = (val); , Spin_lock () makes the preempt field in the Current_thread_info ()->preempt_count field Non-zero, and further, it prohibits the process from stealing.

Combine the above analysis to look at the scenarios where preemption may occur when sharing data:
  1 sharing data between processes and interrupts: Interrupt no task structure, not accept process scheduling, with mutexes and other mutual exclusion after sleep, no longer wake up, so can only choose spin lock;
  Because the process is interrupted at any time, the spin lock does not protect the shared data, so the process replaces spin_lock with a SPIN_LOCK_IRQ shielding interrupt before entering the critical section. The
  2) process shares data with Tasklet: Tasklet is sometimes run in Do_irq (although sometimes run by KSOFTIRQD) and is not fully exited after a break recovery, so
  is waking up to sleep. ; Tasklet the condition being executed is if (!in_interrupt () &&local_softirq_pending ()) {...}.
  If the process is interrupted and executed into the DO_SOFTIRQ, the process is still interrupted, although the mutex (i.e. Preempt_count preempt+1) is on, but as described above In_interrupt ()
  uses only the 3 fields of NMI-HARDIRQ-SOFTIRQ, so it is possible to start performing soft interrupts successfully through the if judgment, making the protection of shared data unsuccessful. If the process is to protect shared data, call Local_bh_disable ();
  Increase the value of the Preempt_count:softirq field so that!in_interrupt () fails;
  3) tasklet-interrupts shared data: Only the mask is interrupted.
 
  Note: The role of In_interrupt can feel similar to the IRQL in Windows, such as organizing statements, update a IRQL related log