From: Andi Kleen <ak@suse.de>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>,
Jan Glauber <jan.glauber@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] i386/x86_64: smp_call_function locking inconsistency
Date: Fri, 9 Feb 2007 08:40:12 +0100 [thread overview]
Message-ID: <200702090840.12899.ak@suse.de> (raw)
In-Reply-To: <20070208203210.GB9798@osiris.ibm.com>
On Thursday 08 February 2007 21:32, Heiko Carstens wrote:
> On i386/x86_64 smp_call_function_single() takes call_lock with
> spin_lock_bh(). To me this would imply that it is legal to call
> smp_call_function_single() from softirq context.
> It's not since smp_call_function() takes call_lock with just
> spin_lock(). We can easily deadlock:
>
> -> [process context]
> -> smp_call_function()
> -> spin_lock(&call_lock)
> -> IRQ -> do_softirq -> tasklet
> -> [softirq context]
> -> smp_call_function_single()
> -> spin_lock_bh(&call_lock)
> -> dead
>
> So either all spin_lock_bh's should be converted to spin_lock,
> which would limit smp_call_function()/smp_call_function_single()
> to process context & irqs enabled.
> Or the spin_lock's could be converted to spin_lock_bh which would
> make it possible to call these two functions even if in softirq
> context. AFAICS this should be safe.
I'm not so sure. Perhaps drop _bh in both and stick a WARN_ON_ONCE in
to catch the cases?
-Andi
prev parent reply other threads:[~2007-02-09 7:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 20:32 [patch] i386/x86_64: smp_call_function locking inconsistency Heiko Carstens
2007-02-08 20:43 ` David Miller
2007-02-09 8:42 ` Heiko Carstens
2007-02-09 12:57 ` Jan Glauber
2007-06-07 14:07 ` Satyam Sharma
2007-06-07 16:27 ` Heiko Carstens
2007-06-07 16:54 ` Satyam Sharma
2007-06-07 17:18 ` Satyam Sharma
2007-06-07 17:22 ` Avi Kivity
2007-06-07 17:33 ` Satyam Sharma
2007-06-10 7:38 ` Avi Kivity
2007-06-08 19:43 ` Andi Kleen
2007-06-08 19:42 ` Andi Kleen
2007-02-09 7:40 ` Andi Kleen [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=200702090840.12899.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jan.glauber@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=schwidefsky@de.ibm.com \
/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.