From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0500221482144744585==" MIME-Version: 1.0 From: Oded Gabbay To: lkp@lists.01.org Subject: Re: [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel Date: Mon, 22 Dec 2014 21:18:58 +0200 Message-ID: <54986EA2.106@amd.com> In-Reply-To: <20141222190041.GC17192@tassilo.jf.intel.com> List-Id: --===============0500221482144744585== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 12/22/2014 09:00 PM, Andi Kleen wrote: > On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote: >> On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote: >>> On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wr= ote: >>>> amdkfd driver can be compiled only in 64-bit kernel. Therefore, there = is no >>>> point in trying to initialize amdkfd in 32-bit kernel. >>>> >>>> In addition, in case of specific configuration of 32-bit kernel, no mo= dules and >>>> random kernel base, the symbol_request function doesn't work as expect= ed - It >>>> doesn't return NULL if the symbol doesn't exists. That makes the kerne= l panic. >>>> Therefore, the as amdkfd doesn't compile in 32-bit kernel, the best wa= y is just >>>> to return false immediately. >>>> >>>> Signed-off-by: Oded Gabbay >>> >>> Reviewed-by: Alex Deucher >> >> Sorry but the patch is just bogus. X-bit only code is usually >> a very bad sign for the code. This is not windows programing after all. Hi Andi, Strange, I have never programmed for Windows in my life (except maybe in a few courses during my degree) :) >> >> Even if you wanted to do a 64bit only driver -- which >> you probably don't -- the standard way would be to exclude >> it in Kconfig. So amdkfd actually *only* supports 64bit user processes, because AMD's HSA stack on Linux supports *only* 64bit user processes. So, yes, I definitely want to do a 64bit only driver. If you look at kfd_open(), it fails the open of /dev/kfd if the process is 32bit. In addition, in Kconfig of amdkfd, it is written: "depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64" The problem here is that there is code in radeon, which is a driver that can compile in 32bit, which tries to load amdkfd. I didn't see a point in trying to load a driver which can't be compiled in 32bit. >> >> Please root-cause why symbol_request doesn't work on 32bit >> and fix it properly. I didn't say it doesn't always work. The actual thing that doesn't work is the define symbol_get and only in a specific case of 32bit kernel AND CONFIG_MODULES is unset AND CONFIG_RANDOMIZE_BASE is set. The define in that case is: #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); }) Why it doesn't work (doesn't return NULL when symbol doesn't exists) ? I don't know, probably because of some elf/makefile/c language magic. I'm not that big of an expert on those issues, and I wanted to provide a fix for this problem during the -rc stages. If someone can help me solving the root cause, I would be more than happy. Oded >> >> +rusty. > = > And also with correct email. > = > -Andi >=20 --===============0500221482144744585==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oded Gabbay Subject: Re: [LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel Date: Mon, 22 Dec 2014 21:18:58 +0200 Message-ID: <54986EA2.106@amd.com> References: <1419246673-7222-1-git-send-email-oded.gabbay@amd.com> <20141222184940.GB17192@tassilo.jf.intel.com> <20141222190041.GC17192@tassilo.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) by gabe.freedesktop.org (Postfix) with ESMTP id 1A9216E3B5 for ; Mon, 22 Dec 2014 11:19:08 -0800 (PST) In-Reply-To: <20141222190041.GC17192@tassilo.jf.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Andi Kleen , Alex Deucher Cc: Dana Elifaz , rusty@rustcorp.com.au, LKML , Maling list - DRI developers , Alexander Deucher , LKP ML List-Id: dri-devel@lists.freedesktop.org CgpPbiAxMi8yMi8yMDE0IDA5OjAwIFBNLCBBbmRpIEtsZWVuIHdyb3RlOgo+IE9uIE1vbiwgRGVj IDIyLCAyMDE0IGF0IDEwOjQ5OjQwQU0gLTA4MDAsIEFuZGkgS2xlZW4gd3JvdGU6Cj4+IE9uIE1v biwgRGVjIDIyLCAyMDE0IGF0IDExOjU4OjQzQU0gLTA1MDAsIEFsZXggRGV1Y2hlciB3cm90ZToK Pj4+IE9uIE1vbiwgRGVjIDIyLCAyMDE0IGF0IDY6MTEgQU0sIE9kZWQgR2FiYmF5IDxvZGVkLmdh YmJheUBhbWQuY29tPiB3cm90ZToKPj4+PiBhbWRrZmQgZHJpdmVyIGNhbiBiZSBjb21waWxlZCBv bmx5IGluIDY0LWJpdCBrZXJuZWwuIFRoZXJlZm9yZSwgdGhlcmUgaXMgbm8KPj4+PiBwb2ludCBp biB0cnlpbmcgdG8gaW5pdGlhbGl6ZSBhbWRrZmQgaW4gMzItYml0IGtlcm5lbC4KPj4+Pgo+Pj4+ IEluIGFkZGl0aW9uLCBpbiBjYXNlIG9mIHNwZWNpZmljIGNvbmZpZ3VyYXRpb24gb2YgMzItYml0 IGtlcm5lbCwgbm8gbW9kdWxlcyBhbmQKPj4+PiByYW5kb20ga2VybmVsIGJhc2UsIHRoZSBzeW1i b2xfcmVxdWVzdCBmdW5jdGlvbiBkb2Vzbid0IHdvcmsgYXMgZXhwZWN0ZWQgLSBJdAo+Pj4+IGRv ZXNuJ3QgcmV0dXJuIE5VTEwgaWYgdGhlIHN5bWJvbCBkb2Vzbid0IGV4aXN0cy4gVGhhdCBtYWtl cyB0aGUga2VybmVsIHBhbmljLgo+Pj4+IFRoZXJlZm9yZSwgdGhlIGFzIGFtZGtmZCBkb2Vzbid0 IGNvbXBpbGUgaW4gMzItYml0IGtlcm5lbCwgdGhlIGJlc3Qgd2F5IGlzIGp1c3QKPj4+PiB0byBy ZXR1cm4gZmFsc2UgaW1tZWRpYXRlbHkuCj4+Pj4KPj4+PiBTaWduZWQtb2ZmLWJ5OiBPZGVkIEdh YmJheSA8b2RlZC5nYWJiYXlAYW1kLmNvbT4KPj4+Cj4+PiBSZXZpZXdlZC1ieTogQWxleCBEZXVj aGVyIDxhbGV4YW5kZXIuZGV1Y2hlckBhbWQuY29tPgo+Pgo+PiBTb3JyeSBidXQgdGhlIHBhdGNo IGlzIGp1c3QgYm9ndXMuIFgtYml0IG9ubHkgY29kZSBpcyB1c3VhbGx5Cj4+IGEgdmVyeSBiYWQg c2lnbiBmb3IgdGhlIGNvZGUuIFRoaXMgaXMgbm90IHdpbmRvd3MgcHJvZ3JhbWluZyBhZnRlciBh bGwuCkhpIEFuZGksCgpTdHJhbmdlLCBJIGhhdmUgbmV2ZXIgcHJvZ3JhbW1lZCBmb3IgV2luZG93 cyBpbiBteSBsaWZlIChleGNlcHQgbWF5YmUgaW4gYQpmZXcgY291cnNlcyBkdXJpbmcgbXkgZGVn cmVlKSA6KQo+Pgo+PiBFdmVuIGlmIHlvdSB3YW50ZWQgdG8gZG8gYSA2NGJpdCBvbmx5IGRyaXZl ciAtLSB3aGljaAo+PiB5b3UgcHJvYmFibHkgZG9uJ3QgLS0gdGhlIHN0YW5kYXJkIHdheSB3b3Vs ZCBiZSB0byBleGNsdWRlCj4+IGl0IGluIEtjb25maWcuClNvIGFtZGtmZCBhY3R1YWxseSAqb25s eSogc3VwcG9ydHMgNjRiaXQgdXNlciBwcm9jZXNzZXMsIGJlY2F1c2UgQU1EJ3MgSFNBCnN0YWNr IG9uIExpbnV4IHN1cHBvcnRzICpvbmx5KiA2NGJpdCB1c2VyIHByb2Nlc3Nlcy4gU28sIHllcywg SSBkZWZpbml0ZWx5CndhbnQgdG8gZG8gYSA2NGJpdCBvbmx5IGRyaXZlci4KSWYgeW91IGxvb2sg YXQga2ZkX29wZW4oKSwgaXQgZmFpbHMgdGhlIG9wZW4gb2YgL2Rldi9rZmQgaWYgdGhlIHByb2Nl c3MgaXMKMzJiaXQuCkluIGFkZGl0aW9uLCBpbiBLY29uZmlnIG9mIGFtZGtmZCwgaXQgaXMgd3Jp dHRlbjoKImRlcGVuZHMgb24gRFJNX1JBREVPTiAmJiBBTURfSU9NTVVfVjIgJiYgWDg2XzY0IgoK VGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRoZXJlIGlzIGNvZGUgaW4gcmFkZW9uLCB3aGljaCBp cyBhIGRyaXZlciB0aGF0IGNhbgpjb21waWxlIGluIDMyYml0LCB3aGljaCB0cmllcyB0byBsb2Fk IGFtZGtmZC4gSSBkaWRuJ3Qgc2VlIGEgcG9pbnQgaW4gdHJ5aW5nCnRvIGxvYWQgYSBkcml2ZXIg d2hpY2ggY2FuJ3QgYmUgY29tcGlsZWQgaW4gMzJiaXQuCgo+Pgo+PiBQbGVhc2Ugcm9vdC1jYXVz ZSB3aHkgc3ltYm9sX3JlcXVlc3QgZG9lc24ndCB3b3JrIG9uIDMyYml0Cj4+IGFuZCBmaXggaXQg cHJvcGVybHkuCkkgZGlkbid0IHNheSBpdCBkb2Vzbid0IGFsd2F5cyB3b3JrLgpUaGUgYWN0dWFs IHRoaW5nIHRoYXQgZG9lc24ndCB3b3JrIGlzIHRoZSBkZWZpbmUgc3ltYm9sX2dldCBhbmQgb25s eSBpbiBhCnNwZWNpZmljIGNhc2Ugb2YgMzJiaXQga2VybmVsIEFORCBDT05GSUdfTU9EVUxFUyBp cyB1bnNldCBBTkQKQ09ORklHX1JBTkRPTUlaRV9CQVNFIGlzIHNldC4KVGhlIGRlZmluZSBpbiB0 aGF0IGNhc2UgaXM6CiNkZWZpbmUgc3ltYm9sX2dldCh4KSAoeyBleHRlcm4gdHlwZW9mKHgpIHgg X19hdHRyaWJ1dGVfXygod2VhaykpOyAmKHgpOyB9KQoKV2h5IGl0IGRvZXNuJ3Qgd29yayAoZG9l c24ndCByZXR1cm4gTlVMTCB3aGVuIHN5bWJvbCBkb2Vzbid0IGV4aXN0cykgPwpJIGRvbid0IGtu b3csIHByb2JhYmx5IGJlY2F1c2Ugb2Ygc29tZSBlbGYvbWFrZWZpbGUvYyBsYW5ndWFnZSBtYWdp Yy4gSSdtCm5vdCB0aGF0IGJpZyBvZiBhbiBleHBlcnQgb24gdGhvc2UgaXNzdWVzLCBhbmQgSSB3 YW50ZWQgdG8gcHJvdmlkZSBhIGZpeCBmb3IKdGhpcyBwcm9ibGVtIGR1cmluZyB0aGUgLXJjIHN0 YWdlcy4gSWYgc29tZW9uZSBjYW4gaGVscCBtZSBzb2x2aW5nIHRoZSByb290CmNhdXNlLCBJIHdv dWxkIGJlIG1vcmUgdGhhbiBoYXBweS4KCglPZGVkCj4+Cj4+ICtydXN0eS4KPiAKPiBBbmQgYWxz byB3aXRoIGNvcnJlY3QgZW1haWwuCj4gCj4gLUFuZGkKPiAKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2 ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932099AbaLVTTP (ORCPT ); Mon, 22 Dec 2014 14:19:15 -0500 Received: from mail-bl2on0135.outbound.protection.outlook.com ([65.55.169.135]:23168 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754442AbaLVTTN (ORCPT ); Mon, 22 Dec 2014 14:19:13 -0500 X-WSS-ID: 0NH00BR-07-YWN-02 X-M-MSG: Message-ID: <54986EA2.106@amd.com> Date: Mon, 22 Dec 2014 21:18:58 +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: Andi Kleen , Alex Deucher CC: , Dana Elifaz , LKML , Maling list - DRI developers , Alexander Deucher , LKP ML Subject: Re: [LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel References: <1419246673-7222-1-git-send-email-oded.gabbay@amd.com> <20141222184940.GB17192@tassilo.jf.intel.com> <20141222190041.GC17192@tassilo.jf.intel.com> In-Reply-To: <20141222190041.GC17192@tassilo.jf.intel.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.224.8.146] 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)(51704005)(24454002)(377454003)(189002)(479174004)(199003)(99396003)(50986999)(76176999)(21056001)(87936001)(65806001)(65956001)(19580395003)(19580405001)(36756003)(23746002)(50466002)(64126003)(64706001)(84676001)(83506001)(31966008)(105586002)(120916001)(54356999)(20776003)(77156002)(47776003)(62966003)(65816999)(4396001)(97736003)(93886004)(107046002)(106466001)(46102003)(2950100001)(33656002)(86362001)(68736005)(77096005)(101416001)(92566001);DIR:OUT;SFP:1102;SCL:1;SRVR:CO1PR02MB206;H:atltwp01.amd.com;FPR:;SPF:None;MLV:sfv;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB206; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:CO1PR02MB206; X-Forefront-PRVS: 0433DB2766 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB206; X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Dec 2014 19:19:05.5706 (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: CO1PR02MB206 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/22/2014 09:00 PM, Andi Kleen wrote: > On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote: >> On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote: >>> On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote: >>>> amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is no >>>> point in trying to initialize amdkfd in 32-bit kernel. >>>> >>>> In addition, in case of specific configuration of 32-bit kernel, no modules and >>>> random kernel base, the symbol_request function doesn't work as expected - It >>>> doesn't return NULL if the symbol doesn't exists. That makes the kernel panic. >>>> Therefore, the as amdkfd doesn't compile in 32-bit kernel, the best way is just >>>> to return false immediately. >>>> >>>> Signed-off-by: Oded Gabbay >>> >>> Reviewed-by: Alex Deucher >> >> Sorry but the patch is just bogus. X-bit only code is usually >> a very bad sign for the code. This is not windows programing after all. Hi Andi, Strange, I have never programmed for Windows in my life (except maybe in a few courses during my degree) :) >> >> Even if you wanted to do a 64bit only driver -- which >> you probably don't -- the standard way would be to exclude >> it in Kconfig. So amdkfd actually *only* supports 64bit user processes, because AMD's HSA stack on Linux supports *only* 64bit user processes. So, yes, I definitely want to do a 64bit only driver. If you look at kfd_open(), it fails the open of /dev/kfd if the process is 32bit. In addition, in Kconfig of amdkfd, it is written: "depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64" The problem here is that there is code in radeon, which is a driver that can compile in 32bit, which tries to load amdkfd. I didn't see a point in trying to load a driver which can't be compiled in 32bit. >> >> Please root-cause why symbol_request doesn't work on 32bit >> and fix it properly. I didn't say it doesn't always work. The actual thing that doesn't work is the define symbol_get and only in a specific case of 32bit kernel AND CONFIG_MODULES is unset AND CONFIG_RANDOMIZE_BASE is set. The define in that case is: #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); }) Why it doesn't work (doesn't return NULL when symbol doesn't exists) ? I don't know, probably because of some elf/makefile/c language magic. I'm not that big of an expert on those issues, and I wanted to provide a fix for this problem during the -rc stages. If someone can help me solving the root cause, I would be more than happy. Oded >> >> +rusty. > > And also with correct email. > > -Andi >