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]
Date:	Thu, 25 Dec 2014 14:20:59 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Oded Gabbay <oded.gabbay@....com>
Cc:	David Airlie <airlied@...ux.ie>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Dana Elifaz <Dana.Elifaz@....com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Alexander Deucher <Alexander.Deucher@....com>,
	iommu@...ts.linux-foundation.org,
	Christian König <christian.koenig@....com>,
	Arnd Bergmann <arnd@...db.de>,
	Will Deacon <will.deacon@....com>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH 0/2] Change order of linkage in kernel makefiles for
 amdkfd

On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote:
> 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.

I strongly object to this patch set. This makes assumptions about how
the build system influences probe order. That's bad because seemingly
unrelated changes could easily break this in the future.

We already have ways to solve this kind of dependency (driver probe
deferral), and I think you should be using it to solve this particular
problem rather than some linking order hack.

Coincidentally there's a separate thread currently going on that deals
with IOMMUs and probe order. The solution being worked on is currently
somewhat ARM-specific, so adding a couple of folks for visibility. It
looks like we're going to need something more generic since this is a
problem that even the "big" architectures need to solve.

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ