[GIT PULL] io_uring fixes for 5.12-rc5

[GIT PULL] io_uring fixes for 5.12-rc5

[Jens Axboe]

Hi Linus,

- Use thread info versions of flag testing, as discussed last week.

- The series enabling PF_IO_WORKER to just take signals, instead of
  needing to special case that they do not in a bunch of places. Ends up
  being pretty trivial to do, and then we can revert all the special
  casing we're currently doing.

- Kill dead pointer assignment

- Fix hashed part of async work queue trace

- Fix sign extension issue for IORING_OP_PROVIDE_BUFFERS

- Fix a link completion ordering regression in this merge window

- Cancelation fixes

Please pull!


The following changes since commit 0031275d119efe16711cd93519b595e6f9b4b330:

  io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL (2021-03-21 09:41:14 -0600)

are available in the Git repository at:

  git://git.kernel.dk/linux-block.git tags/io_uring-5.12-2021-03-27

for you to fetch changes up to 2b8ed1c94182dbbd0163d0eb443a934cbf6b0d85:

  io_uring: remove unsued assignment to pointer io (2021-03-27 14:09:11 -0600)

----------------------------------------------------------------
io_uring-5.12-2021-03-27

----------------------------------------------------------------
Colin Ian King (1):
      io_uring: remove unsued assignment to pointer io

Jens Axboe (9):
      io_uring: don't use {test,clear}_tsk_thread_flag() for current
      io-wq: fix race around pending work on teardown
      kernel: don't call do_exit() for PF_IO_WORKER threads
      io_uring: handle signals for IO threads like a normal thread
      kernel: stop masking signals in create_io_thread()
      Revert "signal: don't allow sending any signals to PF_IO_WORKER threads"
      Revert "kernel: treat PF_IO_WORKER like PF_KTHREAD for ptrace/signals"
      Revert "kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for freezing"
      Revert "signal: don't allow STOP on PF_IO_WORKER threads"

Pavel Begunkov (9):
      io_uring: correct io_queue_async_work() traces
      io_uring: don't skip file_end_write() on reissue
      io_uring: fix provide_buffers sign extension
      io_uring: do ctx sqd ejection in a clear context
      io_uring: maintain CQE order of a failed link
      io_uring: fix timeout cancel return code
      io_uring: do post-completion chore on t-out cancel
      io_uring: don't cancel-track common timeouts
      io_uring: don't cancel extra on files match

 fs/io-wq.c       | 32 +++++++++++-------
 fs/io_uring.c    | 98 +++++++++++++++++++++++++++++---------------------------
 kernel/fork.c    | 16 ++++-----
 kernel/freezer.c |  2 +-
 kernel/ptrace.c  |  2 +-
 kernel/signal.c  | 20 +++++++-----
 6 files changed, 94 insertions(+), 76 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] io_uring fixes for 5.12-rc5

[Linus Torvalds]

On Sat, Mar 27, 2021 at 6:02 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> - Fix sign extension issue for IORING_OP_PROVIDE_BUFFERS

I don't think this fixes anything.

It may change the sign bit, but as far as I can tell, doesn't actually
fix anything at all. You're multiplying a 16-bit value with a signed
32-bit one. The cast to "unsigned long" makes sure it's done as an
unsigned multiply, but doesn't change anything funcamental.

 - "p->len" is an explictly signed type (__s32). Don't ask me why.

 - the size calculation takes that signed value, turns it into an
"unsigned long" (which sign-extends it), and then does an unsigned
multiply of that nonsensical value

 - that can overflow both in 64-bit and 32-bit (since the 32-bit
signed value has been made an extremely large "unsigned long"

So there is absolutely nothing "right" about the typing there. Not
before, and not after. The whole cast is entirely meaningless, and
doesn't seem to fix anything. It is basically a random change.

If you want that calculation to make sense, you need to

 (a) disallow the insane case of signed "len". Most certainly not
sign-extend it to a large unsigned value.

 (b) actually make sure there is no overflow

because adding a random cast does neither of those things.

              Linus

Re: [GIT PULL] io_uring fixes for 5.12-rc5

[pr-tracker-bot]

The pull request you sent on Sat, 27 Mar 2021 19:01:53 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.12-2021-03-27

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b44d1ddcf835b39a8dc14276d770074deaed297c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] io_uring fixes for 5.12-rc5

[Pavel Begunkov]

On 28/03/2021 20:02, Linus Torvalds wrote:
> On Sat, Mar 27, 2021 at 6:02 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> - Fix sign extension issue for IORING_OP_PROVIDE_BUFFERS
> 
> I don't think this fixes anything.
> 
> It may change the sign bit, but as far as I can tell, doesn't actually
> fix anything at all. You're multiplying a 16-bit value with a signed
> 32-bit one. The cast to "unsigned long" makes sure it's done as an
> unsigned multiply, but doesn't change anything funcamental.
> 
>  - "p->len" is an explictly signed type (__s32). Don't ask me why.
> 
>  - the size calculation takes that signed value, turns it into an
> "unsigned long" (which sign-extends it), and then does an unsigned
> multiply of that nonsensical value
> 
>  - that can overflow both in 64-bit and 32-bit (since the 32-bit
> signed value has been made an extremely large "unsigned long"
> 
> So there is absolutely nothing "right" about the typing there. Not
> before, and not after. The whole cast is entirely meaningless, and
> doesn't seem to fix anything. It is basically a random change.
> 
> If you want that calculation to make sense, you need to
> 
>  (a) disallow the insane case of signed "len". Most certainly not
> sign-extend it to a large unsigned value.
> 
>  (b) actually make sure there is no overflow
> 
> because adding a random cast does neither of those things.

Agree, thanks for pointing out. Will get it fixed.


-- 
Pavel Begunkov