Messages in this thread | | | Date | Mon, 22 Mar 2021 17:05:59 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks |
| |
On 03/20, Jens Axboe wrote: > > Hi, > > Been trying to ensure that we do the right thing wrt signals and > PF_IO_WORKER threads
OMG. Am I understand correctly? create_io_thread() can create a sub- thread of userspace process which acts as a kernel thread?
Looks like this is the recent feature I wasn't aware... Can't really comment right now, just some random and possibly wrong notes.
> 1) Just don't allow signals to them in general. We do mask everything > as blocked, outside of SIGKILL, so things like wants_signal() will > never return true for them.
This only means that signal_wake_up() won't be called. But the signal will be queued if sent via tkill/etc, I don't think this is what we want?
A PF_IO_WORKER thread should ignore the signals. But it seems that the PF_IO_WORKER check in sig_task_ignored() makes no sense and can't help. I don't think PF_IO_WORKER && SIG_KTHREAD_KERNEL is possible.
Not to mention that sig_ignored() won't even call sig_task_ignored(), it will return false exactly because the signal is blocked.
Confused.
Plus the the setting of tsk->blocked in create_io_thread() looks racy, signal_pending() can be already true. And in fact it can't really help, calculate_sigpending() can set TIF_SIGPENDING after wake_up_new_task() anyway.
And why does create_io_thread() use lower_32_bits() ? This looks very confusing. This
.exit_signal = (lower_32_bits(flags) & CSIGNAL);
too. Firstly, the rhs is always zero, secondly it is ignored because of CLONE_THREAD.
ptrace_attach() checks PF_IO_WORKER too. Yes, but 'gdb -p' will try to attach to every thread /proc/pid/tasks, so it will probably just hang?
Oleg.
| |