On Mon, Mar 10, 2014 at 3:03 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Mon, Mar 10, 2014 at 2:53 PM, <stef...@seibold.net> wrote: >> Zitat von Linus Torvalds <torva...@linux-foundation.org>: >> >>> On Mon, Mar 10, 2014 at 2:25 PM, <stef...@seibold.net> wrote: >>>> >>>> >>>> This was discovered by me. >>> >>> >>> Sorry for the misattribution. >>> >>>> But this is not a real solution, at least when vcpu function support >>>> will be added, then the code size will exceed the page size. Reserving >>>> two pages for the VDSO is a good option. >>> >>> >>> Quite frankly, there is no way in hell I will take a patch like that >>> for 3.14 any more, and I would argue against it for stable. >>> >>> Now, if this problem never happens with current kernels (because it's >>> purely due to the patch in -tip), then I don't much care. >>> >>> That said, I don't understand why we are even adding new features like >>> this to 32-bit mode in the first place, so if that patch is the sole >>> source of all this headache, then why not just throw the patch away? >>> >> >> The patch is working. And for this current issue there is a solution i >> already >> announced. >> >> A dual VDSO: a one page sized VDSO for the compat mode which has only the >> syscall >> code and on multi page sized VDSO which is mapped into user space for the >> non compat >> mode. >> >> This will work and has no side effects. > > IMO this is dumb. I can think of two sensible solutions: > > 1. Get rid of compat vdso and replace it with no vdso at all. This is > compatible with everything and requires almost no code :) > > 2. Fix compat vdso. Give it as much space as needed, make the address > dynamic, and relocate it to the right place. > > I see no legitimate reason to further increase the number of 32-bit > vdso images. Three is already ridiculous, and adding more is IMO > hideous. > > #1 is actually a serious proposal. To do it right, I think we should > rename the config option to CONFIG_BROKEN_GLIBC_VDSO, default it to n, > and make the help text clarify that this only affects certain > non-released glibc versions and that anyone building a new kernel is > highly unlikely to be affected. Then make vdso=2 act just like > vdso=0. CONFIG_BROKEN_GLIBC_VDSO just changes the default from vdso=1 > to vdso=0. > > Damn it, the number of users who (a) have a buggy copy of glibc, (b) > are using new kernels, and (c) are using CONFIG_COMPAT_VDSO as opposed > to, say, vdso=2 is probably very close to zero. (These users will > have issues until they fix their config.) > > The number of users who (a) have a buggy copy of glibc, (b) are using > new kernels, and (c) have cpus that derive significant benefit from > using a vdso instead of int 80 and care at all is probably also very > close to zero. > > The maintenance burden of this piece of shite is empirically quite far > from zero.
I'm testing a patch. If it seems to work, I'll send it out. It's a big cleanup. > > --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
