All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, ZhenHua" <zhen-hual@hp.com>
To: Joerg Roedel <joro@8bytes.org>, David Woodhouse <dwmw2@infradead.org>
Cc: indou.takao@jp.fujitsu.com, bhe@redhat.com,
	linux-pci@vger.kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, Jerry.Hoemann@hp.com,
	iommu@lists.linux-foundation.org, 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, 15 Oct 2014 16:10:02 +0800	[thread overview]
Message-ID: <543E2BDA.8030906@hp.com> (raw)
In-Reply-To: <20140711162745.GA8335@anatevka.fc.hp.com>

David, Joerg,
I plan to merge this patch set with 3.17 stable kernel, and split this 
patch set into two :
1. The core part, including the changed functions, like [Patch 4/8], 
[Patch 8/8].
2. For the formatting issues, like [Patch 1/8],[Patch 3/8],  including 
the changes for code formations, creation of new files 
intel-iommu-kdump.c, intel-iommu-private.h.

I believe this will make the patch set more clear to read and understand.

What are your suggestions?

Thanks
Zhenhua


On 07/12/2014 12:27 AM, Jerry Hoemann wrote:
> On Wed, Jul 02, 2014 at 03:32:59PM +0200, Joerg Roedel wrote:
>> 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
>
> David, Joerg,
>
> What do you think here?  Do you want me to update the patch set for 3.17?
>
> Jerry
>


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

WARNING: multiple messages have this Message-ID (diff)
From: "Li, ZhenHua" <zhen-hual-VXdhtT5mjnY@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
	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,
	ishii.hironobu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
	bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
	zhenhua-VXdhtT5mjnY@public.gmane.org
Subject: Re: [PATCH 0/8] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Date: Wed, 15 Oct 2014 16:10:02 +0800	[thread overview]
Message-ID: <543E2BDA.8030906@hp.com> (raw)
In-Reply-To: <20140711162745.GA8335-dMAi7lA+vBPDUbYHzcRnttBPR1lH4CV8@public.gmane.org>

David, Joerg,
I plan to merge this patch set with 3.17 stable kernel, and split this 
patch set into two :
1. The core part, including the changed functions, like [Patch 4/8], 
[Patch 8/8].
2. For the formatting issues, like [Patch 1/8],[Patch 3/8],  including 
the changes for code formations, creation of new files 
intel-iommu-kdump.c, intel-iommu-private.h.

I believe this will make the patch set more clear to read and understand.

What are your suggestions?

Thanks
Zhenhua


On 07/12/2014 12:27 AM, Jerry Hoemann wrote:
> On Wed, Jul 02, 2014 at 03:32:59PM +0200, Joerg Roedel wrote:
>> 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
>
> David, Joerg,
>
> What do you think here?  Do you want me to update the patch set for 3.17?
>
> Jerry
>

WARNING: multiple messages have this Message-ID (diff)
From: "Li, ZhenHua" <zhen-hual@hp.com>
To: Joerg Roedel <joro@8bytes.org>, David Woodhouse <dwmw2@infradead.org>
Cc: 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,
	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, 15 Oct 2014 16:10:02 +0800	[thread overview]
Message-ID: <543E2BDA.8030906@hp.com> (raw)
In-Reply-To: <20140711162745.GA8335@anatevka.fc.hp.com>

David, Joerg,
I plan to merge this patch set with 3.17 stable kernel, and split this 
patch set into two :
1. The core part, including the changed functions, like [Patch 4/8], 
[Patch 8/8].
2. For the formatting issues, like [Patch 1/8],[Patch 3/8],  including 
the changes for code formations, creation of new files 
intel-iommu-kdump.c, intel-iommu-private.h.

I believe this will make the patch set more clear to read and understand.

What are your suggestions?

Thanks
Zhenhua


On 07/12/2014 12:27 AM, Jerry Hoemann wrote:
> On Wed, Jul 02, 2014 at 03:32:59PM +0200, Joerg Roedel wrote:
>> 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
>
> David, Joerg,
>
> What do you think here?  Do you want me to update the patch set for 3.17?
>
> Jerry
>


  reply	other threads:[~2014-10-15  8:10 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
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 [this message]
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=543E2BDA.8030906@hp.com \
    --to=zhen-hual@hp.com \
    --cc=Jerry.Hoemann@hp.com \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=dwmw2@infradead.org \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=ishii.hironobu@jp.fujitsu.com \
    --cc=joro@8bytes.org \
    --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.