Re: locking and interrupts

[Jason Nymble <jason.nymble@xxxxxxxxx>]

On 07 Oct 2009, at 7:47 AM, er krishna wrote:

Rajat San,

Just asking (since i didn't see spinlock implementation in kernel src),

On Tue, Oct 6, 2009 at 5:52 PM, Rajat Jain <Rajat.Jain@xxxxxxxxxxxx> wrote:

Hello Govind,

> What happens when you go for spin locks without
> disabling kernel preemption? Suppose you acquire
> a spin lock in a system call handler (a service
> routine on behalf of a user mode process) with
> kernel preemption enabled.

This is not possible. Spin lock APIs disable kernel preemption
automatically.

Spin lock APIs disables kernel preemption in all its api or some specific apis only. Please confirm and elaborate.


 

There are a few variants of the spin lock APIs. See the link which various people have posted for details:

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/index.html

The most basic spin_lock() does not disable scheduling or interrupts etc., so must be avoided for synchronization between a syscall and an interrupt context otherwise you will get deadlock. spin_lock_irqsave() disables all pre-emptive scheduling and interrupts AFAIK, so it would be safe. I think it is generally preferable to avoid using spin_lock_irqsave() if possible by deferring your interrupt work to a tasklet (in which you can use spin_lock_bh to sync to your syscall) or a workqueue (in which you can use a semaphore to sync to your syscall). Even better would be to use lockless algorithms or data structures if possible. In general, if you must use a spinlock, try to keep it limited to a very small piece of code to reduce lock contention. Also, enable kernel debugging and specifically the options about lock checking, these can help a great deal to debug issues. I hope the aforementioned information is correct and doesn't lead you astray...