On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Wed, Mar 12, 2014 at 7:41 AM, Linus Torvalds > <torva...@linux-foundation.org> wrote: > > Having looked at it a bit more, I think the correct solution is: > > - leave the legacy compat-vdso FIXMAP entry at a single page > > - do *not* add the HPET/VVAR page games to the legacy case. Get rid > of the remap_pfn_pages() games entirely.
If I understand your suggestion right, I you're saying that we should have two cases: 1. CONFIG_COMPAT_VDSO or vdso32=2: Use a one-page vdso in the fixmap. 2. !CONFIG_COMPAT_VDSO or vdso32=1: Use a multiple-page vdso + vvar area in a vma (or maybe a couple of vmas). The current 32-bit vdso is actually three separate .so files, selected at boot time. So now we'd need six. (Yes, this can be reduced to two. But still.) I think I'd prefer: 1. CONFIG_COMPAT_VDSO or vdso32=2: No vdso at all 2. !CONFIG_COMPAT_VDSO or vdso32=1: Use a multiple-page vdso + vvar area in a vma (or maybe a couple of vmas). This variant is a *lot* less code, and it avoids the need to generate a further combinatorial blowup in the number of vdso images that the kernel builds. (This is more or less the same thing as my thoroughly-nakked patch, except with the default flipped.) The only downside that I can think of is that people who are using CONFIG_COMPAT_VDSO unnecessarily take a small performance hit. IOW, I don't think that anyone really wants to support two implementations of a non-trivial 32-bit vdso. Re: leaving the hpet and such in the fixmap unconditionally, I'm not sure I see the advantage. For one thing, it can't support the compat case, it's not really clear to me how it fits in with x32, and it prevents future improvements that involve adjusting those mappings per process. Doing it with vmas is IMO not so bad. (Doing with with vmas or with fixmaps depending on kernel configuration, on the other hand, is a mess.) --Andy -- 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/
