lkml.org 
[lkml]   [2021]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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

    \
     
     \ /
      Last update: 2021-05-12 23:32    [W:2.604 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site