This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86_64 RIP-relative addressing bug


I won't go into the gory details, but trying to play VM tricks is a royal
can of worms.  I think it's more trouble than the disassembly path by far.
That may be overstating it.  It's certainly not an easy path.  You can
point different processors at different page tables, but only from the root
of the tree.  An individual page is three or four levels down the tree from
there, and ordinarily all the kernel parts of the address space are a
common subtree shared by all of the top-level page tables used by any
processor for any user address space.  In the general case, making a
modified page table for one CPU to use momentarily involves copying that
entire page table tree (since other CPUs may be running other threads in
the same user address space, and so sharing the that original page table
tree).  In the case where the particular address space is only used by one
thread, you can elide the complete copy and modify and restore a slot--but
you are still copying the kernel-space part of the subtree, which is
ordinarily shared across the entire system.  I don't really know the
numbers, but I suspect the TLB shootdown required even in the best of cases
(i.e. you previously cached all the copied page tables you needed, and no
allocation/copying is required, just mutation) would rival the overhead of
the other approaches.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]