On Sun, Feb 2, 2014 at 1:39 PM, Stefani Seibold <stef...@seibold.net> wrote: > Am Sonntag, den 02.02.2014, 08:46 -0800 schrieb Andy Lutomirski: >> On Sun, Feb 2, 2014 at 3:27 AM, <stef...@seibold.net> wrote: >> > From: Stefani Seibold <stef...@seibold.net> >> > >> > This patch add the time support for 32 bit a VDSO to a 32 bit kernel. >> >> [...] >> >> Can you address the review comments from last time around? For >> example, this still seems to have redundant vvar and hpet mappings, it >> doesn't use the VVAR macro, it moves the 32-bit compat vDSO, etc. >> > > I will address the compat VDSO issue. > > But the VVAR macro will be not a part of this patch set. If you depend > on this, feel free to create one. From my point of view this is not > feasible without a macro hacking, because the address accessing the vvar > area differs in kernel and VDSO user mode.
Sorry, but "I will make the code messier for no apparent reason and I will not offer to fix it in the same series" gets my NAK. Hint: I'm talking about two or three lines of code in vvar.h. > > I also see no redundant mapping. There are two modes, one is the map of > the kernel area the other maps the VDSO into the user space area. This > is exactly the behaviour of the origin VDSO implementation. No. In your series there are *three* mappings. There are: - The linear mapping that the kernel loader sets up (the writable mapping used in the kernel). This is implicit and, of course, fine. - There's the fixmap page, which aliases the normal kernel mapping at a fixed address with the user, ro, and nx attributes. The 64-bit vDSO uses that mapping. See vdso.h -- it's all arranged pretty clearly. Your code, for no discernible reason, sets up a fixmap entry on *32-bit* kernels. - The vma that you're setting up adjacent to the actual vdso text. This is what you are using. Please choose *one* user-readable mapping for the 32-bit vdso and stick with it. If the 64-bit vdso can use it to and userspace doesn't break, even better. But a pointless set of extra fixmap entries is not okay. hpa's right about the symbol versions, BTW -- those are ABI and will probably break (at least) every new-enough Go binary. --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/
