All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: lkp@lists.01.org
Subject: Re: [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
Date: Mon, 05 Jan 2015 14:58:54 +1030	[thread overview]
Message-ID: <87r3v96ebd.fsf@rustcorp.com.au> (raw)
In-Reply-To: <549A85DE.1040006@amd.com>

[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]

Oded Gabbay <oded.gabbay@amd.com> writes:
> On 12/24/2014 01:01 AM, Rusty Russell wrote:
>> Oded Gabbay <oded.gabbay@amd.com> writes:
>>> 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) ?
>>
>> Hmm, I'd guess CONFIG_RANDOMIZE_BASE is relocating NULL symbols...
>>
>> No, I can't reproduce this.  Please send your .config privately.
>>
>> Here's my test case:
>>
>> diff --git a/init/main.c b/init/main.c
>> index 61b993767db5..a3ee1ec97ec3 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>>
>>   	ftrace_init();
>>
>> +	{
>> +		extern void nonexistent_fn(void);
>> +		printk("symbol_get(nonexistent_fn) = %p\n",
>> +		       symbol_get(nonexistent_fn));
>> +	}
>> +
>>   	/* Do the rest non-__init'ed, we're now alive */
>>   	rest_init();
>>   }
>>
>> Thanks,
>> Rusty.
>>
> Hi Rusty,
>
> Attached is the bad config file. (config-bad)
> I have narrowed the changes you need to do to the config file in order to 
> reproduce this bug.
> The base assumption is a 32-bit kernel and without modules support. Rest of the 
> config file is pretty standard, IMO.
> Then, its not enough to enable CONFIG_RANDOMIZE_BASE like I wrote in my original 
> post. You need also to unset CONFIG_HIBERNATION.

Indeed, thanks; your config breaks as reported.  With CONFIG_HIBERNATION
the kernel offset is 0, so we don't see this.

Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
section for weak symbols.  These should not be relocated if already 0.

Put this somewhere to test.  It fails for x86_64, too:

diff --git a/init/main.c b/init/main.c
index 61b993767db5..c9e0195c792a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
 
 	ftrace_init();
 
+	{
+		extern void __attribute__((weak)) nonexistent_fn(void);
+		printk("nonexistent_fn = %p\n", nonexistent_fn);
+		BUG_ON(nonexistent_fn != NULL);
+	}
+
 	/* Do the rest non-__init'ed, we're now alive */
 	rest_init();
 }

Cheers,
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Oded Gabbay <oded.gabbay@amd.com>,
	Andi Kleen <ak@linux.intel.com>,
	Alex Deucher <alexdeucher@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Dana Elifaz <Dana.Elifaz@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Alexander Deucher <Alexander.Deucher@amd.com>,
	LKP ML <lkp@01.org>
Subject: Re: [LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
Date: Mon, 05 Jan 2015 14:58:54 +1030	[thread overview]
Message-ID: <87r3v96ebd.fsf@rustcorp.com.au> (raw)
In-Reply-To: <549A85DE.1040006@amd.com>

Oded Gabbay <oded.gabbay@amd.com> writes:
> On 12/24/2014 01:01 AM, Rusty Russell wrote:
>> Oded Gabbay <oded.gabbay@amd.com> writes:
>>> 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) ?
>>
>> Hmm, I'd guess CONFIG_RANDOMIZE_BASE is relocating NULL symbols...
>>
>> No, I can't reproduce this.  Please send your .config privately.
>>
>> Here's my test case:
>>
>> diff --git a/init/main.c b/init/main.c
>> index 61b993767db5..a3ee1ec97ec3 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>>
>>   	ftrace_init();
>>
>> +	{
>> +		extern void nonexistent_fn(void);
>> +		printk("symbol_get(nonexistent_fn) = %p\n",
>> +		       symbol_get(nonexistent_fn));
>> +	}
>> +
>>   	/* Do the rest non-__init'ed, we're now alive */
>>   	rest_init();
>>   }
>>
>> Thanks,
>> Rusty.
>>
> Hi Rusty,
>
> Attached is the bad config file. (config-bad)
> I have narrowed the changes you need to do to the config file in order to 
> reproduce this bug.
> The base assumption is a 32-bit kernel and without modules support. Rest of the 
> config file is pretty standard, IMO.
> Then, its not enough to enable CONFIG_RANDOMIZE_BASE like I wrote in my original 
> post. You need also to unset CONFIG_HIBERNATION.

Indeed, thanks; your config breaks as reported.  With CONFIG_HIBERNATION
the kernel offset is 0, so we don't see this.

Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
section for weak symbols.  These should not be relocated if already 0.

Put this somewhere to test.  It fails for x86_64, too:

diff --git a/init/main.c b/init/main.c
index 61b993767db5..c9e0195c792a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
 
 	ftrace_init();
 
+	{
+		extern void __attribute__((weak)) nonexistent_fn(void);
+		printk("nonexistent_fn = %p\n", nonexistent_fn);
+		BUG_ON(nonexistent_fn != NULL);
+	}
+
 	/* Do the rest non-__init'ed, we're now alive */
 	rest_init();
 }

Cheers,
Rusty.

  reply	other threads:[~2015-01-05  4:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22 11:11 [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel Oded Gabbay
2014-12-22 11:11 ` Oded Gabbay
2014-12-22 11:11 ` Oded Gabbay
2014-12-22 16:58 ` Alex Deucher
2014-12-22 16:58   ` Alex Deucher
2014-12-22 16:58   ` Alex Deucher
2014-12-22 18:49   ` Andi Kleen
2014-12-22 18:49     ` [LKP] " Andi Kleen
2014-12-22 19:00     ` Andi Kleen
2014-12-22 19:00       ` [LKP] " Andi Kleen
2014-12-22 19:18       ` Oded Gabbay
2014-12-22 19:18         ` [LKP] " Oded Gabbay
2014-12-22 19:18         ` Oded Gabbay
2014-12-23 23:01         ` Rusty Russell
2014-12-23 23:01           ` [LKP] " Rusty Russell
2014-12-24  9:16           ` Oded Gabbay
2014-12-24  9:22           ` Oded Gabbay
2014-12-24  9:22             ` [LKP] " Oded Gabbay
2015-01-05  4:28             ` Rusty Russell [this message]
2015-01-05  4:28               ` Rusty Russell
2015-01-06 20:14               ` Kees Cook
2015-01-06 20:14                 ` [LKP] " Kees Cook
2015-01-06 22:58                 ` Rusty Russell
2015-01-06 22:58                   ` [LKP] " Rusty Russell
2015-01-11 11:57                   ` Oded Gabbay
2015-01-11 11:57                     ` [LKP] " Oded Gabbay
2015-01-11 11:57                     ` Oded Gabbay
2015-01-13 17:15                   ` Kees Cook
2015-01-13 17:15                     ` [LKP] " Kees Cook
2015-01-16  0:27               ` Kees Cook
2015-01-16  0:27                 ` [LKP] " Kees Cook
2015-01-16 11:27                 ` Oded Gabbay
2015-01-16 11:27                   ` [LKP] " Oded Gabbay
2015-01-16 11:27                   ` Oded Gabbay
2015-01-23  4:10                 ` Rusty Russell
2015-01-23  4:10                   ` [LKP] " Rusty Russell
2014-12-25 12:31         ` Christian König
2014-12-25 12:31           ` [LKP] " Christian König
2014-12-25 12:31           ` Christian König
2014-12-28  9:05           ` Oded Gabbay
2014-12-28  9:05             ` [LKP] " Oded Gabbay
2014-12-28  9:05             ` Oded Gabbay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r3v96ebd.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=lkp@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.