Hi,
now that we have an explicit wake_up_new_task() in order to start the
result from create_io_thread(), we should things up before calling
wake_up_new_task().
There're also some improvements around task->comm:
- We return 0 bytes for /proc/<pid>/cmdline
- We no longer allow a userspace process to change
/proc/<pid>/[task/<tid>]/comm
- We dynamically generate comm names (up to 63 chars)
via io_wq_worker_comm(), similar to wq_worker_comm()
While doing this I noticed a few places we check for
PF_KTHREAD, but not PF_IO_WORKER, maybe we should
have something like a PS_IS_KERNEL_THREAD_MASK() macro
that should be used in generic places and only
explicitly use PF_IO_WORKER or PF_KTHREAD checks where the
difference matters.
There are also quite a number of cases where we use
same_thread_group(), I guess these need to be checked.
Should that return true if userspace threads and their iothreds
are compared?
I've compiled but didn't test, I hope there's something useful...
Stefan Metzmacher (10):
kernel: always initialize task->pf_io_worker to NULL
io_uring: io_sq_thread() no longer needs to reset
current->pf_io_worker
io-wq: call set_task_comm() before wake_up_new_task()
io_uring: complete sq_thread setup before calling wake_up_new_task()
io-wq: protect against future set_task_comm() overflows.
io_uring: protect against future set_task_comm() overflows.
fs/proc: hide PF_IO_WORKER in get_task_cmdline()
fs/proc: protect /proc/<pid>/[task/<tid>]/comm for PF_IO_WORKER
io-wq: add io_wq_worker_comm() helper function for dynamic
proc_task_comm() generation
fs/proc: make use of io_wq_worker_comm() for PF_IO_WORKER threads
fs/io-wq.c | 118 ++++++++++++++++++++++++++++++++++++++++++++----
fs/io-wq.h | 4 ++
fs/io_uring.c | 33 +++++++++-----
fs/proc/array.c | 3 ++
fs/proc/base.c | 18 ++++++--
kernel/fork.c | 1 +
6 files changed, 154 insertions(+), 23 deletions(-)
--
2.25.1
