Michael Schmitz <schmitzmic@xxxxxxxxx> writes: > Hi Eric, > > On 15/06/21 4:26 am, Eric W. Biederman wrote: >> Michael Schmitz <schmitzmic@xxxxxxxxx> writes: >> >>> On second thought, I'm not certain what adding another empty stack frame would >>> achieve here. >>> >>> On m68k, 'frame' already is a new stack frame, for running the new thread >>> in. This new frame does not have any user context at all, and it's explicitly >>> wiped anyway. >>> >>> Unless we save all user context on the stack, then push that context to a new >>> save frame, and somehow point get_signal to look there for IO threads >>> (essentially what Eric suggested), I don't see how this could work? >>> >>> I must be missing something. >> It is only designed to work well enough so that ptrace will access >> something well defined when ptrace accesses io_uring tasks. >> >> The io_uring tasks are special in that they are user process >> threads that never run in userspace. So as long as everything >> ptrace can read is accessible on that process all is well. > OK, I'm testing a patch that would save extra context in sys_io_uring_setup, > which ought to ensure that for m68k. I had to update ret_from_kernel_thread to pop that state to get Linus's change to boot. Apparently kernel_threads exiting needs to be handled. >> Having stared a bit longer at the code I think the short term >> fix for both of PTRACE_EVENT_EXIT and io_uring is to guard >> them both with CONFIG_HAVE_ARCH_TRACEHOOK. Which does not work because nios2 which looks susceptible sets CONFIG_HAVE_ARCH_TRACEHOOK. A further look shows that there is also PTRACE_EVENT_EXEC that needs to be handled so execve and execveat need to be wrapped as well. Do you happen to know if there is userspace that will run in qemu-system-m68k that can be used for testing? Eric
