Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 12 May 2021 10:44:40 -0700 | Subject | Re: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads |
| |
On Tue, May 11, 2021 at 9:24 PM Olivier Langlois <olivier@trillion01.com> wrote: > > I have reported an issue that I have with a user process using io_uring > where when it core dumps, the dump fails to be generated. > https://github.com/axboe/liburing/issues/346
I suspect most kernel developers don't have github notifications enabled. I know I have them disabled because it would be *way* too noisy not to.
But maybe Jens does for that libiouring part.
> Pavel did comment to my report and he did point out this thread as > possibly a related issue.
I don't think this is related. The gdb confusion wouldn't affect core dump generation.
I don't see why a core-dump shouldn't work from an IO thread these days - the signal struct and synchronization should all be the same as for a regular user thread.
That said, I do wonder if we should avoid generating core dumps from the IO worker thread itself. The IO thread itself should never get a SIGSEGV/SIGBUS anyway, it should have been turned into -EFAULT.
So maybe the
if (current->flags & PF_IO_WORKER) goto out;
in kernel/signal.c should be moved up above the do_coredump() logic regardless.
Jens, have you played with core-dumping when there are active io_uring threads? There's a test-program in that github issue report..
Linus
| |