|
From: Kevin M. <ch...@go...> - 2019-02-11 17:01:39
|
Hey all, I work on the DynamoRIO project (https://github.com/DynamoRIO/dynamorio), a dynamic instrumentation tool like Pin or Valgrind. Last year a commit was made to the linux kernel [0] introducing “Restartable Sequences” (aka rseq), a low-level synchronization primitive for doing lockless per-CPU work. For those who don’t know about it, rseq introduces a way in which a thread can detect, with very low overhead, whether it was interrupted (preempted, migrated to another CPU, etc) in the middle of executing some sequence of code; combined with access to CPU-local data, this enables algorithms which scale well for many threads on many CPUs. Unfortunately for DynamoRIO, we need to handle these sequences explicitly or else we will run into correctness issues. For Google’s internal API, we have rudimentary support in open-source DynamoRIO for this feature [1], and have done extensive work to support arbitrary instrumentation of these sections [2]; for that API, our solutions work well. But we have some unsolved problems for the API which ultimately landed upstream. In particular, even detecting where these atomic sequences are in a binary is challenging in the general case. We believe PIN and Valgrind are affected by this API for general (Linux) use-cases as well, and were curious if anyone else has plans to handle this new Linux feature. On the DynamoRIO project we have discussed various solutions to our woes, most of which boil down to additions to the API or conventions that would need to be followed by applications to get correct execution under DynamoRIO. But, assuming it affects more than us, we figured we could try and come up with a solution that works well for everyone. Our wiki page about Restartable Sequences [2] has a short summary of various pain points and some solutions to inspire discussion. Thanks for your time, Kevin [0] https://github.com/torvalds/linux/commit/d82991a8688ad128b46db1b42d5d84396487a508 [1] https://github.com/DynamoRIO/dynamorio/blob/5d8bfafcf29133b48d3f53d45e110b6a49761496/core/unix/os.c#L10604 [2] https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences PS: here's to hoping that CC'ing all three mailing lists doesn't cause any troubles :) Sorry in advance for any annoyances. |
|
From: Derek B. <bru...@go...> - 2019-09-18 19:43:47
|
On Mon, Feb 11, 2019 at 12:01 PM 'Kevin Malachowski' via DynamoRIO Devs < dyn...@go...> wrote: > Last year a commit was made to the linux > kernel introducing “Restartable Sequences” (aka rseq), a low-level > synchronization primitive for doing lockless per-CPU work. ... assuming it affects more than us, we figured we could try and come up > with a > solution that works well for everyone. > DynamoRIO has implemented a "run twice" solution to support this rseq kernel feature. It is a thorny problem to solve and we have documented the problems and our solutions at https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences <https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences>. We had to rely on application conventions (also being pushed by the rseq library writers) and limit the scope of what is supported in order to arrive at a workable solution. When Valgrind tackles this problem we would be interested in hearing about it, including any alternative solutions. - Derek |