Bottom Half vs. Kernel context in Preemption disabled kernel

0
votes

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?

1
linux-kerneldevice-driver
Did you read Rusty's Unreliable Guide To Locking? - CL.
Yes. It's only covering PREEMPTION enable case or both PREEMPTION and SMP are disabled. What I'm wondering is, CONFIG_SMP=y and No preemption configuration, how softirq is executed. - user2526111
The API is the same regardless of configuration. - CL.
I'm only wondering, bottom half can preempt the kernel context (kernel thread which is not in ISR/BH). Also, wondering when ISR schedules BH, it will be executed regardless of current running thread. Thanks! - user2526111
Kernel and 'normal' threads are not different in this regard. - CL.

1 Answers

1
votes

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.