From: Trent Piepho <tpiepho@impinj.com>
To: "lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>
Cc: "jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"gustavo.pimentel@synopsys.com" <gustavo.pimentel@synopsys.com>,
"faiz_abbas@ti.com" <faiz_abbas@ti.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"joao.pinto@synopsys.com" <joao.pinto@synopsys.com>,
"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"vigneshr@ti.com" <vigneshr@ti.com>,
"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [PATCH] PCI: dwc: Fix interrupt race in when handling MSI
Date: Wed, 14 Nov 2018 21:29:28 +0000 [thread overview]
Message-ID: <1542230968.30311.485.camel@impinj.com> (raw)
In-Reply-To: <20181112160148.GA26379@e107981-ln.cambridge.arm.com>
On Mon, 2018-11-12 at 16:01 +0000, Lorenzo Pieralisi wrote:
> On Thu, Nov 08, 2018 at 08:51:38PM +0000, Trent Piepho wrote:
> >
> > The reason is that the GIC interrupt above the dwc is non-reentrant.
> > It remains masked (aka active[1]) during this entire process (1 to 10).
> > This means every MSI is effectively already masked. So masking the
> > active MSI(s) a 2nd time gains nothing besides preventing some extra
> > edges for a masked interrupt going to the ARM GIC.
> >
> > In theory, if the GIC interrupt handler was reentrant, then on receipt
> > of a new MSI we could re-enter the dwc handler on a different CPU and
> > run the new MSI (a different MSI!) at the same time as the original MSI
> > handler is still running.
> >
> > There difference here is that by unmasking in the interrupt in the GIC
> > before the dwc handler is finished, masking an individual MSI in the
> > dwc is no longer a 2nd redundant masking.
>
> There is not (and there must not be) anything in DWC HW that allows
> us assume its "interrupt controller" is cascaded to a GIC. It may
> correspond to what we are debugging but it is an assumption we must not
> make and its driver has to work regardless of what its interrupt
> controller is connected to, that's the basis of hierarchical IRQ chips
> management, at least from my narrow and (most likely) incomplete
> knowledge of the IRQ subsystem.
If you mean we can't assume the dwc is cascaded from specifically a
GIC, totally agree.
If you mean we can't assume the dwc is cascaded from "something", then
I disagree. The driver can't possibly be at the top level. How would
the cpu ever enter it?
What I think really is what matters here is if the the chain the dwc is
cascaded from allows the dwc to be called reentrantly or not.
On my system, the code base I inspected does not allow that. I don't
know of any written Linux interrupt policy that says this must be the
case. If it is not the case, then I see other points in the dwc driver
that are potentially racy.
next prev parent reply other threads:[~2018-11-15 7:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-27 0:00 [PATCH] PCI: dwc: Fix interrupt race in when handling MSI Trent Piepho
2018-11-05 12:08 ` Gustavo Pimentel
2018-11-06 14:53 ` Lorenzo Pieralisi
2018-11-06 16:00 ` Marc Zyngier
2018-11-06 19:40 ` Trent Piepho
2018-11-07 11:07 ` Lorenzo Pieralisi
2018-11-07 12:58 ` Gustavo Pimentel
2018-11-07 18:41 ` Marc Zyngier
2018-11-07 20:17 ` Trent Piepho
2018-11-08 9:49 ` Marc Zyngier
2018-11-08 19:49 ` Trent Piepho
2018-11-09 10:13 ` Lorenzo Pieralisi
2018-11-09 11:34 ` Marc Zyngier
2018-11-09 18:53 ` Trent Piepho
2018-11-13 0:41 ` Gustavo Pimentel
2018-11-13 1:18 ` Trent Piepho
2018-11-13 10:36 ` Lorenzo Pieralisi
2018-11-13 18:55 ` Trent Piepho
2018-11-13 14:40 ` Marc Zyngier
2018-11-07 12:57 ` Gustavo Pimentel
2018-11-07 18:32 ` Trent Piepho
2018-11-08 11:46 ` Gustavo Pimentel
2018-11-08 20:51 ` Trent Piepho
2018-11-12 16:01 ` Lorenzo Pieralisi
2018-11-13 1:03 ` Gustavo Pimentel
2018-11-14 21:29 ` Trent Piepho [this message]
2018-11-12 23:45 ` Gustavo Pimentel
2018-11-07 18:46 ` Marc Zyngier
2018-11-08 11:24 ` Gustavo Pimentel
2018-11-06 18:59 ` Trent Piepho
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=1542230968.30311.485.camel@impinj.com \
--to=tpiepho@impinj.com \
--cc=bhelgaas@google.com \
--cc=faiz_abbas@ti.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=joao.pinto@synopsys.com \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=marc.zyngier@arm.com \
--cc=stable@vger.kernel.org \
--cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).