mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kittur Sameer <kssameer@attbi.com>
To: sridharv@ufl.edu, linux-kernel@vger.kernel.org
Subject: Re: interrupt - spin lock question
Date: Sun, 3 Mar 2002 22:32:37 -0800	[thread overview]
Message-ID: <20020304063447.THGI2951.rwcrmhc53.attbi.com@there> (raw)
In-Reply-To: <1015219129.3c8303b9e87a7@webmail.health.ufl.edu>
In-Reply-To: <1015219129.3c8303b9e87a7@webmail.health.ufl.edu>

On Sunday 03 March 2002 09:18 pm, sridharv@ufl.edu wrote:
> I have a question related to spin locking on UP systems.Before that I would
> like to point out my understanding of the background stuff
> 1. spinlocks shud be used in intr handlers

It should be used in the interrupt handler, if you need to prevent any  race 
conditions with other interrupt/non-interrupt  context code that may be 
executing on some other CPU on an SMP system. Thus spinlocks need to be held 
for as short a duration as possible. You would need to use the 
spin_lock_irqsave/spin_unlock_irqrestore variant pair to prevent your 
interrupt handler from running on the same processor while holding the lock. 
This may be  needed if the interrupt handler may try to acquire the same lock 
thus causing a deadlock.

> 2. interrupts can preempt kernel code
> 3. spinlocks are turned to empty when kernel is compiled without SMP
> support.
>
> If a particular driver is running( not the intr handler part) and at this
> time an interrupt occurs. The handler has to be invoked now. Won't the
> preemption cause race conditions/inconsistencies? Is any other mechanism
> used? Pl correct me if I have not understood any part of this correctly

On a UP kernel the spin_lock_irqsave/spin_unlock_irqrestore pair expand to 
save_flags(flag); cli()/restore_flags(flag).

The masking of interrupts on the processor between spin_lock_irqsave and 
spin_unlock_irqrestore  pair prevent the user context code from being 
preempted by the interrupt handler.


Sameer.

      parent reply	other threads:[~2002-03-04  6:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-04  5:18 sridharv
2002-03-04  5:27 ` Robert Love
2002-03-04  6:33   ` sridharv
2002-03-04  7:19   ` Robert Love
2002-03-04  6:32 ` Kittur Sameer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020304063447.THGI2951.rwcrmhc53.attbi.com@there \
    --to=kssameer@attbi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sridharv@ufl.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®