RISC-V: User-Visible ABI Cleanup

From: Palmer Dabbelt
Date: Mon Nov 20 2017 - 13:59:03 EST

This patch set contains all the user-visible ABI changes that we currently know
about. There might be a few more as we get through the glibc upstreaming
process, though. Most of the changes are pretty minor:

* Some VDSO symbols that weren't defined were versioned, which doesn't make any
* We were missing some common VDSO entries.
* The instruction cache is flushed when making a dirty page executable.
* A system call (and VDSO entry) has been added to flush the instruction cache.

There's one big, implicit ABI change here: 'fence.i' is no longer meaningful to
execute from Linux userspace, instead users are expected to call the new VDSO
entry. There's a lot more info in the commit, but the short version is:

* 'fence.i' performs an instruction cache flush on the local hart.
* There's no way for userspace to map threads to harts, so there's no way to
perform global instrucion cache flushes.
* The supervisor can't trap 'fence.i', so the only other way to maintain
correct behavior would be to flush the instruction cache before returning to

We don't want to take the performance hit of flushing the instruction cache
every time we return to userspace, so we're breaking the ABI to mandate that
users call the VDSO entry instead of using 'fence.i'. Since we haven't had a
tarball release of Linux yet, I think this ABI break is still kosher. Of
course, we won't do this once there's been a release :).

Sorry this was a bit late, but I'm really hoping to get this into 4.15 so we
don't end up with a broken ABI in our first kernel release.

[PATCH 1/4] RISC-V: Remove __vdso_cmpxchg{32,64} symbol versions
[PATCH 2/4] RISC-V: Add VDSO entries for
[PATCH 3/4] RISC-V: Flush I$ when making a dirty page executable
[PATCH 4/4] RISC-V: Allow userspace to flush the instruction cache