On Tue, Feb 05, 2008 at 01:54:26PM +0100, Ingo Molnar wrote:
quoted text
> * Jiri Kosina <jkosina@suse.cz> wrote:
> 
> > On Tue, 5 Feb 2008, Pavel Machek wrote:
> > 
> > > > Actually, this clearly shows that either prehistoric libc.so.5 or the 
> > > > program itself are broken.
> > > I believe it shows clear regression in latest 2.6.25 kernel.
> > 
> > I am still not completely sure. It might be a regression, but it also 
> > might just trigger the bug in ancient version in libc.so.5 which might 
> > be fixed in some later version [...]
> 
> which too is a regression ...
> 
> really, lets add a sysctl for this, and a .config option that either 
> disables or enables it. Then we will default to disabled. (but users can 
> enable it - and distros can build their kernels with this .config option 
> enabled)

I don't think kernel should care about programs which are buggy and make invalid
assumptions, and that's the case here.  I remember we have been through this
5 years ago when brk randomization has been added to Red Hat kernels.  There was
one or two broken programs which made assumptions on what brk(0) is supposed
to return at program startup, everything else was ok.
For the buggy apps there is always setarch i386 -R ./the_buggy_program
so I don't think we need to add another sysctl for this.

	Jakub
--
unsubscribe notice
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/