linux-kernel - Re: [RFC] [Patch] calgary iommu: Use the first kernel's tce tables in kdump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080313154919.GE7114@il.ibm.com>
Date:	Thu, 13 Mar 2008 17:49:19 +0200
From:	Muli Ben-Yehuda <muli@...ibm.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Chandru <chandru@...ibm.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, jdmason@...zu.us
Subject: Re: [RFC] [Patch] calgary iommu: Use the first kernel's tce tables
	in kdump

On Wed, Mar 12, 2008 at 02:08:06PM -0400, Vivek Goyal wrote:

> Agree. Ignoring all the DMA errors in kdump kernel does not sound
> very good.
> 
> On a side note, typically how much time does it take to for DMA
> operations to finish. Can we wait for a random amount of time in
> second kernel, hoping all the DMA operations are complete, and then
> setup a new table?
> 
> This can be atleast a stop gap solution till we come up with a good
> solution?

The problem as I understand it is that when we boot into the kdump
kernel we have left-over devices from the old kernel which are active
and initiating DMA's. This is fine as long as Calgayr is also active
(with the old kernel's mappings). Once we initialize Calgary (in the
kdump) kernel with the new mappings, however, it starts trapping all
those DMA's. We can't wait for them to stop, because that will only
happen when the device is re-initialized (or otherwise quiesced).

Cheers,
Muli
--
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/