All of lore.kernel.org
 help / color / mirror / Atom feed
* Spinlock query
@ 2006-08-30  2:12 ` Rick Brown
  0 siblings, 0 replies; 7+ messages in thread
From: Rick Brown @ 2006-08-30  2:12 UTC (permalink / raw)
  To: kernelnewbies, linux-newbie, linux-kernel

Hi,

In my driver (Process context), I have written the following code:

--------------------------------------------
spin_lock(lock)
...
//Critical section to manipulate driver data
...
spin_u lock(lock)
---------------------------------------------

I have written similar code in my interrupt handler (Interrupt
context). The driver data is not accessed from anywhere else. Is my
code safe from any potential concurrency issues? Is there a need to
use spin_lock_irqsave()? In both the places?

I intend to run the driver on SMP machine.

Regards,

Rick

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Spinlock query
@ 2006-08-30  2:12 ` Rick Brown
  0 siblings, 0 replies; 7+ messages in thread
From: Rick Brown @ 2006-08-30  2:12 UTC (permalink / raw)
  To: kernelnewbies, linux-newbie, linux-kernel

Hi,

In my driver (Process context), I have written the following code:

--------------------------------------------
spin_lock(lock)
...
//Critical section to manipulate driver data
...
spin_u lock(lock)
---------------------------------------------

I have written similar code in my interrupt handler (Interrupt
context). The driver data is not accessed from anywhere else. Is my
code safe from any potential concurrency issues? Is there a need to
use spin_lock_irqsave()? In both the places?

I intend to run the driver on SMP machine.

Regards,

Rick
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Spinlock query
  2006-08-30  2:12 ` Rick Brown
  (?)
@ 2006-08-30  3:10 ` Rik van Riel
  2006-08-30  5:31   ` Rajat Jain
       [not found]   ` <fa2bedd60608292159ra9fce70wd1dbc8231d9c052c@mail.gmail.com>
  -1 siblings, 2 replies; 7+ messages in thread
From: Rik van Riel @ 2006-08-30  3:10 UTC (permalink / raw)
  To: Rick Brown; +Cc: kernelnewbies, linux-kernel

Rick Brown wrote:
> Hi,
> 
> In my driver (Process context), I have written the following code:
> 
> --------------------------------------------
> spin_lock(lock)
> ...
> //Critical section to manipulate driver data

... interrupt hits here
     interrupt handler tries to grab the spinlock, which is already taken
     *BOOM*

> spin_u lock(lock)
> ---------------------------------------------
> 
> I have written similar code in my interrupt handler (Interrupt
> context). The driver data is not accessed from anywhere else. Is my
> code safe from any potential concurrency issues? Is there a need to
> use spin_lock_irqsave()? In both the places?

You need to use spin_lock_irqsave() from process context.
 From the interrupt handler itself it doesn't hurt, but it
shouldn't matter much since interrupt handlers should not
get preempted.

-- 
What is important?  What you want to be true, or what is true?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Spinlock query
  2006-08-30  3:10 ` Rik van Riel
@ 2006-08-30  5:31   ` Rajat Jain
  2006-08-30  6:04     ` Vin
  2006-08-30 12:03     ` Rik van Riel
       [not found]   ` <fa2bedd60608292159ra9fce70wd1dbc8231d9c052c@mail.gmail.com>
  1 sibling, 2 replies; 7+ messages in thread
From: Rajat Jain @ 2006-08-30  5:31 UTC (permalink / raw)
  To: Rik van Riel; +Cc: Rick Brown, kernelnewbies, linux-kernel

On 8/30/06, Rik van Riel <riel@surriel.com> wrote:
> Rick Brown wrote:
> > Hi,
> >
> > In my driver (Process context), I have written the following code:
> >
> > --------------------------------------------
> > spin_lock(lock)
> > ...
> > //Critical section to manipulate driver data
>
> ... interrupt hits here
>     interrupt handler tries to grab the spinlock, which is already taken
>     *BOOM*
>
> > spin_u lock(lock)
> > ---------------------------------------------
> >

The interrupt handler TRIES to grab the spinlock, which is already
taken. Why will it "BOOM"? Wouldn't the interrupt handler busy wait,
waiting for the lock?

Am I missing something here?

Rajat

> > I have written similar code in my interrupt handler (Interrupt
> > context). The driver data is not accessed from anywhere else. Is my
> > code safe from any potential concurrency issues? Is there a need to
> > use spin_lock_irqsave()? In both the places?
>
> You need to use spin_lock_irqsave() from process context.
>  From the interrupt handler itself it doesn't hurt, but it
> shouldn't matter much since interrupt handlers should not
> get preempted.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Spinlock query
  2006-08-30  5:31   ` Rajat Jain
@ 2006-08-30  6:04     ` Vin
  2006-08-30 12:03     ` Rik van Riel
  1 sibling, 0 replies; 7+ messages in thread
From: Vin @ 2006-08-30  6:04 UTC (permalink / raw)
  To: Rajat Jain; +Cc: Rik van Riel, Rick Brown, kernelnewbies, linux-kernel

Hi,

On 8/30/06, Rajat Jain <rajat.noida.india@gmail.com> wrote:
> On 8/30/06, Rik van Riel <riel@surriel.com> wrote:
> > Rick Brown wrote:
> > > Hi,
> > >
> > > In my driver (Process context), I have written the following code:
> > >
> > > --------------------------------------------
> > > spin_lock(lock)
> > > ...
> > > //Critical section to manipulate driver data
> >
> > ... interrupt hits here
> >     interrupt handler tries to grab the spinlock, which is already taken
> >     *BOOM*
> >
> > > spin_u lock(lock)
> > > ---------------------------------------------
> > >
>
> The interrupt handler TRIES to grab the spinlock, which is already
> taken. Why will it "BOOM"? Wouldn't the interrupt handler busy wait,
> waiting for the lock?
>
If you take spin_lock in interrupt as well as in process context then-:
1. On UP non-preempt kernel: There will be no locks taken, so nothing
is gonna protect the shared data between the interrupt handler &
process context thread.
2. On the UP preempt kernel: The lock has been taken by the process
context, and now if the interrupts is issued, it will try to grab the
same lock, but it will never get it ... and nobody is going to leave
that lock. boom* - Deadlock.
3. On SMP machine non-preempt kernel: The locks will be taken but no
protection against the interrupt as such.
4. On SMP preempt kernel: process context threads are synchronised but
not the interrupts.

> > > I have written similar code in my interrupt handler (Interrupt
> > > context). The driver data is not accessed from anywhere else. Is my
> > > code safe from any potential concurrency issues? Is there a need to
> > > use spin_lock_irqsave()? In both the places?
> >
> > You need to use spin_lock_irqsave() from process context.
> >  From the interrupt handler itself it doesn't hurt, but it
> > shouldn't matter much since interrupt handlers should not
> > get preempted.

Yes, AFAIK the correct idea is to take spin_lock() in interrupt
handler (Here I consider that your interrupt is already disabled.)
And take spin_lock_irq() or spin_lock_irqsave() lock from the process
context.

--v

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Spinlock query
  2006-08-30  5:31   ` Rajat Jain
  2006-08-30  6:04     ` Vin
@ 2006-08-30 12:03     ` Rik van Riel
  1 sibling, 0 replies; 7+ messages in thread
From: Rik van Riel @ 2006-08-30 12:03 UTC (permalink / raw)
  To: Rajat Jain; +Cc: Rick Brown, kernelnewbies, linux-kernel

Rajat Jain wrote:
> On 8/30/06, Rik van Riel <riel@surriel.com> wrote:
>> Rick Brown wrote:
>> > Hi,
>> >
>> > In my driver (Process context), I have written the following code:
>> >
>> > --------------------------------------------
>> > spin_lock(lock)
>> > ...
>> > //Critical section to manipulate driver data
>>
>> ... interrupt hits here
>>     interrupt handler tries to grab the spinlock, which is already taken
>>     *BOOM*
>>
>> > spin_u lock(lock)
>> > ---------------------------------------------
>> >
> 
> The interrupt handler TRIES to grab the spinlock, which is already
> taken. Why will it "BOOM"? Wouldn't the interrupt handler busy wait,
> waiting for the lock?
> 
> Am I missing something here?

Yes, it will busy wait.  Forever.


-- 
What is important?  What you want to be true, or what is true?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Spinlock query
       [not found]   ` <fa2bedd60608292159ra9fce70wd1dbc8231d9c052c@mail.gmail.com>
@ 2006-09-01  2:31     ` Rajat Jain
  0 siblings, 0 replies; 7+ messages in thread
From: Rajat Jain @ 2006-09-01  2:31 UTC (permalink / raw)
  To: Manoj Awasthi; +Cc: Rik van Riel, Rick Brown, kernelnewbies, linux-kernel

>
> > You need to use spin_lock_irqsave() from process context.
> > From the interrupt handler itself it doesn't hurt, but it
> > shouldn't matter much since interrupt handlers should not
> > get preempted.
>
>
> but interrupt handlers run in interrupt context when interrupts are already
> disabled. Is that correct ?
>

AFAIK the interrupt that the handler is serving is guaranteed to be
disabled on all the processors.

In addition, if the interrupt was registered with SA_INTERRUPT flag,
all the interrupts will be disabled on the current processor.

Regards,

Rajat

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2006-09-01  2:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-08-30  2:12 Spinlock query Rick Brown
2006-08-30  2:12 ` Rick Brown
2006-08-30  3:10 ` Rik van Riel
2006-08-30  5:31   ` Rajat Jain
2006-08-30  6:04     ` Vin
2006-08-30 12:03     ` Rik van Riel
     [not found]   ` <fa2bedd60608292159ra9fce70wd1dbc8231d9c052c@mail.gmail.com>
2006-09-01  2:31     ` Rajat Jain

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.