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-next>] [day] [month] [year] [list]
Message-ID: <1419246435-7050-1-git-send-email-oded.gabbay@amd.com>
Date:	Mon, 22 Dec 2014 13:07:13 +0200
From:	Oded Gabbay <oded.gabbay@....com>
To:	David Airlie <airlied@...ux.ie>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	<dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
	<iommu@...ts.linux-foundation.org>, Joerg Roedel <joro@...tes.org>,
	"Jerome Glisse" <j.glisse@...il.com>,
	John Bridgman <John.Bridgman@....com>,
	Alexander Deucher <Alexander.Deucher@....com>,
	Christian König <christian.koenig@....com>,
	Dana Elifaz <Dana.Elifaz@....com>,
	Geert Uytterhoeven <geert+renesas@...der.be>
Subject: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

This small patch-set, was created to solve the bug described at 
https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when 
trying use amdkfd driver on Kaveri). It replaces the previous patch-set called 
[PATCH 0/3] Use workqueue for device init in amdkfd
(http://lists.freedesktop.org/archives/dri-devel/2014-December/074401.html)

That bug appears only when radeon, amdkfd and amd_iommu_v2 are compiled 
inside the kernel (not as modules). In that case, the correct loading 
order, as determined by the exported symbol used by each driver, is 
not enforced anymore and the kernel loads them based on who was linked 
first. That makes radeon load first, amdkfd second and amd_iommu_v2 
third.

Because the initialization of a device in amdkfd is initiated by radeon, 
and can only be completed if amdkfd and amd_iommu_v2 were loaded and 
initialized, then in the case mentioned above, this initalization fails 
and there is a kernel panic as some pointers are not initialized but 
used nontheless.

To solve this bug, this patch-set moves iommu/ before gpu/ in drivers/Makefile 
and also moves amdkfd/ before radeon/ in drivers/gpu/drm/Makefile.

The rationale is that in general, AMD GPU devices are dependent on AMD IOMMU 
controller functionality to allow the GPU to access a process's virtual memory 
address space, without the need for pinning the memory. That's why it makes 
sense to initialize the iommu/ subsystem ahead of the gpu/ subsystem.

	Oded

Oded Gabbay (2):
  drivers: Move iommu/ before gpu/ in Makefile
  drm: Put amdkfd before radeon in drm Makefile

 drivers/Makefile         | 6 ++++--
 drivers/gpu/drm/Makefile | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
1.9.1

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ