On Mon, Mar 10, 2014 at 2:53 PM, <[email protected]> wrote: > Zitat von Linus Torvalds <[email protected]>: > >> On Mon, Mar 10, 2014 at 2:25 PM, <[email protected]> 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
