From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oded Gabbay Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init Date: Sun, 21 Dec 2014 13:34:36 +0200 Message-ID: <5496B04C.50502@amd.com> References: <1419108374-7020-1-git-send-email-oded.gabbay@amd.com> <1419108374-7020-2-git-send-email-oded.gabbay@amd.com> <5496AEAD.3090003@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) by gabe.freedesktop.org (Postfix) with ESMTP id 0F0526E261 for ; Sun, 21 Dec 2014 03:34:59 -0800 (PST) In-Reply-To: <5496AEAD.3090003@vodafone.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , dri-devel@lists.freedesktop.org Cc: Alexander.Deucher@amd.com, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org CgpPbiAxMi8yMS8yMDE0IDAxOjI3IFBNLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+IEFtIDIw LjEyLjIwMTQgdW0gMjE6NDYgc2NocmllYiBPZGVkIEdhYmJheToKPj4gV2hlbiBhbWRrZmQgYW5k IHJhZGVvbiBhcmUgY29tcGlsZWQgaW5zaWRlIHRoZSBrZXJuZWwgaW1hZ2UgKG5vdCBhcyBtb2R1 bGVzKSwKPj4gcmFkZW9uIHdpbGwgbG9hZCBiZWZvcmUgYW1ka2ZkIGFuZCB3aWxsIHNldCAqa2Zk MmtnZCB0byBpdHMgaW50ZXJmYWNlCj4+IHN0cnVjdHVyZS4gVGhlcmVmb3JlLCB3ZSBtdXN0IG5v dCBzZXQgKmtmZDJrZ2QgdG8gTlVMTCB3aGVuIGFtZGtmZCBpcyBsb2FkZWQKPj4gYmVjYXVzZSBp dCB3aWxsIG92ZXJyaWRlIHJhZGVvbidzIGluaXRpYWxpemF0aW9uIGFuZCBjYXVzZSBrZXJuZWwg QlVHLgo+Pgo+PiBTaWduZWQtb2ZmLWJ5OiBPZGVkIEdhYmJheSA8b2RlZC5nYWJiYXlAYW1kLmNv bT4KPgo+IFlvdSBzaG91bGQgcHJvYmFibHkgcmF0aGVyIGZpeCB0aGUgZGVwZW5kZW5jeSBiZXR3 ZWVuIHRoZSB0d28gbW9kdWxlcyB0byBnZXQgYW4KPiBkZXRlcm1pbmVkIGxvYWQgb3JkZXIgaW5z dGVhZCBvZiBkb2luZyBzdWNoIG5hc3R5IHdvcmthcm91bmRzLgo+Cj4gQ2hyaXN0aWFuLgoKVGhl IHByb2JsZW0gaXMgdGhhdCB3aGVuIG1vZHVsZXMgYXJlIGNvbXBpbGVkIGluc2lkZSB0aGUga2Vy bmVsLCB0aGVyZSBpcyBOTyAKZGV0ZXJtaW5lZCBsb2FkIG9yZGVyIGFuZCB0aGVyZSBpcyBubyBt ZWNoYW5pc20gdG8gZW5mb3JjZSB0aGF0LiBJZiB0aGVyZSBpcy93YXMgCnN1Y2ggYSBtZWNoYW5p c20sIEkgd291bGQgb2YgY291cnNlIHByZWZlciB0byB1c2UgaXQuCgpBY3R1YWxseSwgSSBkb24n dCB1bmRlcnN0YW5kIHdoeSB0aGUga2VybmVsIGRvZXNuJ3QgZW5mb3JjZSB0aGUgb3JkZXIgYWNj b3JkaW5nIAp0byB0aGUgdXNlIG9mIGV4cG9ydGVkIHN5bWJvbHMsIGxpa2UgaXQgZG9lcyB3aXRo IG1vZHVsZXMuCgpUaGVyZSB3aWxsIGFsd2F5cyBiZSBkZXBlbmRlbmNpZXMgYmV0d2VlbiBrZ2Qg KHJhZGVvbikgYW5kIGFtZGtmZCBhbmQgYmV0d2VlbiAKYW1ka2ZkIGFuZCBhbWRfaW9tbXVfdjIu IEkgZG9uJ3QgdGhpbmsgSSBjYW4gZWxpbWluYXRlIHRob3NlIGRlcGVuZGVuY2llcywgbm90IAp3 aXRob3V0IGEgdmVyeSBjb21wbGV4IHNvbHV0aW9uLiBBbmQgdGhlIGZhY3QgdGhhdCB0aGlzIGNv bXBsZXggc29sdXRpb24gb2NjdXJzIApvbmx5IGluIGEgdmVyeSBzcGVjaWZpYyB1c2UgY2FzZSAo YWxsIG1vZHVsZXMgY29tcGlsZWQgaW4pLCBtYWtlcyBtZSBsZXNzIAppbmNsaW5lZCB0byBkbyB0 aGF0LgoKU28gSSBkb24ndCBzZWUgaXQgYXMgYSAibmFzdHkgd29ya2Fyb3VuZCIuIEkgd291bGQg Y2FsbCBpdCBqdXN0IGEgIndvcmthcm91bmQiIApmb3IgYSBzcGVjaWZpYyB1c2UgY2FzZSwgd2hp Y2ggc2hvdWxkIGJlIHNvbHZlZCBieSBhIGdlbmVyaWMgc29sdXRpb24gdG8gdGhlIAprZXJuZWwg ZW5mb3JjaW5nIGxvYWQgb3JkZXJzLgoKCU9kZWQKPgo+PiAtLS0KPj4gICBkcml2ZXJzL2dwdS9k cm0vYW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMgfCA1ICsrLS0tCj4+ICAgMSBmaWxlIGNoYW5nZWQs IDIgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKPj4KPj4gZGlmZiAtLWdpdCBhL2RyaXZl cnMvZ3B1L2RybS9hbWQvYW1ka2ZkL2tmZF9tb2R1bGUuYwo+PiBiL2RyaXZlcnMvZ3B1L2RybS9h bWQvYW1ka2ZkL2tmZF9tb2R1bGUuYwo+PiBpbmRleCA5NWQ1YWYxLi4yMzY1NjJmIDEwMDY0NAo+ PiAtLS0gYS9kcml2ZXJzL2dwdS9kcm0vYW1kL2FtZGtmZC9rZmRfbW9kdWxlLmMKPj4gKysrIGIv ZHJpdmVycy9ncHUvZHJtL2FtZC9hbWRrZmQva2ZkX21vZHVsZS5jCj4+IEBAIC0zNCw3ICszNCw3 IEBACj4+ICAgI2RlZmluZSBLRkRfRFJJVkVSX01JTk9SICAgIDcKPj4gICAjZGVmaW5lIEtGRF9E UklWRVJfUEFUQ0hMRVZFTCAgICAwCj4+IC1jb25zdCBzdHJ1Y3Qga2ZkMmtnZF9jYWxscyAqa2Zk MmtnZDsKPj4gK2NvbnN0IHN0cnVjdCBrZmQya2dkX2NhbGxzICprZmQya2dkID0gTlVMTDsKPj4g ICBzdGF0aWMgY29uc3Qgc3RydWN0IGtnZDJrZmRfY2FsbHMga2dkMmtmZCA9IHsKPj4gICAgICAg LmV4aXQgICAgICAgID0ga2dkMmtmZF9leGl0LAo+PiAgICAgICAucHJvYmUgICAgICAgID0ga2dk MmtmZF9wcm9iZSwKPj4gQEAgLTg0LDE0ICs4NCwxMyBAQCBFWFBPUlRfU1lNQk9MKGtnZDJrZmRf aW5pdCk7Cj4+ICAgdm9pZCBrZ2Qya2ZkX2V4aXQodm9pZCkKPj4gICB7Cj4+ICsgICAga2ZkMmtn ZCA9IE5VTEw7Cj4+ICAgfQo+PiAgIHN0YXRpYyBpbnQgX19pbml0IGtmZF9tb2R1bGVfaW5pdCh2 b2lkKQo+PiAgIHsKPj4gICAgICAgaW50IGVycjsKPj4gLSAgICBrZmQya2dkID0gTlVMTDsKPj4g LQo+PiAgICAgICAvKiBWZXJpZnkgbW9kdWxlIHBhcmFtZXRlcnMgKi8KPj4gICAgICAgaWYgKChz Y2hlZF9wb2xpY3kgPCBLRkRfU0NIRURfUE9MSUNZX0hXUykgfHwKPj4gICAgICAgICAgIChzY2hl ZF9wb2xpY3kgPiBLRkRfU0NIRURfUE9MSUNZX05PX0hXUykpIHsKPgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRy aS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753517AbaLULfE (ORCPT ); Sun, 21 Dec 2014 06:35:04 -0500 Received: from mail-bn1on0148.outbound.protection.outlook.com ([157.56.110.148]:62656 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751298AbaLULfA convert rfc822-to-8bit (ORCPT ); Sun, 21 Dec 2014 06:35:00 -0500 X-WSS-ID: 0NGXK65-07-939-02 X-M-MSG: Message-ID: <5496B04C.50502@amd.com> Date: Sun, 21 Dec 2014 13:34:36 +0200 From: Oded Gabbay Organization: AMD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , CC: , Subject: Re: [PATCH 1/3] amdkfd: Don't clear *kfd2kgd on kfd_module_init References: <1419108374-7020-1-git-send-email-oded.gabbay@amd.com> <1419108374-7020-2-git-send-email-oded.gabbay@amd.com> <5496AEAD.3090003@vodafone.de> In-Reply-To: <5496AEAD.3090003@vodafone.de> Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [10.20.0.84] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 Authentication-Results: spf=none (sender IP is 165.204.84.221) smtp.mailfrom=Oded.Gabbay@amd.com; X-Forefront-Antispam-Report: CIP:165.204.84.221;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(428002)(479174004)(24454002)(199003)(377454003)(189002)(51704005)(106466001)(2950100001)(54356999)(68736005)(65956001)(107046002)(65816999)(21056001)(50466002)(77096005)(50986999)(76176999)(33656002)(87936001)(105586002)(120916001)(19580395003)(101416001)(64126003)(84676001)(47776003)(20776003)(64706001)(46102003)(31966008)(4396001)(65806001)(19580405001)(99396003)(23676002)(77156002)(36756003)(92566001)(83506001)(62966003)(97736003)(86362001)(2101003);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0201MB0997;H:atltwp01.amd.com;FPR:;SPF:None;MLV:sfv;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB0997; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:BY1PR0201MB0997; X-Forefront-PRVS: 0432A04947 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB0997; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Dec 2014 11:34:54.9731 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.221] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB0997 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB0949; X-OriginatorOrg: amd4.onmicrosoft.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > 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)) { >