[英]Does context switching occurs when IOCTL is issued from user space while kernel module is holding a spin_lock without disabling interrupts?
I have a critical section in kernel module which is protected under a spin_lock()
.我在内核模块中有一个关键部分,它受
spin_lock()
保护。 I have used spin_lock()
to acquire the lock without disabling irq or softirqs.我已经使用
spin_lock()
在不禁用 irq 或 softirqs 的情况下获取锁。 As we know IOCTLs are syscalls which enters kernel through software interrupt 128 (0x80).正如我们所知,IOCTL 是通过软件中断 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?因此,如果在获取
spin_lock()
的临界区中间时从用户空间发出 IOCTL,是否会发生上下文切换? What if the same spin_lock()
is used at the backend of IOCTLs too?如果在 IOCTL 的后端也使用相同的
spin_lock()
会怎样? Does it lead to deadlock?会导致死锁吗?
I have used spin_lock() to acquire the lock without disabling irq or softirqs
我已经使用 spin_lock() 在不禁用 irq 或 softirqs 的情况下获取锁
IRQ/SoftIRQ has nothing to do with system calls. IRQ/SoftIRQ 与系统调用无关。 Disabling IRQs or softIRQs is needed when protected data structure potentially can be used from within interrupt context .
当受保护的数据结构可能在中断上下文中使用时,需要禁用 IRQ 或 softIRQ 。 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 .顺便说一句,有一个特殊的
spin_lock
-API,如spin_lock_bh()/spin_unlock_bh()
、 spin_lock_irq()
/ spin_unlock_irq()
等。您应该阅读本指南。
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 - eg 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.
因此,如果您的数据结构只能从用户上下文中访问 - 您应该为用户上下文使用常规锁定 API。
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.那么只有更高优先级的代码可以抢占(IRQ、softIRQ),但是如果“更高优先级的代码”不会尝试获取您持有的锁,则无需担心(从死锁的角度来看)。
What if the same spin_lock() is used at the backend of IOCTLs too?
如果在 IOCTL 的后端也使用相同的 spin_lock() 会怎样?
It will definitely "spin" until you release the lock.在您释放锁之前,它肯定会“旋转”。
Does it lead to deadlock?
会导致死锁吗?
In depends on how you will use it.取决于您将如何使用它。
PS what's wrong with mutexes? PS互斥体有什么问题?
Read also:另请阅读:
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.