Messages in this thread | | | From | Andrew Lutomirski <> | Date | Tue, 7 Jun 2011 19:49:02 -0400 | Subject | Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls |
| |
On Tue, Jun 7, 2011 at 7:32 PM, <pageexec@freemail.hu> wrote: >> > do you know what that mucking looks like? ;) prepare for the most complex code >> > you've ever seen (it's in __bad_area_nosemaphore): >> > >> > 779 #ifdef CONFIG_X86_64 >> > 780 »·······if (mm && (error_code & PF_INSTR) && mm->context.vdso) { >> > 781 »·······»·······if (regs->ip == (unsigned long)vgettimeofday) { >> > 782 »·······»·······»·······regs->ip = (unsigned long)VDSO64_SYMBOL(mm->context.vdso, gettimeofday); >> > 783 »·······»·······»·······return; >> > 784 »·······»·······} else if (regs->ip == (unsigned long)vtime) { >> > 785 »·······»·······»·······regs->ip = (unsigned long)VDSO64_SYMBOL(mm->context.vdso, clock_gettime); >> > 786 »·······»·······»·······return; >> > 787 »·······»·······} else if (regs->ip == (unsigned long)vgetcpu) { >> > 788 »·······»·······»·······regs->ip = (unsigned long)VDSO64_SYMBOL(mm->context.vdso, getcpu); >> > 789 »·······»·······»·······return; >> > 790 »·······»·······} >> > 791 »·······} >> > 792 #endif >> >> I like this approach, however since we're already in the kernel it >> makes sense just to run the normal syscall instead of redirecting to >> the vdso. > > it's not that simple as the page fault occurs not at the actual syscall > insn but at the first insn of the given vsyscall function, so you'd have > to emulate it carefully to be able to return back the original caller in > userland. > >
My patch (the version that's in tip/x86/vdso) more-or-less does that. It's something like six lines of code, including error handling.
__bad_area_nosemaphore is not a fast path, and in fact I tried that for the very first version of this code that I wrote. My recollection is that it's noticeably slower than int 0xcc because it has to go through the whole VMA lookup.
If you want to submit a patch to switch from int 0xcc to __bad_area_nosemaphore, be my guest :) It will have almost no effect on the complexity of the code, and, in fact, you'll probably get a net deletion of lines because you can remove all the crud in vmlinux.lds.S and some of the mapping code in vsyscall_64.c.
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |