[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150511101124.GG20611@8bytes.org>
Date: Mon, 11 May 2015 12:11:24 +0200
From: Joerg Roedel <joro@...tes.org>
To: Dave Young <dyoung@...hat.com>
Cc: "Li, Zhen-Hua" <zhen-hual@...com>, dwmw2@...radead.org,
indou.takao@...fujitsu.com, bhe@...hat.com, vgoyal@...hat.com,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
alex.williamson@...hat.com, ddutile@...hat.com,
ishii.hironobu@...fujitsu.com, bhelgaas@...gle.com,
doug.hatch@...com, jerry.hoemann@...com, tom.vaden@...com,
li.zhang6@...com, lisa.mitchell@...com, billsumnerlinux@...il.com,
rwright@...com
Subject: Re: [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
> Joreg, I can not find the last reply from you, so just reply here about
> my worries here.
>
> I said that the patchset will cause more problems, let me explain about
> it more here:
>
> Suppose page table was corrupted, ie. original mapping iova1 -> page 1
> it was changed to iova1 -> page 2 accidently while crash happening,
> thus future dma will read/write page 2 instead page 1, right?
When the page-table is corrupted then it is a left-over from the old
kernel. When the kdump kernel boots the situation can at least not get
worse. For the page tables it is also hard to detect wrong mappings (if
this would be possible the hardware could already do it), so any checks
we could do there are of limited use anyway.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists