1. 12 Apr, 2021 36 commits
  2. 11 Apr, 2021 4 commits
    • Pavel Begunkov's avatar
      io_uring: reg buffer overflow checks hardening · 50e96989
      Pavel Begunkov authored
      We are safe with overflows in io_sqe_buffer_register() because it will
      just yield alloc failure, but it's nicer to check explicitly.
      Signed-off-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Link: https://lore.kernel.org/r/2b0625551be3d97b80a5fd21c8cd79dc1c91f0b5.1616624589.git.asml.silence@gmail.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      50e96989
    • Jens Axboe's avatar
      io_uring: allow SQPOLL without CAP_SYS_ADMIN or CAP_SYS_NICE · 548d819d
      Jens Axboe authored
      Now that we have any worker being attached to the original task as
      threads, accounting of CPU time is directly attributed to the original
      task as well. This means that we no longer have to restrict SQPOLL to
      needing elevated privileges, as it's really no different from just having
      the task spawn a busy looping thread in userspace.
      Reported-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      548d819d
    • Jens Axboe's avatar
      io-wq: eliminate the need for a manager thread · 685fe7fe
      Jens Axboe authored
      io-wq relies on a manager thread to create/fork new workers, as needed.
      But there's really no strong need for it anymore. We have the following
      cases that fork a new worker:
      
      1) Work queue. This is done from the task itself always, and it's trivial
         to create a worker off that path, if needed.
      
      2) All workers have gone to sleep, and we have more work. This is called
         off the sched out path. For this case, use a task_work items to queue
         a fork-worker operation.
      
      3) Hashed work completion. Don't think we need to do anything off this
         case. If need be, it could just use approach 2 as well.
      
      Part of this change is incrementing the running worker count before the
      fork, to avoid cases where we observe we need a worker and then queue
      creation of one. Then new work comes in, we fork a new one. That last
      queue operation should have waited for the previous worker to come up,
      it's quite possible we don't even need it. Hence move the worker running
      from before we fork it off to more efficiently handle that case.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      685fe7fe
    • Jens Axboe's avatar
      kernel: allow fork with TIF_NOTIFY_SIGNAL pending · 66ae0d1e
      Jens Axboe authored
      fork() fails if signal_pending() is true, but there are two conditions
      that can lead to that:
      
      1) An actual signal is pending. We want fork to fail for that one, like
         we always have.
      
      2) TIF_NOTIFY_SIGNAL is pending, because the task has pending task_work.
         We don't need to make it fail for that case.
      
      Allow fork() to proceed if just task_work is pending, by changing the
      signal_pending() check to task_sigpending().
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      66ae0d1e