On Wed, 13 Apr 2011 19:16:40 +0200 Geert Uytterhoeven <[email protected]> wrote:
> On Wed, Apr 13, 2011 at 19:04, Andrew Morton <[email protected]> > wrote: > > On Wed, 13 Apr 2011 09:59:50 +0200 Geert Uytterhoeven > > <[email protected]> wrote: > > > >> CC stable for v2.6.38 > >> > >> .. > >> > >> > 5520e89 ("brk: fix min_brk lower bound computation for COMPAT_BRK") tried > >> > to get the whole logic of brk randomization for legacy (libc5-based) > >> > applications finally right. > >> > > >> > It turns out that the way to detect whether brk has actually been > >> > randomized in the end or not introduced by that patch still doesn't work > >> > for those binaries, as reported by Geert. > >> > > >> > I don't like it, but currently see no better option than a bit flag in > >> > task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2 > >> > case. > >> > > > > > There's nothing in this changelog which tells us that the problem is > > serious enough to need fixing in -stable. If there had been, I'd have > > added cc:stable to the changelog myself. > > > > So. Why do we think this needs fixing in 2.6.38+? > > Because it's a regression on running (albeit very old) userspace binaries. > What is a regression? Please provide a description of the kernel behavior both before and after this patch. _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
