Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1296853 > unrolled thread

[PATCH] x86/ucode: replace redundant string literals

Back to article view | Back to linux.kernel

Contents

  [PATCH] x86/ucode: replace redundant string literals "Jan Beulich" <JBeulich@suse.com> - 2015-12-22 16:50 +0100
    Re: [PATCH] x86/ucode: replace redundant string literals Borislav Petkov <bp@suse.de> - 2015-12-22 18:10 +0100
      Re: [PATCH] x86/ucode: replace redundant string literals "Jan Beulich" <JBeulich@suse.com> - 2015-12-22 18:30 +0100
        Re: [PATCH] x86/ucode: replace redundant string literals Borislav Petkov <bp@suse.de> - 2015-12-22 19:20 +0100
          Re: [PATCH] x86/ucode: replace redundant string literals "Jan Beulich" <jbeulich@suse.com> - 2015-12-23 11:10 +0100
            Re: [PATCH] x86/ucode: replace redundant string literals Borislav Petkov <bp@suse.de> - 2015-12-23 11:20 +0100
              Re: [PATCH] x86/ucode: replace redundant string literals "Jan Beulich" <jbeulich@suse.com> - 2015-12-23 11:20 +0100

#1296853 — [PATCH] x86/ucode: replace redundant string literals

This doesn't just eliminate needless redundancy (plus avoid a possible
disconnect if one string instance gets changed without the other(s)),
but also eliminates a warning some gcc versions emit ("array access
beyond array bounds", observed with 4.3.4) in the 32-bit case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 arch/x86/kernel/cpu/microcode/core.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

--- 4.4-rc6/arch/x86/kernel/cpu/microcode/core.c
+++ 4.4-rc6-x86-ucode-early-string/arch/x86/kernel/cpu/microcode/core.c
@@ -83,13 +83,11 @@ static bool __init check_loader_disabled
 {
 #ifdef CONFIG_X86_32
 	const char *cmdline = (const char *)__pa_nodebug(boot_command_line);
-	const char *opt	    = "dis_ucode_ldr";
-	const char *option  = (const char *)__pa_nodebug(opt);
+	const char *option  = (const char *)__pa_nodebug(__setup_str_disable_loader);
 	bool *res = (bool *)__pa_nodebug(&dis_ucode_ldr);
-
 #else /* CONFIG_X86_64 */
 	const char *cmdline = boot_command_line;
-	const char *option  = "dis_ucode_ldr";
+	const char *option  = __setup_str_disable_loader;
 	bool *res = &dis_ucode_ldr;
 #endif
 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1296908

On Tue, Dec 22, 2015 at 08:40:43AM -0700, Jan Beulich wrote:
> This doesn't just eliminate needless redundancy
> (plus avoid a possible disconnect if one string instance gets changed
> without the other(s)),

This argument is bogus. We will never ever change a user-visible command
line option. Ever.

> but also eliminates a warning some gcc versions emit ("array access
> beyond array bounds", observed with 4.3.4) in the 32-bit case.

Now that I'm interested in - how exactly do you trigger this? gcc
version, etc?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
>  arch/x86/kernel/cpu/microcode/core.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> --- 4.4-rc6/arch/x86/kernel/cpu/microcode/core.c
> +++ 4.4-rc6-x86-ucode-early-string/arch/x86/kernel/cpu/microcode/core.c
> @@ -83,13 +83,11 @@ static bool __init check_loader_disabled
>  {
>  #ifdef CONFIG_X86_32
>  	const char *cmdline = (const char *)__pa_nodebug(boot_command_line);
> -	const char *opt	    = "dis_ucode_ldr";
> -	const char *option  = (const char *)__pa_nodebug(opt);
> +	const char *option  = (const char *)__pa_nodebug(__setup_str_disable_loader);
>  	bool *res = (bool *)__pa_nodebug(&dis_ucode_ldr);
> -
>  #else /* CONFIG_X86_64 */
>  	const char *cmdline = boot_command_line;
> -	const char *option  = "dis_ucode_ldr";
> +	const char *option  = __setup_str_disable_loader;
>  	bool *res = &dis_ucode_ldr;
>  #endif

I don't like it: it is not clear at a glance that this __setup_str*
magic gets generated from the __setup macro. In addition, this code is
as unreadable as it is now - your patch makes it even more cryptic.

I much prefer the redundancy.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296917

>>> On 22.12.15 at 18:07, <bp@suse.de> wrote:
> On Tue, Dec 22, 2015 at 08:40:43AM -0700, Jan Beulich wrote:
>> This doesn't just eliminate needless redundancy
>> (plus avoid a possible disconnect if one string instance gets changed
>> without the other(s)),
> 
> This argument is bogus. We will never ever change a user-visible command
> line option. Ever.
> 
>> but also eliminates a warning some gcc versions emit ("array access
>> beyond array bounds", observed with 4.3.4) in the 32-bit case.
> 
> Now that I'm interested in - how exactly do you trigger this? gcc
> version, etc?

As said - 4.3.4 (I only now realize that this could also have been a
kernel version).

>> --- 4.4-rc6/arch/x86/kernel/cpu/microcode/core.c
>> +++ 4.4-rc6-x86-ucode-early-string/arch/x86/kernel/cpu/microcode/core.c
>> @@ -83,13 +83,11 @@ static bool __init check_loader_disabled
>>  {
>>  #ifdef CONFIG_X86_32
>>  	const char *cmdline = (const char *)__pa_nodebug(boot_command_line);
>> -	const char *opt	    = "dis_ucode_ldr";
>> -	const char *option  = (const char *)__pa_nodebug(opt);
>> +	const char *option  = (const char *)__pa_nodebug(__setup_str_disable_loader);
>>  	bool *res = (bool *)__pa_nodebug(&dis_ucode_ldr);
>> -
>>  #else /* CONFIG_X86_64 */
>>  	const char *cmdline = boot_command_line;
>> -	const char *option  = "dis_ucode_ldr";
>> +	const char *option  = __setup_str_disable_loader;
>>  	bool *res = &dis_ucode_ldr;
>>  #endif
> 
> I don't like it: it is not clear at a glance that this __setup_str*
> magic gets generated from the __setup macro. In addition, this code is
> as unreadable as it is now - your patch makes it even more cryptic.
> 
> I much prefer the redundancy.

And the compiler warning? At the very least these should then be
const char __initconst [].

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296958

On Tue, Dec 22, 2015 at 10:20:36AM -0700, Jan Beulich wrote:
> As said - 4.3.4 (I only now realize that this could also have been a
> kernel version).

Just fetched stable from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable

$ git tag --list | grep v4.3
v4.3
v4.3-rc1
v4.3-rc2
v4.3-rc3
v4.3-rc4
v4.3-rc5
v4.3-rc6
v4.3-rc7
v4.3.1
v4.3.2
v4.3.3

I don't see a v4.3.4 tag yet...

> And the compiler warning? At the very least these should then be
> const char __initconst [].

Let's sort out the issue first - this is the first time I hear of this
warning.

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297310

>>> Borislav Petkov <bp@suse.de> 12/22/15 7:14 PM >>>
>On Tue, Dec 22, 2015 at 10:20:36AM -0700, Jan Beulich wrote:
>> As said - 4.3.4 (I only now realize that this could also have been a
>> kernel version).
>
>Just fetched stable from
>git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable
>
>$ git tag --list | grep v4.3
>v4.3
>v4.3-rc1
>v4.3-rc2
>v4.3-rc3
>v4.3-rc4
>v4.3-rc5
>v4.3-rc6
>v4.3-rc7
>v4.3.1
>v4.3.2
>v4.3.3
>
>I don't see a v4.3.4 tag yet...

Sigh - this was in reply to your gcc version question. Right after having sent
the most recent reply I realized that there's no Linux 4.3.4 yet, so there really
was no ambiguity from the beginning. Therefore I have a hard time
understanding what you're asking for.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297314

On Wed, Dec 23, 2015 at 03:06:08AM -0700, Jan Beulich wrote:
> Sigh - this was in reply to your gcc version question. Right after having sent
> the most recent reply I realized that there's no Linux 4.3.4 yet, so there really
> was no ambiguity from the beginning. Therefore I have a hard time
> understanding what you're asking for.

I'm asking how exactly you're triggering this so that I can reproduce it too
here.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297315

>>> Borislav Petkov <bp@suse.de> 12/23/15 11:10 AM >>>
>On Wed, Dec 23, 2015 at 03:06:08AM -0700, Jan Beulich wrote:
>> Sigh - this was in reply to your gcc version question. Right after having sent
>> the most recent reply I realized that there's no Linux 4.3.4 yet, so there really
>> was no ambiguity from the beginning. Therefore I have a hard time
>> understanding what you're asking for.
>
>I'm asking how exactly you're triggering this so that I can reproduce it too
>here.

Simple 32-bit build on SLE11 SP4.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web