From: Joerg Roedel <joro@8bytes.org>
To: Dave Young <dyoung@redhat.com>
Cc: "Li, Zhen-Hua" <zhen-hual@hp.com>,
dwmw2@infradead.org, indou.takao@jp.fujitsu.com, bhe@redhat.com,
vgoyal@redhat.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
kexec@lists.infradead.org, alex.williamson@redhat.com,
ddutile@redhat.com, ishii.hironobu@jp.fujitsu.com,
bhelgaas@google.com, doug.hatch@hp.com, jerry.hoemann@hp.com,
tom.vaden@hp.com, li.zhang6@hp.com, lisa.mitchell@hp.com,
billsumnerlinux@gmail.com, rwright@hp.com
Subject: Re: [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
Date: Mon, 4 May 2015 13:05:51 +0200 [thread overview]
Message-ID: <20150504110551.GD15736@8bytes.org> (raw)
In-Reply-To: <20150403084031.GF22579@dhcp-128-53.nay.redhat.com>
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
> Have not read all the patches, but I have a question, not sure this
> has been answered before. Old memory is not reliable, what if the old
> memory get corrupted before panic? Is it safe to continue using it in
> 2nd kernel, I worry that it will cause problems.
Yes, the old memory could be corrupted, and there are more failure cases
left which we have no way of handling yet (if iommu data structures are
in kdump backup areas).
The question is what to do if we find some of the old data structures
corrupted, hand how far should the tests go. Should we also check the
page-tables, for example? I think if some of the data structures for a
device are corrupted it probably already failed in the old kernel and
things won't get worse in the new one.
So checking is not strictly necessary in the first version of these
patches (unless we find a valid failure scenario). Once we have some
good plan on what to do if we find corruption, we can add checking of
course.
Regards,
Joerg
next prev parent reply other threads:[~2015-05-04 11:06 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 5:36 [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 01/10] iommu/vt-d: New function to attach domain with id Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 02/10] iommu/vt-d: Items required for kdump Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 03/10] iommu/vt-d: Function to get old context entry Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 04/10] iommu/vt-d: functions to copy data from old mem Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 05/10] iommu/vt-d: Add functions to load and save old re Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 06/10] iommu/vt-d: datatypes and functions used for kdump Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 07/10] iommu/vt-d: enable kdump support in iommu module Li, Zhen-Hua
2015-04-02 11:06 ` Joerg Roedel
2015-04-03 7:45 ` Li, ZhenHua
2015-03-19 5:36 ` [PATCH v9 08/10] iommu/vt-d: assign new page table for dma_map Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 09/10] iommu/vt-d: Copy functions for irte Li, Zhen-Hua
2015-03-19 5:36 ` [PATCH v9 10/10] iommu/vt-d: Use old irte in kdump kernel Li, Zhen-Hua
2015-04-02 11:11 ` [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults " Joerg Roedel
2015-04-03 7:54 ` Li, ZhenHua
2015-04-03 8:28 ` Dave Young
2015-04-03 8:31 ` Li, ZhenHua
2015-04-03 8:40 ` Dave Young
2015-04-03 9:01 ` Li, ZhenHua
2015-04-03 9:21 ` Dave Young
2015-04-03 14:05 ` Li, Zhen-Hua
2015-04-07 3:49 ` Dave Young
2015-04-05 1:54 ` Baoquan He
2015-04-07 3:46 ` Dave Young
2015-04-07 9:08 ` Dave Young
2015-04-07 9:55 ` Li, ZhenHua
2015-04-08 3:33 ` Dave Young
2015-04-07 14:12 ` Don Dutile
2015-05-07 14:00 ` Dave Young
2015-05-07 14:25 ` Don Dutile
2015-05-08 1:21 ` Dave Young
2015-05-10 21:37 ` Don Dutile
2015-05-10 21:31 ` Don Dutile
2015-05-04 11:05 ` Joerg Roedel [this message]
2015-05-04 15:21 ` Don Dutile
2015-05-05 6:09 ` Dave Young
2015-05-05 15:23 ` Joerg Roedel
2015-05-06 1:46 ` Dave Young
2015-05-06 8:16 ` Joerg Roedel
2015-05-07 13:25 ` Dave Young
2015-05-07 13:56 ` Dave Young
2015-05-11 10:11 ` Joerg Roedel
2015-05-12 5:57 ` Dave Young
2015-05-12 6:41 ` Dave Young
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=20150504110551.GD15736@8bytes.org \
--to=joro@8bytes.org \
--cc=alex.williamson@redhat.com \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=billsumnerlinux@gmail.com \
--cc=ddutile@redhat.com \
--cc=doug.hatch@hp.com \
--cc=dwmw2@infradead.org \
--cc=dyoung@redhat.com \
--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=li.zhang6@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lisa.mitchell@hp.com \
--cc=rwright@hp.com \
--cc=tom.vaden@hp.com \
--cc=vgoyal@redhat.com \
--cc=zhen-hual@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 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).