From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
Noam Camus <noamc@ezchip.com>,
arcml <linux-snps-arc@lists.infradead.org>
Subject: Re: Interesting csd deadlock on ARC
Date: Tue, 23 Feb 2016 15:51:23 +0530 [thread overview]
Message-ID: <56CC32A3.5020804@synopsys.com> (raw)
In-Reply-To: <20160223095824.GH6356@twins.programming.kicks-ass.net>
>> What I actually meant was is it OK for irq_work_queue_on() to be called locally
>> (is this a sched bug/optimization(. Further if it is OK to be called, does it need
>> to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or
>> arch_send_call_function_single_ipi() is expected to handle sending IPI to self !
>
> Right, so I'm not actually sure we started out with this requirement.
> But you're not the first to run into this, see:
>
> lkml.kernel.org/r/CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com
Thx for the link, very helpful. I've posted fix for ARC which uses software
interrupt and is thus UP/SMP safe.
> Initially I think irq_work_queue_on() was only used remotely, but I
> think it makes sense to allow the current cpu, esp. since people seem to
> be using it like that.
>
> Now the distinct difference between arch_irq_work_raise() and
> arch_send_call_function_single_ipi() is that arch_irq_work_raise()
> should be NMI-safe.
Ok - so when I implement interrupt priorities (aka NMI for ARC), this needs to be
highest.
>
> So on x86 it has to be extra careful about the lapic state, whereas the
> regular IPI code doesn't.
>
> I seem to have forgotten the status of NMIs on ARC, but this is
> something to make a note of.
Not had a chance to go back to it since we last discussed.
I've just been swamped with bug fixing like this one :-(
Thx,
-Vineet
WARNING: multiple messages have this Message-ID (diff)
From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: Interesting csd deadlock on ARC
Date: Tue, 23 Feb 2016 15:51:23 +0530 [thread overview]
Message-ID: <56CC32A3.5020804@synopsys.com> (raw)
In-Reply-To: <20160223095824.GH6356@twins.programming.kicks-ass.net>
>> What I actually meant was is it OK for irq_work_queue_on() to be called locally
>> (is this a sched bug/optimization(. Further if it is OK to be called, does it need
>> to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or
>> arch_send_call_function_single_ipi() is expected to handle sending IPI to self !
>
> Right, so I'm not actually sure we started out with this requirement.
> But you're not the first to run into this, see:
>
> lkml.kernel.org/r/CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg at mail.gmail.com
Thx for the link, very helpful. I've posted fix for ARC which uses software
interrupt and is thus UP/SMP safe.
> Initially I think irq_work_queue_on() was only used remotely, but I
> think it makes sense to allow the current cpu, esp. since people seem to
> be using it like that.
>
> Now the distinct difference between arch_irq_work_raise() and
> arch_send_call_function_single_ipi() is that arch_irq_work_raise()
> should be NMI-safe.
Ok - so when I implement interrupt priorities (aka NMI for ARC), this needs to be
highest.
>
> So on x86 it has to be extra careful about the lapic state, whereas the
> regular IPI code doesn't.
>
> I seem to have forgotten the status of NMIs on ARC, but this is
> something to make a note of.
Not had a chance to go back to it since we last discussed.
I've just been swamped with bug fixing like this one :-(
Thx,
-Vineet
next prev parent reply other threads:[~2016-02-23 10:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 6:47 Interesting csd deadlock on ARC Vineet Gupta
2016-02-19 6:47 ` Vineet Gupta
2016-02-23 5:21 ` Vineet Gupta
2016-02-23 5:21 ` Vineet Gupta
2016-02-23 9:58 ` Peter Zijlstra
2016-02-23 9:58 ` Peter Zijlstra
2016-02-23 9:58 ` Peter Zijlstra
2016-02-23 10:21 ` Vineet Gupta [this message]
2016-02-23 10:21 ` Vineet Gupta
2016-02-23 10:39 ` Peter Zijlstra
2016-02-23 10:39 ` Peter Zijlstra
2016-02-23 10:58 ` Noam Camus
2016-02-23 10:58 ` Noam Camus
2016-02-23 10:58 ` Noam Camus
2016-02-24 4:45 ` Vineet Gupta
2016-02-24 4:45 ` Vineet Gupta
2016-02-24 4:51 ` Vineet Gupta
2016-02-24 4:51 ` Vineet Gupta
2016-02-25 14:06 ` Peter Zijlstra
2016-02-25 14:06 ` Peter Zijlstra
2016-02-25 14:06 ` Peter Zijlstra
2016-02-25 14:23 ` Vineet Gupta
2016-02-25 14:23 ` Vineet Gupta
2016-02-25 14:30 ` Russell King - ARM Linux
2016-02-25 14:30 ` Russell King - ARM Linux
2016-02-25 15:58 ` Vineet Gupta
2016-02-25 15:58 ` Vineet Gupta
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=56CC32A3.5020804@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=fweisbec@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=noamc@ezchip.com \
--cc=peterz@infradead.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.