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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160302145823.GV22747@8bytes.org>
Date:	Wed, 2 Mar 2016 15:58:23 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Xunlei Pang <xlpang@...hat.com>
Cc:	linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
	Baoquan He <bhe@...hat.com>, ZhenHua Li <zhen-hual@...com>
Subject: Re: [PATCH] iommu/vt-d: Assign old irt entries a common valid vector
 in kdump kernel

On Wed, Mar 02, 2016 at 06:02:28PM +0800, Xunlei Pang wrote:
> Currently, the kernel copies the old irt entries during iommu
> initialization for kdump, so old vectors in the first kernel are
> used but having no related kernel irq handlers set explicitly,
> this can lead to some problems after lapics are enabled:
>  - When some in-flight dma finished and triggered an interrupt,
>    the kernel will throw a warning message in do_IRQ() like "No
>    irq handler", because handle_irq() will return false with no
>    irq_desc handlers. This may confuse users.
>  - When the in-flight dma interrupt arrives, and if there happens
>    to be an irq with the same vector allocated in kdump kernel,
>    it will invoke the existing ISR registered in kdump kernel as
>    if one valid interrupt in the kdump kernel happens. This might
>    cause some wrong software logic, for example if the ISR always
>    wakes up a process.

Hmm, the current situation with misdirected irq messages in the kdump
kernel is not different from a situation without any iommu at all,
right?

And the goal of preserving the old mappings is to get as close as
possible to the situation without iommu. This seems to carry the VT-d
driver away from that.


	Joerg

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ