[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210907122045.x6jyanqaf43rasnq@pali>
Date: Tue, 7 Sep 2021 14:20:45 +0200
From: Pali Rohár <pali@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Rob Herring <robh@...nel.org>, Marc Zyngier <maz@...nel.org>,
linux-pci <linux-pci@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: pci-ftpci100: race condition in masking/unmasking interrupts
On Tuesday 07 September 2021 13:22:37 Linus Walleij wrote:
> On Wed, Aug 18, 2021 at 1:47 PM Pali Rohár <pali@...nel.org> wrote:
>
> > I do not see any entry in MAINTAINERS file for pci-ftpci100.c driver, so
> > I'm not sure to whom should I address this issue...
>
> It's me.
Ok! So could you send update for MAINTAINERS file for this driver?
> > During pci-aardvark review, Marc pointed one issue which is currently
> > available also in pci-ftpci100.c driver.
> >
> > When masking or unmasking interrupts there is read-modify-write sequence
> > for FARADAY_PCI_CTRL2 register without any locking and is not atomic:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pci-ftpci100.c?h=v5.13#n270
> >
> > So there is race condition when masking/unmasking more interrupts at the
> > same time.
>
> I thought those operations were called in atomic context.
I guess that they cannot be as for performance reasons you could want to
mask or unmask more interrupts in parallel on more CPUs.
> How did you fix it?
Guarding all read-modify-write operations on register by raw spin lock. See:
https://lore.kernel.org/linux-pci/20210820155020.3000-1-pali@kernel.org/
Powered by blists - more mailing lists