From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4616069258483944073==" MIME-Version: 1.0 From: Christian König To: lkp@lists.01.org Subject: Re: [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel Date: Thu, 25 Dec 2014 13:31:10 +0100 Message-ID: <549C038E.1030206@vodafone.de> In-Reply-To: <54986EA2.106@amd.com> List-Id: --===============4616069258483944073== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Am 22.12.2014 um 20:18 schrieb Oded Gabbay: > > 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 w= rote: >>>>> 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 m= odules and >>>>> random kernel base, the symbol_request function doesn't work as expec= ted - It >>>>> doesn't return NULL if the symbol doesn't exists. That makes the kern= el panic. >>>>> Therefore, the as amdkfd doesn't compile in 32-bit kernel, the best w= ay 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 try= ing > to load a driver which can't be compiled in 32bit. Well in this case couldn't we make the code in radeon depend on whether = or not the KFD driver is compiled in or not instead of checking the = system architecture? Regards, Christian. > >>> 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 ro= ot > cause, I would be more than happy. > > Oded >>> +rusty. >> And also with correct email. >> >> -Andi >> > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============4616069258483944073==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: [LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel Date: Thu, 25 Dec 2014 13:31:10 +0100 Message-ID: <549C038E.1030206@vodafone.de> References: <1419246673-7222-1-git-send-email-oded.gabbay@amd.com> <20141222184940.GB17192@tassilo.jf.intel.com> <20141222190041.GC17192@tassilo.jf.intel.com> <54986EA2.106@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id BB3CA6E075 for ; Thu, 25 Dec 2014 04:31:47 -0800 (PST) In-Reply-To: <54986EA2.106@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Oded Gabbay , 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 QW0gMjIuMTIuMjAxNCB1bSAyMDoxOCBzY2hyaWViIE9kZWQgR2FiYmF5Ogo+Cj4gT24gMTIvMjIv MjAxNCAwOTowMCBQTSwgQW5kaSBLbGVlbiB3cm90ZToKPj4gT24gTW9uLCBEZWMgMjIsIDIwMTQg YXQgMTA6NDk6NDBBTSAtMDgwMCwgQW5kaSBLbGVlbiB3cm90ZToKPj4+IE9uIE1vbiwgRGVjIDIy LCAyMDE0IGF0IDExOjU4OjQzQU0gLTA1MDAsIEFsZXggRGV1Y2hlciB3cm90ZToKPj4+PiBPbiBN b24sIERlYyAyMiwgMjAxNCBhdCA2OjExIEFNLCBPZGVkIEdhYmJheSA8b2RlZC5nYWJiYXlAYW1k LmNvbT4gd3JvdGU6Cj4+Pj4+IGFtZGtmZCBkcml2ZXIgY2FuIGJlIGNvbXBpbGVkIG9ubHkgaW4g NjQtYml0IGtlcm5lbC4gVGhlcmVmb3JlLCB0aGVyZSBpcyBubwo+Pj4+PiBwb2ludCBpbiB0cnlp bmcgdG8gaW5pdGlhbGl6ZSBhbWRrZmQgaW4gMzItYml0IGtlcm5lbC4KPj4+Pj4KPj4+Pj4gSW4g YWRkaXRpb24sIGluIGNhc2Ugb2Ygc3BlY2lmaWMgY29uZmlndXJhdGlvbiBvZiAzMi1iaXQga2Vy bmVsLCBubyBtb2R1bGVzIGFuZAo+Pj4+PiByYW5kb20ga2VybmVsIGJhc2UsIHRoZSBzeW1ib2xf cmVxdWVzdCBmdW5jdGlvbiBkb2Vzbid0IHdvcmsgYXMgZXhwZWN0ZWQgLSBJdAo+Pj4+PiBkb2Vz bid0IHJldHVybiBOVUxMIGlmIHRoZSBzeW1ib2wgZG9lc24ndCBleGlzdHMuIFRoYXQgbWFrZXMg dGhlIGtlcm5lbCBwYW5pYy4KPj4+Pj4gVGhlcmVmb3JlLCB0aGUgYXMgYW1ka2ZkIGRvZXNuJ3Qg Y29tcGlsZSBpbiAzMi1iaXQga2VybmVsLCB0aGUgYmVzdCB3YXkgaXMganVzdAo+Pj4+PiB0byBy ZXR1cm4gZmFsc2UgaW1tZWRpYXRlbHkuCj4+Pj4+Cj4+Pj4+IFNpZ25lZC1vZmYtYnk6IE9kZWQg R2FiYmF5IDxvZGVkLmdhYmJheUBhbWQuY29tPgo+Pj4+IFJldmlld2VkLWJ5OiBBbGV4IERldWNo ZXIgPGFsZXhhbmRlci5kZXVjaGVyQGFtZC5jb20+Cj4+PiBTb3JyeSBidXQgdGhlIHBhdGNoIGlz IGp1c3QgYm9ndXMuIFgtYml0IG9ubHkgY29kZSBpcyB1c3VhbGx5Cj4+PiBhIHZlcnkgYmFkIHNp Z24gZm9yIHRoZSBjb2RlLiBUaGlzIGlzIG5vdCB3aW5kb3dzIHByb2dyYW1pbmcgYWZ0ZXIgYWxs Lgo+IEhpIEFuZGksCj4KPiBTdHJhbmdlLCBJIGhhdmUgbmV2ZXIgcHJvZ3JhbW1lZCBmb3IgV2lu ZG93cyBpbiBteSBsaWZlIChleGNlcHQgbWF5YmUgaW4gYQo+IGZldyBjb3Vyc2VzIGR1cmluZyBt eSBkZWdyZWUpIDopCj4+PiBFdmVuIGlmIHlvdSB3YW50ZWQgdG8gZG8gYSA2NGJpdCBvbmx5IGRy aXZlciAtLSB3aGljaAo+Pj4geW91IHByb2JhYmx5IGRvbid0IC0tIHRoZSBzdGFuZGFyZCB3YXkg d291bGQgYmUgdG8gZXhjbHVkZQo+Pj4gaXQgaW4gS2NvbmZpZy4KPiBTbyBhbWRrZmQgYWN0dWFs bHkgKm9ubHkqIHN1cHBvcnRzIDY0Yml0IHVzZXIgcHJvY2Vzc2VzLCBiZWNhdXNlIEFNRCdzIEhT QQo+IHN0YWNrIG9uIExpbnV4IHN1cHBvcnRzICpvbmx5KiA2NGJpdCB1c2VyIHByb2Nlc3Nlcy4g U28sIHllcywgSSBkZWZpbml0ZWx5Cj4gd2FudCB0byBkbyBhIDY0Yml0IG9ubHkgZHJpdmVyLgo+ IElmIHlvdSBsb29rIGF0IGtmZF9vcGVuKCksIGl0IGZhaWxzIHRoZSBvcGVuIG9mIC9kZXYva2Zk IGlmIHRoZSBwcm9jZXNzIGlzCj4gMzJiaXQuCj4gSW4gYWRkaXRpb24sIGluIEtjb25maWcgb2Yg YW1ka2ZkLCBpdCBpcyB3cml0dGVuOgo+ICJkZXBlbmRzIG9uIERSTV9SQURFT04gJiYgQU1EX0lP TU1VX1YyICYmIFg4Nl82NCIKPgo+IFRoZSBwcm9ibGVtIGhlcmUgaXMgdGhhdCB0aGVyZSBpcyBj b2RlIGluIHJhZGVvbiwgd2hpY2ggaXMgYSBkcml2ZXIgdGhhdCBjYW4KPiBjb21waWxlIGluIDMy Yml0LCB3aGljaCB0cmllcyB0byBsb2FkIGFtZGtmZC4gSSBkaWRuJ3Qgc2VlIGEgcG9pbnQgaW4g dHJ5aW5nCj4gdG8gbG9hZCBhIGRyaXZlciB3aGljaCBjYW4ndCBiZSBjb21waWxlZCBpbiAzMmJp dC4KCldlbGwgaW4gdGhpcyBjYXNlIGNvdWxkbid0IHdlIG1ha2UgdGhlIGNvZGUgaW4gcmFkZW9u IGRlcGVuZCBvbiB3aGV0aGVyIApvciBub3QgdGhlIEtGRCBkcml2ZXIgaXMgY29tcGlsZWQgaW4g b3Igbm90IGluc3RlYWQgb2YgY2hlY2tpbmcgdGhlIApzeXN0ZW0gYXJjaGl0ZWN0dXJlPwoKUmVn YXJkcywKQ2hyaXN0aWFuLgoKPgo+Pj4gUGxlYXNlIHJvb3QtY2F1c2Ugd2h5IHN5bWJvbF9yZXF1 ZXN0IGRvZXNuJ3Qgd29yayBvbiAzMmJpdAo+Pj4gYW5kIGZpeCBpdCBwcm9wZXJseS4KPiBJIGRp ZG4ndCBzYXkgaXQgZG9lc24ndCBhbHdheXMgd29yay4KPiBUaGUgYWN0dWFsIHRoaW5nIHRoYXQg ZG9lc24ndCB3b3JrIGlzIHRoZSBkZWZpbmUgc3ltYm9sX2dldCBhbmQgb25seSBpbiBhCj4gc3Bl Y2lmaWMgY2FzZSBvZiAzMmJpdCBrZXJuZWwgQU5EIENPTkZJR19NT0RVTEVTIGlzIHVuc2V0IEFO RAo+IENPTkZJR19SQU5ET01JWkVfQkFTRSBpcyBzZXQuCj4gVGhlIGRlZmluZSBpbiB0aGF0IGNh c2UgaXM6Cj4gI2RlZmluZSBzeW1ib2xfZ2V0KHgpICh7IGV4dGVybiB0eXBlb2YoeCkgeCBfX2F0 dHJpYnV0ZV9fKCh3ZWFrKSk7ICYoeCk7IH0pCj4KPiBXaHkgaXQgZG9lc24ndCB3b3JrIChkb2Vz bid0IHJldHVybiBOVUxMIHdoZW4gc3ltYm9sIGRvZXNuJ3QgZXhpc3RzKSA/Cj4gSSBkb24ndCBr bm93LCBwcm9iYWJseSBiZWNhdXNlIG9mIHNvbWUgZWxmL21ha2VmaWxlL2MgbGFuZ3VhZ2UgbWFn aWMuIEknbQo+IG5vdCB0aGF0IGJpZyBvZiBhbiBleHBlcnQgb24gdGhvc2UgaXNzdWVzLCBhbmQg SSB3YW50ZWQgdG8gcHJvdmlkZSBhIGZpeCBmb3IKPiB0aGlzIHByb2JsZW0gZHVyaW5nIHRoZSAt cmMgc3RhZ2VzLiBJZiBzb21lb25lIGNhbiBoZWxwIG1lIHNvbHZpbmcgdGhlIHJvb3QKPiBjYXVz ZSwgSSB3b3VsZCBiZSBtb3JlIHRoYW4gaGFwcHkuCj4KPiAJT2RlZAo+Pj4gK3J1c3R5Lgo+PiBB bmQgYWxzbyB3aXRoIGNvcnJlY3QgZW1haWwuCj4+Cj4+IC1BbmRpCj4+Cj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBkcmktZGV2ZWwgbWFpbGluZyBs aXN0Cj4gZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwo+IGh0dHA6Ly9saXN0cy5mcmVl ZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752506AbaLYMbt (ORCPT ); Thu, 25 Dec 2014 07:31:49 -0500 Received: from pegasos-out.vodafone.de ([80.84.1.38]:54182 "EHLO pegasos-out.vodafone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752034AbaLYMbs (ORCPT ); Thu, 25 Dec 2014 07:31:48 -0500 X-Spam-Flag: NO X-Spam-Score: 0.157 Authentication-Results: rohrpostix2.prod.vfnet.de (amavisd-new); dkim=softfail (invalid, public key: DNS query timeout for mail._domainkey.vodafone.de) header.i=@vodafone.de X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de F342423 Message-ID: <549C038E.1030206@vodafone.de> Date: Thu, 25 Dec 2014 13:31:10 +0100 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Oded Gabbay , Andi Kleen , Alex Deucher CC: Dana Elifaz , rusty@rustcorp.com.au, 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> <54986EA2.106@amd.com> In-Reply-To: <54986EA2.106@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 22.12.2014 um 20:18 schrieb Oded Gabbay: > > 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. Well in this case couldn't we make the code in radeon depend on whether or not the KFD driver is compiled in or not instead of checking the system architecture? Regards, Christian. > >>> 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 >> > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel