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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 22 Dec 2014 17:40:04 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Oded Gabbay <oded.gabbay@....com>
Cc:	Christian König <deathsimple@...afone.de>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"Deucher, Alexander" <Alexander.Deucher@....com>,
	"Elifaz, Dana" <Dana.Elifaz@....com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init

>>>>> There should be, but when the modules are compiled in, they are loaded
>>>>> based on
>>>>> link order only, if they are in the same group, and the groups are
>>>>> loaded by a
>>>>> pre-defined order.
>>>>
>>>> Is that really still up to date? I've seen effort to change that
>>>> something like
>>>> 10+ years ago when Rusty reworked the module system. And it is comming
>>>> up on the
>>>> lists again from time to time.
>>>
>>> From what I can see in the Makefile rules, code and google, yes, that's
>>> still
>>> the situation. If someone will prove me wrong I will be more than happy
>>> to
>>> correct my code.
>>>>
>>>>
>>>>> I don't want to move iommu before gpu, so I don't have a solution for
>>>>> the
>>>>> order between amdkfd and amd_iommu_v2.
>>>>
>>>> Why not? That's still better than creating a kernel workqueue,
>>>> scheduling one
>>>> work item on it, rescheduling the task until everything is completed and
>>>> you can
>>>> continue.
>>>
>>> Because I don't know the consequences of moving an entire subsystem in
>>> front
>>> of another one. In addition, even if everyone agrees, I'm pretty sure
>>> that
>>> Linus won't be happy to do that in -rc stages. So maybe this is something
>>> to
>>> consider for 3.20 merge window, but I would still like to provide a
>>> solution
>>> for 3.19.
>>
>>
>> Yeah, true indeed. How about depending on everything being compiled as
>> module
>> for 3.19 then? Still better than having such a hack in the driver for as a
>> temporary workaround for one release.
>>
> I thought about it, but because this problem was originally reported by a
> user that told us he couldn't use modules because of his setup, I decided
> not to.
> I assume there are other users out there who needs this option (compiled
> everything in the kernel - embedded ?), so I don't want to make their life
> harder.
>
> In addition, saying it is a workaround for one release is true in case
> moving iommu subsystem in front of gpu subsystem is acceptable and doesn't
> cause other problems, unknown at this point.
>
> Bottom line, my personal preference is to help the users _now_ and if a
> better fix is found in the future, change the code accordingly.

My guess is moving the iommu subsystem in front of the GPU would be rational.

It does seem like it would generally have a depend in that order.

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