linux-kernel - Re: [BUILD-FAILURE] linux-next: Tree for June 30

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 30 Jun 2008 13:42:09 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Sam Ravnborg <sam@...nborg.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Andy Whitcroft <apw@...dowen.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [BUILD-FAILURE] linux-next: Tree for June 30

H. Peter Anvin wrote:
> Sam Ravnborg wrote:
>>> ah, ok. So the patch below should solve this for now?
>>>
>>> is there any particular reason why we are limited to 100 sections? 
>>> (is there some ELF limitation here perhaps?)
>>
>> I would still like to know if you see significant different numbers 
>> than Kamalesh.
>> If you see a number close to 100 then OK.
>> But if you see a number say in the range of below 80 then we should 
>> dive deeper into this.
>>
>> I do not even know what the program does - never looked at it befoe
>> so why the original limit was 100 I dunno.
>>
> 
> It looks to me that the people who did the relocatable kernel code just 
> put in a magic number.  There is certainly no inherent reason for this 
> limit.
> 
> What's really ugly is that this is in a host-space program!  It would 
> have been one thing if it had been in a piece of code run in a 
> restricted environment, e.g. in the decompressor, but this one runs in 
> user space on the build environment.
> 
> The quick solution is to change this number to something obscenely big 
> (say 10000, but even that could be an issue if we end up doing stuff 
> like section per function); the proper solution is to turn these arrays 
> into a structure and allocate the array dynamically.

Here is a quick patch to just change the number; I'll take a quick pass 
to see how much work it'd be to allocate it dynamically.

	-hpa

View attachment "diff" of type "text/plain" (413 bytes)