From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
doug.hatch-VXdhtT5mjnY@public.gmane.org,
ishii.hironobu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
zhenhua-VXdhtT5mjnY@public.gmane.org,
Bill Sumner <bill.sumner-VXdhtT5mjnY@public.gmane.org>
Subject: Re: [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Date: Wed, 2 Jul 2014 15:32:59 +0200 [thread overview]
Message-ID: <20140702133258.GN26537@8bytes.org> (raw)
In-Reply-To: <1398854973.12733.23.camel-W2I5cNIroUsVm/YvaOjsyQ@public.gmane.org>
Hi David,
On Wed, Apr 30, 2014 at 11:49:33AM +0100, David Woodhouse wrote:
> There could be all kinds of existing mappings in the DMA page tables,
> and I'm not sure it's safe to preserve them. What prevents the crashdump
> kernel from trying to use any of the physical pages which are
> accessible, and which could thus be corrupted by stray DMA?
>
> In fact, the old kernel could even have set up 1:1 passthrough mappings
> for some devices, which would then be able to DMA *anywhere*. Surely we
> need to prevent that?
Ideally we would prevent that, yes. But the problem is that a failed DMA
transaction might put the device into an unrecoverable state. Usually
any in-flight DMA transactions should only target buffers set up by the
previous kernel and not corrupt any data.
> After the last round of this patchset, we discussed a potential
> improvement where you point every virtual bus address at the *same*
> physical scratch page.
That is a solution to prevent the in-flight DMA failures. But what
happens when there is some in-flight DMA to a disk to write some inodes
or a new superblock. Then this scratch address-space may cause
filesystem corruption at worst.
So with this in mind I would prefer initially taking over the
page-tables from the old kernel before the device drivers re-initialize
the devices.
Joerg
next prev parent reply other threads:[~2014-07-02 13:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 0:36 [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO Bill Sumner
[not found] ` <1398386198-19304-1-git-send-email-bill.sumner-VXdhtT5mjnY@public.gmane.org>
2014-04-25 0:36 ` [PATCH 1/8] iommu/vt-d: Fix a few existing lines for checkpatch.pl Bill Sumner
2014-04-25 0:36 ` [PATCH 2/8] iommu/vt-d: Consolidate lines for a new private header Bill Sumner
2014-04-25 0:36 ` [PATCH 3/8] iommu/vt-d: Create intel-iommu-private.h Bill Sumner
2014-04-25 0:36 ` [PATCH 4/8] iommu/vt-d: Update iommu_attach_domain() and its callers Bill Sumner
2014-04-25 0:36 ` [PATCH 5/8] iommu/vt-d: Items required for kdump Bill Sumner
2014-04-25 0:36 ` [PATCH 6/8] iommu/vt-d: Create intel-iommu-kdump.c Bill Sumner
2014-04-25 0:36 ` [PATCH 7/8] iommu/vt-d: Add domain-id functions to intel-iommu-kdump.c Bill Sumner
2014-04-25 0:36 ` [PATCH 8/8] iommu/vt-d: Changes to support kdump Bill Sumner
2014-04-30 10:49 ` [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO David Woodhouse
[not found] ` <1398854973.12733.23.camel-W2I5cNIroUsVm/YvaOjsyQ@public.gmane.org>
2014-05-02 20:13 ` Jerry Hoemann
2014-05-07 18:25 ` Jerry Hoemann
2014-07-02 13:32 ` Joerg Roedel [this message]
[not found] ` <20140702133258.GN26537-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-07-11 16:27 ` Jerry Hoemann
[not found] ` <20140711162745.GA8335-dMAi7lA+vBPDUbYHzcRnttBPR1lH4CV8@public.gmane.org>
2014-10-15 8:10 ` Li, ZhenHua
2014-10-15 8:45 ` Li, ZhenHua
2014-10-22 2:16 ` Bjorn Helgaas
[not found] ` <CAErSpo69VmK5zD-ztNVHCA=KrK8zucqubY17z0K3rcpe6ReNUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-22 2:47 ` Eric W. Biederman
[not found] ` <87mw8on7lx.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2014-10-22 3:08 ` Li, ZhenHua
2014-10-22 13:21 ` Joerg Roedel
[not found] ` <20141022132158.GD10074-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-10-22 18:26 ` 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=20140702133258.GN26537@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=bill.sumner-VXdhtT5mjnY@public.gmane.org \
--cc=doug.hatch-VXdhtT5mjnY@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ishii.hironobu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=zhenhua-VXdhtT5mjnY@public.gmane.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 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).