I really suspect that all of those registers are popped so at least for Iĭon't read alpha assembly very well and fork is a bit subtle. Perhaps all of the registers are there in kernel_threads already. With a structure that defines all of the registers in copy_thread. Looking at copy_thread it looks like at least on alpha we are dealing Kernel threads not havingĪll of their registers saved is one of those details. To see if I can understand what is going on.
SPARK AIRDROP CODE
I am starting with Al's analysis and reading the code > too (vfork/clone), so adding exit and io_uring to do so seems like the We traditionally have that requirement for fork() and friends > architectures do this, so it gets absolutely no coverage. And this is really painful because none of the *normal* 23:26 ` Linus Torvalds 0 siblings, 1 reply 121+ messages in threadįrom: Eric W. Something in task_pt_regs() thatĬatches "this doesn't actually work" and does a WARN_ON_ONCE() on the Too (vfork/clone), so adding exit and io_uring to do so seems like theīut I really wish we had some way to test and trigger this so that we > function in create_io_thread with the deeper stack. > do this need to be fixed to at least call do_exit and the kernel > I think at this point we need to say that the architectures that have a And this is really painful because none of the *normal*Īrchitectures do this, so it gets absolutely no coverage. > a context where they are not all saved. > The problem is sometimes we read all of the registers from Matt Turner, alpha, Geert Uytterhoeven, linux-m68k,Īrnd Bergmann, Ley Foon Tan, Tejun Heo, Daniel Jacobowitz, Linux Kernel Mailing List, Richard Henderson, Ivan Kokshaysky, 22:04 ` Linus Torvaldsġ sibling, 1 reply 121+ messages in threadįrom: Linus Torvalds 22:04 UTC ( / raw)Ĭc: linux-arch, Jens Axboe, Oleg Nesterov, Al Viro, 20:57 Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Eric W. * Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Makes PTRACE_EVENT_EXIT in do_exit not a problem if someone reads the
This issue that I am not seeing? Am I missing some critical detail that Is that reasonable of me to ask? Is there some other way to deal with I think at this point we need to say that the architectures that have aĭo this need to be fixed to at least call do_exit and the kernelįunction in create_io_thread with the deeper stack. Think create_io_threads saves all of the registers on the kernel stack. I have not doubled checked create_io_thread but I don't Which is a syscall and we definitely won't have everything saved on the In PTRACE_EVENT_EXIT we could be called from exit(2) Is called from io_uring, and we have the ptrace_stop in However I have looked farther and we have the location where get_signal That change wasħ7f6ab8b7768 ("don't dump the threads that had been already exiting when When this was initially observed it looked just like a coredump problemĪnd it could be solved by tweaking the coredump code. The problem is sometimes we read all of the registers from Saved on the kernel stack, and the kernel calls into signal handling andĪ few other contexts with all of the registers saved on the kernel Nios2 the kernel calls into system calls with a subset of the registers On some architectures such as alpha, m68k, and Geert Uytterhoeven, linux-m68k, Arnd Bergmann, Ley Foon Tan,ĭigging through the guts of exit I found something I am not quiteĬertain what to do with. Richard Henderson, Ivan Kokshaysky, Matt Turner, linux-alpha, Biederman 20:57 UTC ( / raw)Ĭc: Jens Axboe, Oleg Nesterov, Al Viro, Linus Torvalds, linux-kernel, 23:38 ` m68k: save extra registers on sys_exit and sys_exit_group syscall entry Michael SchmitzĠ siblings, 2 replies 121+ messages in threadįrom: Eric W. Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads All of help / color / mirror / Atom feed * Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads 20:57 Eric W.
0 kommentar(er)
