Re: Spinlock query

On 8/30/06, Rik van Riel <riel@xxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Spinlock query
    ... > In my driver (Process context), I have written the following code: ... > //Critical section to manipulate driver data ... interrupt handler tries to grab the spinlock, ... Why will it "BOOM"? ...
    (Linux-Kernel)
  • Re: [patch 2/5] [PREEMPT_RT] Changing interrupt handlers from running in thread to hardirq and back
    ... where one of the latter makes the interrupt handler threaded. ... The change_irq_contextcall-back must be set at request_irq, so it it is not enough to just make a new function where the driver can set it's the callback after the request_irq. ... extern int request_irq(unsigned int, ...
    (Linux-Kernel)
  • Re: Fwd: Removing Giant from a driver
    ... pass that mutex instead of Giant... ... I doubt this driver is using a fast interrupt handler... ... A fast interrupt handler doesn't context switch, ... don't understand what Giant is good for. ...
    (freebsd-hackers)
  • Receiving problem in Realtek RTL8139D(L) network card driver implementation
    ... I am a newbie to the device driver developement in Linux. ... After this, when i ping a host, driver saying transmission of ICMP ... successfull transmission in interrupt handler) and also incrementing ... icmp packet 1: DESTINATION HOST UNREACHABLE ...
    (comp.os.linux.networking)
  • Receiving problem in Realtek RTL8139D(L) network card driver implementation
    ... I am a newbie to the device driver developement in Linux. ... After this, when i ping a host, driver saying transmission of ICMP ... successfull transmission in interrupt handler) and also incrementing ... icmp packet 1: DESTINATION HOST UNREACHABLE ...
    (comp.os.linux.development.system)