On Mon, Jun 21, 2021 at 06:59:01PM +0000, Al Viro wrote: > On Mon, Jun 21, 2021 at 01:54:56PM +0000, Al Viro wrote: > > On Tue, Jun 15, 2021 at 02:58:12PM -0700, Linus Torvalds wrote: > > > > > And I think our horrible "kernel threads return to user space when > > > done" is absolutely horrifically nasty. Maybe of the clever sort, but > > > mostly of the historical horror sort. > > > > How would you prefer to handle that, then? Separate magical path from > > kernel_execve() to switch to userland? We used to have something of > > that sort, and that had been a real horror... > > > > As it is, it's "kernel thread is spawned at the point similar to > > ret_from_fork(), runs the payload (which almost never returns) and > > then proceeds out to userland, same way fork(2) would've done." > > That way kernel_execve() doesn't have to do anything magical. > > > > Al, digging through the old notes and current call graph... > > 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 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... 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...
