lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 27 Mar 2021 02:46:24 +0100 From: Stefan Metzmacher <metze@...ba.org> To: Jens Axboe <axboe@...nel.dk>, io-uring@...r.kernel.org Cc: torvalds@...ux-foundation.org, ebiederm@...ssion.com, oleg@...hat.com, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/6] Allow signals for IO threads Hi Jens, > root@...704-166:~# LANG=C gdb --pid 1320 > GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word". > Attaching to process 1320 > [New LWP 1321] > [New LWP 1322] > > warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386 > > warning: Architecture rejected target-supplied description > syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 > 38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory. > (gdb) Ok, the following makes gdb happy again: --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -163,6 +163,8 @@ int copy_thread(unsigned long clone_flags, unsigned long sp, unsigned long arg, /* Kernel thread ? */ if (unlikely(p->flags & (PF_KTHREAD | PF_IO_WORKER))) { memset(childregs, 0, sizeof(struct pt_regs)); + if (p->flags & PF_IO_WORKER) + childregs->cs = current_pt_regs()->cs; kthread_frame_init(frame, sp, arg); return 0; } I'm wondering if we should decouple the PF_KTHREAD and PF_IO_WORKER cases even more and keep as much of a userspace-like copy_thread as possible. metze
Powered by blists - more mailing lists