From: liyu <liyu@ccoss.com.cn>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Question] spin_lock in interrupt handler.
Date: Mon, 21 Nov 2005 09:13:10 +0800 [thread overview]
Message-ID: <43811F26.7080309@ccoss.com.cn> (raw)
In-Reply-To: <1132353884.14048.10.camel@localhost.localdomain>
Steven Rostedt wrote:
>On Fri, 2005-11-18 at 16:37 +0800, liyu wrote:
>
>
>>Hi, every one in LKML.
>>
>> I have one question about how to use spin_lock.
>>
>> I read Documentation/spinlocks.txt wrote by Linus. The Lesson 1 and
>>2 are simple for me.
>>But I confused in Lesson 3. The most doublt is why we can not use
>>spin_lock_irq*() version in
>>interrupt handler?
>>
>> At i386, I known the interrupt is disabled in interrupt handler. I
>>think this feature is
>>supplied in handware-level. The spin_lock_irqrestore() will use 'sti'
>>instruction internal, it will change interrupt mask bit in FLAGS
>>register, do this have re-enable interrupt, even in interrput handler? I
>>can not sure this.
>>
>>
>
>Hello once again Liyu ;-)
>
>I don't see where he says you can't use spin_lock_irq* in interrupt
>handlers. He only says that you are safe to use the non-irq* versions
>IFF (if and only if) the locks are not used in interrupts.
>
>So, (copied from the text itself):
>
>---
>The reasons you mustn't use these versions if you have interrupts that
>play with the spinlock is that you can get deadlocks:
>
> spin_lock(&lock);
> ...
> <- interrupt comes in:
> spin_lock(&lock);
>---
>
>If you hold a spin lock without interrupts disabled, and an interrupt
>happens on the same CPU that holds the lock, and that interrupt handler
>tries to grab the lock it will just spin until that lock is released,
>which will _never_ happen, since the lock is held by the process that
>was interrupted, and will not run until the interrupt (that's spinning)
>is done. So you have a deadlock.
>
>Clear?
>
>-- Steve
>
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
>
>
>
>
Hi, Steven, Nice to meet you too ;) (These are the words that I first
studied in English class.)
Yes, I am clear, I think I understand it in wrong direction before.
Good Luck.
-liyu
prev parent reply other threads:[~2005-11-21 1:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 10:18 [Question]How to restrict some kind of task? liyu
2005-11-15 10:21 ` Con Kolivas
2005-11-16 1:16 ` liyu
2005-11-17 6:20 ` liyu
2005-11-17 9:57 ` Con Kolivas
2005-11-18 8:37 ` [Question] spin_lock in interrupt handler liyu
2005-11-18 22:44 ` Steven Rostedt
2005-11-21 1:13 ` liyu [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=43811F26.7080309@ccoss.com.cn \
--to=liyu@ccoss.com.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox