linux-kernel - Re: [PATCH] x86: fix two sparse warnings in early boot string handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Feb 2014 17:29:49 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	<linux-kernel@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, <x86@...nel.org>
Subject: Re: [PATCH] x86: fix two sparse warnings in early boot string handling

On 14-02-12 05:00 PM, David Rientjes wrote:
> On Wed, 12 Feb 2014, Paul Gortmaker wrote:
> 
>> Actually no v2 pending.  The original v1 patch was/is correct as-is.
>>
>> While x86-64 defconfig passed, it turns out that both strcmp and strstr
>> have to stay, else we will get this on i386 allyesconfig builds:
>>
>> arch/x86/boot/compressed/eboot.o: In function `handle_cmdline_files.isra.5.constprop.6':
>> eboot.c:(.text+0x4cf): undefined reference to `strstr'
>> eboot.c:(.text+0x601): undefined reference to `strstr'
>> make[2]: *** [arch/x86/boot/compressed/vmlinux] Error 1
>>
> 
> This means there is a strstr() prototype that is visible to 
> drivers/firmware/efi/efi-stub-helper.c but fails at linkage because you've 
> removed the definition. 

Yes, because you suggested removal when you said, in what is
now deleted context text:

 "I don't see why you can't remove strstr() in 
 arch/x86/boot/string.c entirely.  What breaks?"

The above answers your question. The eboot.c breaks.  So
we can't remove strstr.

> So, again, why would you add a duplicate 
> prototype with your patch?

I'm sure there is an implicit path to <linux/string.h>
which allows eboot.c to see a prototype and hence compile.

But that prototype is not associated with the early boot
string.c support.  Those prototypes are in boot.h -- where
my 1st patch added the strstr one to be consistent with
all the other early boot string.c functions.  Is it clear now?

> 
>> arch/x86/boot/edd.o: In function `query_edd':
>> arch/x86/boot/edd.c:136: undefined reference to `strcmp'
>> arch/x86/boot/edd.c:136: undefined reference to `strcmp'
>> arch/x86/boot/edd.c:140: undefined reference to `strcmp'
>> arch/x86/boot/edd.c:142: undefined reference to `strcmp'
>> make[1]: *** [arch/x86/boot/setup.elf] Error 1
>>
>> So my gut feeling was right after all.  ;)
>>
> 
> I'm not sure what strcmp has to do with this.

Per the earlier mail, and you suggestion about removal of
anything unused, this demonstrated that strcmp was also being
used and hence could not be removed either.

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