Re: iommu/vt-d: Use per-cpu IOVA caching, suspend-to-ram causes machine hang

Re: iommu/vt-d: Use per-cpu IOVA caching, suspend-to-ram causes machine hang

[Adam Morrison]

> Hi Omer the following commit introduced a regression when doing
> suspend-to-ram. The machine never wakes up. We have more than
> a few machines that hang: SNB-i7-2620m, IVB-3370, HSW-4470r, BDW-5600u,
> BDW-525u.

Jan Niehusmann posted a patch that fixes a similar problem:

    http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1158159.html

Can you please try it and see if it does the trick for you?

Thanks,
Adam

Re: iommu/vt-d: Use per-cpu IOVA caching, suspend-to-ram causes machine hang

[Marius Vlad]

[-- Attachment #1.1: Type: text/plain, Size: 563 bytes --]

Yes, that does it. Thanks.

On Mon, Jun 06, 2016 at 12:02:30AM +0300, Adam Morrison wrote:
> > Hi Omer the following commit introduced a regression when doing
> > suspend-to-ram. The machine never wakes up. We have more than
> > a few machines that hang: SNB-i7-2620m, IVB-3370, HSW-4470r, BDW-5600u,
> > BDW-525u.
> 
> Jan Niehusmann posted a patch that fixes a similar problem:
> 
>     http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1158159.html
> 
> Can you please try it and see if it does the trick for you?
> 
> Thanks,
> Adam

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2] iommu/vt-d: fix overflow of iommu->domains array

[Jan Niehusmann]

The valid range of 'did' in get_iommu_domain(*iommu, did)
is 0..cap_ndoms(iommu->cap), so don't exceed that
range in free_all_cpu_cached_iovas().

The user-visible impact of the out-of-bounds access is the machine
hanging on suspend-to-ram. It is, in fact, a kernel panic, but due
to already suspended devices, that's often not visible to the user.

Fixes: 22e2f9fa63b0 ("iommu/vt-d: Use per-cpu IOVA caching")
Signed-off-by: Jan Niehusmann <jan@gondor.com>
Tested-By: Marius Vlad <marius.c.vlad@intel.com>
---
Added some details and Tested-By to the commit message. Patch is unchanged.

Posted to intel-gfx@lists.freedesktop.org and iommu@lists.linux-foundation.org
where the issue was discussed.

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a644d0c..82989d4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4600,7 +4600,7 @@ static void free_all_cpu_cached_iovas(unsigned int cpu)
 		if (!iommu)
 			continue;
 
-		for (did = 0; did < 0xffff; did++) {
+		for (did = 0; did < cap_ndoms(iommu->cap); did++) {
 			domain = get_iommu_domain(iommu, did);
 
 			if (!domain)
-- 
2.1.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2] iommu/vt-d: fix overflow of iommu->domains array

[Joerg Roedel]

On Mon, Jun 06, 2016 at 02:20:11PM +0200, Jan Niehusmann wrote:
> The valid range of 'did' in get_iommu_domain(*iommu, did)
> is 0..cap_ndoms(iommu->cap), so don't exceed that
> range in free_all_cpu_cached_iovas().
> 
> The user-visible impact of the out-of-bounds access is the machine
> hanging on suspend-to-ram. It is, in fact, a kernel panic, but due
> to already suspended devices, that's often not visible to the user.
> 
> Fixes: 22e2f9fa63b0 ("iommu/vt-d: Use per-cpu IOVA caching")
> Signed-off-by: Jan Niehusmann <jan@gondor.com>
> Tested-By: Marius Vlad <marius.c.vlad@intel.com>

Queued to iommu/fixes branch, thanks Jan.



	Joerg

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx