Re: Yes, people use FOLL_FORCE ;)

[Robert O'Callahan]

On Tue, May 30, 2017 at 11:08 AM, Keno Fischer <keno@xxxxxxxxxxxxxxxxxx> wrote:
> Now, while we're probably fine with using the fallbacks, I know there's
> others that rely on this behavior as well (cc'ing Robert O'Callahan of the
> rr project for which this change will result in significant performance
> degradation).

Yeah, this breaks rr. We write to readonly code and data mappings via
/proc/.../mem in lots of different situations, particularly when we're
adjusting program state during replay to match the recorded execution.

Like Julia, we can add workarounds, but they could be expensive. For
small writes we can fall back to PTRACE_POKEDATA without much
performance loss, but for big writes it would be cheaper to
sock-puppet the ptracee to call mprotect to temporarily make pages
writeable. Of course that takes at least four context switches, so the
lower-bound overhead of that approach is pretty bad. OTOH there are
probably tricks we could pull to mitigate the overhead some more. For
example during replay we might be able to make some pages that
"should" be read-only actually be read-write when we know the recorded
process didn't try writing to them.

So in summary: rr can be upgraded to cope with this, incurring some
unknown amount of additional overhead, but existing rr installs will
definitely be totally broken.

Thanks,
Rob