Search code examples
linux-kerneldevice-driver

Bottom Half vs. Kernel context in Preemption disabled kernel

Quick question.

  1. Ethernet driver raise IRQ.
  2. ISR will schedule tasklet (BH)
  3. There is critical section between this tasklet and some kernel context (which is trigger by "ioctl")
  4. KERNEL_PREEMPTION is disabled / But CONFIG_SMP is enabled (2 CPUs)

In this situation, should I use "spin_lock_bh"?

Since preemption is "disabled", even though kernel context holds "spin_lock", tasklet cannot preempt the kernel context which is calling ioctl and this kernel context is kind of "safe" from BH.

or is it possible for following scenario to happen?

When this kernel context is getting serviced, IRQ comes and ISR will schedule tasklet. Then, after returning from IRQ, kernel schedule will pickup tasklet even though there is kernel context.

I'm not sure which one is correct?

Solution

  • Preemption status is irrelevant. Upon return from the ISR, the tasklet could run whether preemption is enabled or disabled. So, yes you need to use spin_lock_bh().

    Regarding synchronization issues, SoftIRQs/Tasklets behave like the ISRs, the only difference is that ISRs interrupt BHs. Since the ISR interrupted the kernel while it was holding a lock, so can the tasklet.