From: Bjorn Helgaas <helgaas@kernel.org>
To: Daniel Stodden <dns@arista.com>
Cc: Dmitry Safonov <dima@arista.com>,
Logan Gunthorpe <logang@deltatee.com>,
Kurt Schwemmer <kurt.schwemmer@microsemi.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v4 1/1] PCI: switchtec: Fix stdev_release() crash after surprise hot remove
Date: Wed, 22 Nov 2023 09:55:31 -0600 [thread overview]
Message-ID: <20231122155531.GA300313@bhelgaas> (raw)
In-Reply-To: <20231122042316.91208-2-dns@arista.com>
On Tue, Nov 21, 2023 at 08:23:16PM -0800, Daniel Stodden wrote:
> A PCI device hot removal may occur while stdev->cdev is held open. The call
> to stdev_release() then happens during close or exit, at a point way past
> switchtec_pci_remove(). Otherwise the last ref would vanish with the
> trailing put_device(), just before return.
>
> At that later point in time, the devm cleanup has already removed the
> stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
> one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
> a fatal page fault, and the subsequent dma_free_coherent(), if reached,
> would pass a stale &stdev->pdev->dev pointer.
>
> Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
> stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
> future accidents.
>
> Reproducible via the script at
> https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
>
> Link: https://lore.kernel.org/r/20231113212150.96410-2-dns@arista.com
> Signed-off-by: Daniel Stodden <dns@arista.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> Reviewed-by: Dmitry Safonov <dima@arista.com>
Oh, I forgot to mention: for future reference, you should only add
Signed-off-by when you create the patch or you receive it from
somebody else and are passing it on.
You should not add the Signed-off-by of the person you're sending it
*to*, because that person will add their own Signed-off-by when they
process it. E.g., I apply patches with "git am --signoff" which adds
my Signed-off-by, which would result in a duplicate.
No worries, I took care of it so there's no duplicate for me :)
Bjorn
next prev parent reply other threads:[~2023-11-22 15:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 4:23 [PATCH v4 0/1] PCI: switchtec: Fix stdev_release() crash after surprise hot remove Daniel Stodden
2023-11-22 4:23 ` [PATCH v4 1/1] " Daniel Stodden
2023-11-22 15:55 ` Bjorn Helgaas [this message]
2023-11-22 19:03 ` Daniel Stodden
2023-12-07 21:08 ` Christophe JAILLET
2023-12-08 22:36 ` Daniel Stodden
2023-11-22 15:48 ` [PATCH v4 0/1] " Bjorn Helgaas
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=20231122155531.GA300313@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=dima@arista.com \
--cc=dns@arista.com \
--cc=kurt.schwemmer@microsemi.com \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.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.