From: Robert Love <rml@tech9.net>
To: Jeremy Hall <jhall@maoz.com>
Cc: linux-mm@kvack.org
Subject: Re: interrupt context
Date: 14 Apr 2003 18:57:21 -0400 [thread overview]
Message-ID: <1050361041.3664.121.camel@localhost> (raw)
In-Reply-To: <200304142148.h3ELm7HB016432@sith.maoz.com>
On Mon, 2003-04-14 at 17:48, Jeremy Hall wrote:
> > Note two processors can never run the _same_ handler for the same line.
> > A given line (say IRQ 8) is masked out on all processors while its
> > handler.
>
> ok, but in this case, the same handler appears on two different lines,
> once for one RME card, once for the other. It is theoretically possible
> that one line could be handled by once CPU and the other by the other CPU.
Yep. You must obtain a spin lock and disable local interrupts if there
is any shared data here (and I am sure there is).
> > Further, if SA_INTERRUPT is specified then all other interrupts are
> > disabled, too, on the local processor.
> >
> It would appear this may not be true, or my understanding of the code is
> not sound (more likely) it would also appear rme9652_read might not be
> able to differuntiate between being called for an RME card or another
> card.
It is true :)
See irq.c for your architecture. On x86, we have handle_IRQ_event():
if (!(action->flags & SA_INTERRUPT))
local_irq_enable();
It is called with interrupts disabled. Unless SA_INTERRUPT is set,
though, they are enabled here. Note this is the _local_ processor only.
> I'm still digging at this, so don't know yet how to answer this point.
> I'm thinking somehow we need to schedule the snd_pcm_period_elapsed, or
> force it to run in interrupt context.
>
> I thought I had done the latter by moving the snd_rme9652_write to the
> bottom of the function so that it wouldn't clear the interrupt condition
> until after it processed the data.
>
> but I guess I hadn't because it didn't make a difference. This is why I
> raise the question about whether other interrupts can be called.
Well, as I have said, they can still run on OTHER processors, as long as
its a different interrupt line (same handler is irrelevant).
So you can have these two handlers you speak of run at the same time. I
think you are trying to prevent that, no?
Well, you cannot... but you can protect the shared data or hardware with
a lock. Grab a spin_lock in the handler prior to doing what you wish to
protect. This will prevent that chunk of code from running
simultaneously.
Linus has a nice discussion on spin locks in Documentation/spinlocks.txt
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2003-04-14 22:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 18:51 interrupt context Jeremy Hall
2003-04-14 18:56 ` Robert Love
2003-04-14 19:32 ` Jeremy Hall
2003-04-14 19:35 ` Robert Love
2003-04-14 21:09 ` Jeremy Hall
2003-04-14 21:18 ` Robert Love
2003-04-14 21:48 ` Jeremy Hall
2003-04-14 22:57 ` Robert Love [this message]
2003-04-15 3:44 ` Jeremy Hall
2003-04-15 4:14 ` Jeremy Hall
2003-04-15 21:40 ` Robert Love
2003-04-15 23:02 ` Jeremy Hall
2003-04-16 3:41 ` Jeremy Hall
-- strict thread matches above, loose matches on Subject: below --
2008-03-23 21:44 Interrupt context Codrin Alexandru Grajdeanu
2008-03-24 21:00 ` Christopher Li
2008-03-25 1:34 ` Octavian Purdila
2008-03-25 2:57 ` Christopher Li
2008-03-26 12:43 ` Octavian Purdila
2008-03-26 21:53 ` Christopher Li
[not found] <CA+bLfK5FPqFvU2xy7xKdV4LkAvmY6GAPFrB-4UBzn-cOunQ6Xg@mail.gmail.com>
2012-10-05 8:51 ` interrupt context Iain Fraser
2012-10-05 9:32 ` Borislav Petkov
2012-10-05 10:20 ` Iain Fraser
2012-10-05 10:34 ` Borislav Petkov
2012-10-05 13:27 ` Theodore Ts'o
2012-10-05 14:03 ` Iain Fraser
2012-10-05 18:05 ` anish kumar
2012-10-05 18:15 ` Iain Fraser
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=1050361041.3664.121.camel@localhost \
--to=rml@tech9.net \
--cc=jhall@maoz.com \
--cc=linux-mm@kvack.org \
/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 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.