[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071121001307.GA1804@elte.hu>
Date: Wed, 21 Nov 2007 01:13:07 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Zachary Amsden <zach@...are.com>
Cc: Roland McGrath <roland@...hat.com>, Andi Kleen <ak@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/18] x86 vDSO: consolidate vdso32
* Zachary Amsden <zach@...are.com> wrote:
> > The 32-bit vDSO mapping now behaves the same on x86_64 as on native
> > 32-bit. The abi.syscall32 sysctl on x86_64 now takes the same values
> > that vm.vdso_enabled takes on the 32-bit kernel. That is, 1 means a
> > randomized vDSO location, 2 means the fixed old address. The
> > CONFIG_COMPAT_VDSO option is now available to make this the default
> > setting, the same meaning it has for the 32-bit kernel. (This does
> > not affect the 64-bit vDSO.)
>
> I think you should drop CONFIG_COMPAT_VDSO support for 32-bit VDSO on
> 64-bit kernel. This was only to hack around a broken version of glibc
> that shipped with SUSE PRO 9.0, which had broken assertions based on
> misinterpretation of ELF fields. 64-bit machines will never see this
> glibc and the hack can die.
>
> Perhaps it is finally time to remove the hack from 32-bit as well, and
> eliminate COMPAT_VDSO entirely? Or does it really have to live
> forever.
we can phase it out, via the Documentation/feature-removal-schedule.txt
mechanism.
Ingo
-
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/
Powered by blists - more mailing lists