linux-kernel - [PATCH 0/3] Use workqueue for device init in amdkfd

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: <1419108374-7020-1-git-send-email-oded.gabbay@amd.com>
Date:	Sat, 20 Dec 2014 22:46:11 +0200
From:	Oded Gabbay <oded.gabbay@....com>
To:	<dri-devel@...ts.freedesktop.org>
CC:	David Airlie <airlied@...ux.ie>,
	Jerome Glisse <j.glisse@...il.com>,
	Joerg Roedel <joro@...tes.org>, <linux-kernel@...r.kernel.org>,
	"John Bridgman" <John.Bridgman@....com>,
	<Alexander.Deucher@....com>
Subject: [PATCH 0/3] Use workqueue for device init in amdkfd

This small patch-set, together with amd_iommu_v2 patch at 
http://lists.linuxfoundation.org/pipermail/iommu/2014-December/011435.html 
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).

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 problem, amdkfd now checks if both it and amd_iommu_v2 
were loaded before trying to initalize the device. If not, it enqueue 
the work using a workqueue, which allows radeon to continue its device 
initialization (because radeon calls amdkfd to initalize the device).
The work function schedules itself as long as amdkfd and amd_iommu_v2 
were not initialized.

Detection of when the modules finished their initialization is done by 
a simple variable that is initialized to 1 when the module_init function 
is completed successfully. Other methods for detection were checked, 
e.g. module_is_live() and MODULE_SOFTDEP(), but they were proved not 
to work when all modules are compiled in the kernel image (which is 
the problematic scenario to begin with).

	Oded

Oded Gabbay (3):
  amdkfd: Don't clear *kfd2kgd on kfd_module_init
  amdkfd: Track when amdkfd init is complete
  amdkfd: Use workqueue for GPU init

 drivers/gpu/drm/amd/amdkfd/kfd_device.c | 72 +++++++++++++++++++++++++++++++--
 drivers/gpu/drm/amd/amdkfd/kfd_module.c | 14 +++++--
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h   |  4 ++
 3 files changed, 83 insertions(+), 7 deletions(-)

-- 
2.1.0

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