Spinlocks and interrupts

[kai@gnukai.com (Kai Meyer)]

Alright, to summarize, for my benefit mostly,

I'm writing a block device driver, which has 2 entry points into my code 
that will reach this critical section. It's either the make request 
function for the block device, or the resulting bio->bi_end_io function. 
I do some waiting with msleep() (for now) from the make request function 
entry point, so I'm confident that entry point is not in an atomic 
context. I also only end up requesting the critical section to call 
kmalloc from this context, which is why I never ran into the scheduling 
while atomic issue before.

I'm fairly certain the critical section executes in thread context not 
interrupt context from either entry point.

I'm certain that the spinlock_t is only ever used in one function (a I 
posted a simplified version of the critical section earlier).

It seems that the critical section is often called in an atomic context.

The spin_lock function sounds like it will only cause a second call to 
spin_lock to spin if it is called on a separate core.

But, since I'm certain the critical section is never called from 
interrupt context, only thread context, the fact that pre-emption is 
disabled on the core should provide the protection I need with out 
having to disable IRQs. Disabling IRQs would prevent an interrupt from 
occurring while the lock is acquired. I would like to avoid disabling 
interrupts if I don't need to.

So it sounds like spin_lock/spin_unlock is the correct choice?

In addition, I'd like to be more confident in my assumptions above. Can 
I test for atomic context? For instance, I know that you can call 
irqs_disabled(), is there a similar is_atomic() function I can call? I 
would like to put a few calls in different places to learn what sort of 
context I'm.

-Kai Meyer

On 11/10/2011 12:19 PM, Jeff Haran wrote:
>> -----Original Message-----
>> From: kernelnewbies-bounces+jharan=bytemobile.com at kernelnewbies.org
>> [mailto:kernelnewbies-
>> bounces+jharan=bytemobile.com at kernelnewbies.org] On Behalf Of Dave
>> Hylands
>> Sent: Thursday, November 10, 2011 11:07 AM
>> To: Kai Meyer
>> Cc: kernelnewbies at kernelnewbies.org
>> Subject: Re: Spinlocks and interrupts
>>
>> Hi Kai,
>>
>> On Thu, Nov 10, 2011 at 10:14 AM, Kai Meyer<kai@gnukai.com>  wrote:
>>> I think I get it. I'm hitting the scheduling while atomic because
> I'm
>>> calling my function from a struct bio's endio function, which is
>>> probably running with a lock held somewhere else, and then my mutex
>>> sleeps, while the spin_lock functions do not sleep.
>> Actually, just holding a lock doesn't create an atomic context.
> I believe on kernels with kernel pre-emption enabled the act of taking
> the lock disables pre-emption. If it didn't work this way you could end
> up taking the lock in one process context and while the lock was held
> get pre-empted. Then another process tries to take the lock and you dead
> lock.
>
> Jeff Haran
>
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies