Hi Al,
On 22/06/21 7:24 am, Al Viro wrote:
There's a large mess around do_exit() - we have a bunch of
callers all over arch/*; if nothing else, I very much doubt that really
want to let tracer play with a thread in the middle of die_if_kernel()
or similar.
We sure as hell do not want to arrange for anything on the kernel
stack in such situations, no matter what's done in exit(2)...
FWIW, on alpha it's die_if_kernel(), do_entUna() and do_page_fault(),
all in not-from-userland cases. On m68k - die_if_kernel(), do_page_fault()
(both for non-from-userland cases) and something really odd - fpsp040_die().
Exception handling for floating point stuff on 68040? Looks like it has
Exception handling for emulated floating point instructions, really -
exceptions happening when excecuting FPU instructions on hardware will
do the normal exception processing.
an open-coded copy_to_user()/copy_from_user(), with faults doing hard
do_exit(SIGSEGV) instead of raising a signal and trying to do something
sane...
Yes, that's what it does. Not pretty ... though all that using m68k
copy_to_user()/copy_from_user() would change is returning how many bytes
could not copied. In contrast to the ifpsp060 code, we could not pass on
that return status to callers of copyin/copyout in fpsp040, so I don't
see what sane thing could be done if a fault happens.
(I'd expect the MMU would have raised a bus error and resolved the
problem by a page fault if possible, before we ever get to this point?)
I really don't want to try and figure out how painful would it be to
teach that code how to deal with faults - _testing_ anything in that
area sure as hell will be. IIRC, details of recovery from FPU exceptions
on 68040 in the manual left impression of a minefield...
This is only about faults when moving data from/to user space. FPU
exceptions are handled elsewhere in the code. So we at least don't have
to deal with that particular minefield.
Teaching the fpsp040 code to deal with access faults looks horrible
indeed... let's not go there.
Cheers,
Michael
