linux-kernel - Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 21 Dec 2014 13:34:36 +0200
From:	Oded Gabbay <oded.gabbay@....com>
To:	Christian König <deathsimple@...afone.de>,
	<dri-devel@...ts.freedesktop.org>
CC:	<linux-kernel@...r.kernel.org>, <Alexander.Deucher@....com>
Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init



On 12/21/2014 01:27 PM, Christian König wrote:
> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>> When amdkfd and radeon are compiled inside the kernel image (not as modules),
>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded
>> because it will override radeon's initialization and cause kernel BUG.
>>
>> Signed-off-by: Oded Gabbay <oded.gabbay@....com>
>
> You should probably rather fix the dependency between the two modules to get an
> determined load order instead of doing such nasty workarounds.
>
> Christian.

The problem is that when modules are compiled inside the kernel, there is NO 
determined load order and there is no mechanism to enforce that. If there is/was 
such a mechanism, I would of course prefer to use it.

Actually, I don't understand why the kernel doesn't enforce the order according 
to the use of exported symbols, like it does with modules.

There will always be dependencies between kgd (radeon) and amdkfd and between 
amdkfd and amd_iommu_v2. I don't think I can eliminate those dependencies, not 
without a very complex solution. And the fact that this complex solution occurs 
only in a very specific use case (all modules compiled in), makes me less 
inclined to do that.

So I don't see it as a "nasty workaround". I would call it just a "workaround" 
for a specific use case, which should be solved by a generic solution to the 
kernel enforcing load orders.

	Oded
>
>> ---
>>   drivers/gpu/drm/amd/amdkfd/kfd_module.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> index 95d5af1..236562f 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> @@ -34,7 +34,7 @@
>>   #define KFD_DRIVER_MINOR    7
>>   #define KFD_DRIVER_PATCHLEVEL    0
>> -const struct kfd2kgd_calls *kfd2kgd;
>> +const struct kfd2kgd_calls *kfd2kgd = NULL;
>>   static const struct kgd2kfd_calls kgd2kfd = {
>>       .exit        = kgd2kfd_exit,
>>       .probe        = kgd2kfd_probe,
>> @@ -84,14 +84,13 @@ EXPORT_SYMBOL(kgd2kfd_init);
>>   void kgd2kfd_exit(void)
>>   {
>> +    kfd2kgd = NULL;
>>   }
>>   static int __init kfd_module_init(void)
>>   {
>>       int err;
>> -    kfd2kgd = NULL;
>> -
>>       /* Verify module parameters */
>>       if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
>>           (sched_policy > KFD_SCHED_POLICY_NO_HWS)) {
>
--
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/