All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: indou.takao@jp.fujitsu.com, bhe@redhat.com,
	linux-pci@vger.kernel.org, kexec@lists.infradead.org, "Hoemann,
	Jerry" <jerry.hoemann@hp.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	doug.hatch@hp.com, ishii.hironobu@jp.fujitsu.com,
	bhelgaas@google.com, zhenhua@hp.com,
	Bill Sumner <bill.sumner@hp.com>
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@i7.infradead.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



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
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

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Bill Sumner <bill.sumner@hp.com>,
	"Hoemann, Jerry" <jerry.hoemann@hp.com>,
	indou.takao@jp.fujitsu.com, bhe@redhat.com,
	linux-pci@vger.kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	doug.hatch@hp.com, ishii.hironobu@jp.fujitsu.com,
	bhelgaas@google.com, zhenhua@hp.com
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@i7.infradead.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



  parent reply	other threads:[~2014-07-02 13:33 UTC|newest]

Thread overview: 61+ 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
2014-04-25  0:36 ` Bill Sumner
2014-04-25  0:36 ` Bill Sumner
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   ` Bill Sumner
2014-04-25  0:36   ` 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   ` Bill Sumner
2014-04-25  0:36   ` 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   ` Bill Sumner
2014-04-25  0:36   ` 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   ` Bill Sumner
2014-04-25  0:36   ` Bill Sumner
2014-04-25  0:36 ` [PATCH 5/8] iommu/vt-d: Items required for kdump Bill Sumner
2014-04-25  0:36   ` Bill Sumner
2014-04-25  0:36   ` 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   ` Bill Sumner
2014-04-25  0:36   ` 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   ` Bill Sumner
2014-04-25  0:36   ` Bill Sumner
2014-04-25  0:36 ` [PATCH 8/8] iommu/vt-d: Changes to support kdump Bill Sumner
2014-04-25  0:36   ` Bill Sumner
2014-04-25  0:36   ` Bill Sumner
2014-04-30 10:49 ` [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO David Woodhouse
2014-04-30 10:49   ` David Woodhouse
2014-04-30 10:49   ` David Woodhouse
2014-05-02 20:13   ` Jerry Hoemann
2014-05-02 20:13     ` Jerry Hoemann
2014-05-02 20:13     ` Jerry Hoemann
2014-05-07 18:25   ` Jerry Hoemann
2014-05-07 18:25     ` Jerry Hoemann
2014-05-07 18:25     ` Jerry Hoemann
2014-07-02 13:32   ` Joerg Roedel [this message]
2014-07-02 13:32     ` Joerg Roedel
2014-07-02 13:32     ` Joerg Roedel
2014-07-11 16:27     ` Jerry Hoemann
2014-07-11 16:27       ` Jerry Hoemann
2014-07-11 16:27       ` Jerry Hoemann
2014-10-15  8:10       ` Li, ZhenHua
2014-10-15  8:10         ` Li, ZhenHua
2014-10-15  8:10         ` Li, ZhenHua
2014-10-15  8:45         ` Li, ZhenHua
2014-10-15  8:45           ` Li, ZhenHua
2014-10-22  2:16     ` Bjorn Helgaas
2014-10-22  2:16       ` Bjorn Helgaas
2014-10-22  2:16       ` Bjorn Helgaas
2014-10-22  2:47       ` Eric W. Biederman
2014-10-22  2:47         ` Eric W. Biederman
2014-10-22  2:47         ` Eric W. Biederman
2014-10-22  3:08         ` Li, ZhenHua
2014-10-22  3:08           ` Li, ZhenHua
2014-10-22  3:08           ` Li, ZhenHua
2014-10-22 13:21       ` Joerg Roedel
2014-10-22 13:21         ` Joerg Roedel
2014-10-22 18:26         ` Bjorn Helgaas
2014-10-22 18:26           ` Bjorn Helgaas
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@8bytes.org \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=bill.sumner@hp.com \
    --cc=doug.hatch@hp.com \
    --cc=dwmw2@infradead.org \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=ishii.hironobu@jp.fujitsu.com \
    --cc=jerry.hoemann@hp.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=zhenhua@hp.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.