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:37:05 -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@...ibm.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [BUILD-FAILURE] linux-next: Tree for June 30

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.

	-hpa

--
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/