Do fuswintr/suswintr make sense?

[Konstantin Belousov]

On Mon, Apr 16, 2018 at 04:10:12PM +0000, Brooks Davis wrote:
> The fuswintr() and suswintr() are intended to be safe in interrupt
> context.  They are used in the profiling code and if they fail the code
> falls back to triggering a trap with appropriate fields in struct
> thread.  This is fine as such, but amd64, arm, i386, and powerpc have
> implementations that always fail.  arm64, mips, riscv, and sparc64 all
> add code to the trap handler to detect that this particular code has
> faulted and return to the handler before doing and processing that might
> result in a sleep.  This optimization came from 4.4BSD.
> 
> Does this optimization actually make sense in 2017, particularly
> given that we're not taking advantage of it on x86 (and worse, our
> implementations of return (-1) aren't inlined so they have cache
> impacts)?

I do not see a reason to keep them around.

When I worked on copyin_nofault(), I specifically decided to not make it
working from the interrupt handlers contexts.  You need to be at the top
of the kernel to be able to use it.  So far there were no requests to
change that.

Since there is no other users of interrupt-safe usermode access, and since
the only user cope with such access not working, I do not see a point.