Does context switching occurs when IOCTL is issued from user space while kernel module is holding a spin_lock without disabling interrupts?

Question

I have a critical section in kernel module which is protected under a spin_lock(). I have used spin_lock() to acquire the lock without disabling irq or softirqs. As we know IOCTLs are syscalls which enters kernel through software interrupt 128 (0x80). Hence, if an IOCTL is been issued from user space while we are in middle of critical section acquiring the spin_lock(), does context switching happens? What if the same spin_lock() is used at the backend of IOCTLs too? Does it lead to deadlock?

Are trying to acquire some global `spin_lock` or it is your own `spin_lock`? — red0ct, Feb 06 '20 at 09:35

red0ct · Answer 1 · 2020-02-06T12:31:49.133

I have used spin_lock() to acquire the lock without disabling irq or softirqs

IRQ/SoftIRQ has nothing to do with system calls. Disabling IRQs or softIRQs is needed when protected data structure potentially can be used from within interrupt context. Btw there are a special spin_lock-APIs like spin_lock_bh()/spin_unlock_bh(), spin_lock_irq()/spin_unlock_irq(), etc. You should read this guide.

does context switching happens?

I don't see anything to stop it (if you mean syscall context switch). When system call occurs it enters kernel-mode (context switch) in user context (process context - e.g. context of the process which provoked syscall), not interrupt or soft interrupt context. So if your data structure can be accessed only from within user context - you should use regular locking APIs for user context.
As for context switch in kernel-mode while holding a spinlock - it cannot happen because spinlock by itself disables preemption:

static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
    preempt_disable();
    spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
    LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}

Then only higher priority code can preempt (IRQs, softIRQs), but it has nothing to worry (from a perspective of deadlocks) if that "higher priority code" won't try to acquire the lock you're holding.

What if the same spin_lock() is used at the backend of IOCTLs too?

It will definitely "spin" until you release the lock.

Does it lead to deadlock?

In depends on how you will use it.

P.S. what's wrong with mutexes?

Does context switching occurs when IOCTL is issued from user space while kernel module is holding a spin_lock without disabling interrupts?

1 Answers1