public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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





      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