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
