All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@impinj.com>
To: "marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"gustavo.pimentel@synopsys.com" <gustavo.pimentel@synopsys.com>
Cc: "jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"faiz_abbas@ti.com" <faiz_abbas@ti.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jpinto@synopsys.com" <jpinto@synopsys.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>
Subject: Re: [PATCH] PCI: dwc: Fix interrupt race in when handling MSI
Date: Fri, 9 Nov 2018 18:53:02 +0000	[thread overview]
Message-ID: <1541789582.30311.382.camel@impinj.com> (raw)
In-Reply-To: <b4dfa6e0-c569-c669-d3f1-b1016eecefa8@arm.com>

On Fri, 2018-11-09 at 11:34 +0000, Marc Zyngier wrote:
> On 08/11/18 19:49, Trent Piepho wrote:
> > On Thu, 2018-11-08 at 09:49 +0000, Marc Zyngier wrote:
> > > 
> > Then that lasted four years until it was changed Aug 2017 in https://pa
> > tchwork.kernel.org/patch/9893303/
> > 
> > That lasted just six months until someone tried to revert it, https://p
> > atchwork.kernel.org/patch/9893303/

Should be https://patchwork.kernel.org/patch/10208879/

> > 
> > Seems pretty clear the way it is now is much worse than the way it was
> > before, even if the previous design may have had another flaw.  Though
> > I've yet to see anyone point out something makes the previous design
> > broken.  Sub-optimal yes, but not broken.
> 
> This is not what was reported by the previous submitter. I guess they
> changed this for a reason, no? I'm prepared to admit this is a end-point
> driver bug, but we need to understand what is happening and stop
> changing this driver randomly.

See Vignesh's recent message about the last change.  It was a mistaken
attempt to fix a problem, which it didn't fix, and I think we all agree
it's not right.

Reverting it is not "changing this driver randomly."  And I take that
as a personal offense.  You imply I just applied patches randomly until
something appeared to work.  Maybe you think this is all over my head? 
Far from it.  I traced every part of the interrupt path and thought
through every race.  Hamstrung by lack of docs, I still determined the
behavior that was relevant through empirical analysis.  I only
discovered this was a recent regression and Vignesh's earlier attempt
to revert it after I was done and was trying to determine how the code
got this way in the first place.

> > It feels like you're using this bug to hold designware hostage in a
> > broken kernel, and me along with them.  I don't have the documentation,
> > no one does, there's no way for me to give you want you want.  But I've
> > got hardware that doesn't work in the mainline kernel.
> 
> I take it as a personal offence that I'd be holding anything or anyone
> hostage. I think I have a long enough track record working with the
> Linux kernel not to take any of this nonsense. What's my interest in
> keeping anything in this sorry state? Think about it for a minute.

I'm sorry if you took it that way.  I appreciate that there are still
people who care about fixing things right and don't settle for whatever
the easiest thing is that lets them say they're done, even if that just
leaves time bombs for everyone who comes after.

So I thank you for taking a stand.

But I think it's clear that 8c934095fa2f was a mistake that causes
serious bugs.  That's not a random guess; it's well considered and well
tested.  Not reverting it now isn't helping anyone using stable kernels
with this regression.

  reply	other threads:[~2018-11-09 18:53 UTC|newest]

Thread overview: 32+ 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 10:28 ` Vignesh R
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 17:17                 ` Vignesh R
2018-11-09 11:34               ` Marc Zyngier
2018-11-09 18:53                 ` Trent Piepho [this message]
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
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=1541789582.30311.382.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=jpinto@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 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.