[GIT PULL] io_uring fixes for 5.12-rc3

[GIT PULL] io_uring fixes for 5.12-rc3

[Jens Axboe]

Hi Linus,

Not quite as small this week as I had hoped, but at least this should be
the end of it. All the little known issues have been ironed out - most
of it little stuff, but cancelations being the bigger part. Only minor
tweaks and/or regular fixes expected beyond this point.

- Fix the creds tracking for async (io-wq and SQPOLL)

- Various SQPOLL fixes related to parking, sharing, forking, IOPOLL,
  completions, and life times. Much simpler now.

- Make IO threads unfreezable by default, on account of a bug report
  that had them spinning on resume. Honestly not quite sure why thawing
  leaves us with a perpetual signal pending (causing the spin), but for
  now make them unfreezable like there were in 5.11 and prior.

- Move personality_idr to xarray, solving a use-after-free related to
  removing an entry from the iterator callback. Buffer idr needs the
  same treatment.

- Re-org around and task vs context tracking, enabling the fixing of
  cancelations, and then cancelation fixes on top.

- Various little bits of cleanups and hardening, and removal of now dead
  parts.

Please pull!


The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

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

for you to fetch changes up to 58f99373834151e1ca7edc49bc5578d9d40db099:

  io_uring: fix OP_ASYNC_CANCEL across tasks (2021-03-12 09:42:56 -0700)

----------------------------------------------------------------
io_uring-5.12-2021-03-12

----------------------------------------------------------------
Jens Axboe (9):
      io-wq: fix race in freeing 'wq' and worker access
      io-wq: always track creds for async issue
      io_uring: SQPOLL parking fixes
      io-wq: remove unused 'user' member of io_wq
      io_uring: move all io_kiocb init early in io_init_req()
      io_uring: always wait for sqd exited when stopping SQPOLL thread
      kernel: make IO threads unfreezable by default
      io_uring: force creation of separate context for ATTACH_WQ and non-threads
      io_uring: perform IOPOLL reaping if canceler is thread itself

Matthew Wilcox (Oracle) (1):
      io_uring: Convert personality_idr to XArray

Pavel Begunkov (20):
      io_uring: make del_task_file more forgiving
      io_uring: introduce ctx to tctx back map
      io_uring: do ctx initiated file note removal
      io_uring: don't take task ring-file notes
      io_uring: index io_uring->xa by ctx not file
      io_uring: warn when ring exit takes too long
      io_uring: cancel reqs of all iowq's on ring exit
      io-wq: warn on creating manager while exiting
      io_uring: fix unrelated ctx reqs cancellation
      io_uring: clean R_DISABLED startup mess
      io_uring: fix io_sq_offload_create error handling
      io_uring: add io_disarm_next() helper
      io_uring: fix complete_post races for linked req
      io_uring: fix invalid ctx->sq_thread_idle
      io_uring: remove indirect ctx into sqo injection
      io_uring: cancel deferred requests in try_cancel
      io_uring: remove useless ->startup completion
      io_uring: prevent racy sqd->thread checks
      io_uring: cancel sqpoll via task_work
      io_uring: fix OP_ASYNC_CANCEL across tasks

Stefan Metzmacher (2):
      io_uring: run __io_sq_thread() with the initial creds from io_uring_setup()
      io_uring: kill io_sq_thread_fork() and return -EOWNERDEAD if the sq_thread is gone

Yang Li (1):
      io_uring: remove unneeded variable 'ret'

yangerkun (1):
      io-wq: fix ref leak for req in case of exit cancelations

 fs/io-wq.c               |  25 +-
 fs/io-wq.h               |   2 +-
 fs/io_uring.c            | 837 ++++++++++++++++++++++++++---------------------
 include/linux/io_uring.h |   2 +-
 kernel/fork.c            |   1 +
 5 files changed, 470 insertions(+), 397 deletions(-)

-- 
Jens Axboe

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

[Linus Torvalds]

On Fri, Mar 12, 2021 at 11:48 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> - Make IO threads unfreezable by default, on account of a bug report
>   that had them spinning on resume. Honestly not quite sure why thawing
>   leaves us with a perpetual signal pending (causing the spin), but for
>   now make them unfreezable like there were in 5.11 and prior.

That "not quite sure" doesn't exactly give my the warm and fuzzies,
but not being new is ok, I guess. But I'd really like you to try to
figure out what is actually going on.

I'm _guessing_ it's just that now those threads are user threads, and
then the freezing logic expects them to freeze/thaw using a signal
machinery or something like that. And that doesn't work when there is
no signal handling for those threads.

But it would be good to _know_.

            Linus

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

[Linus Torvalds]

On Fri, Mar 12, 2021 at 1:17 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'm _guessing_ it's just that now those threads are user threads, and
> then the freezing logic expects them to freeze/thaw using a signal
> machinery or something like that. And that doesn't work when there is
> no signal handling for those threads.

IOW, I think it's this logic in freeze_task():

        if (!(p->flags & PF_KTHREAD))
                fake_signal_wake_up(p);
        else
                wake_up_state(p, TASK_INTERRUPTIBLE);

where that "not a PF_KTHREAD" test will trigger for the io_uring
threads, and it does that fake_signal_wake_up(), and then
signal_wake_up() does that

        set_tsk_thread_flag(t, TIF_SIGPENDING);

but the io_uring thread has no way to react to it.

So now the io_uring thread will see "I have pending signals" (even if
there is no actual pending signal - it's just a way to get normal
processes to get out of TASK_INTERRUPTIBLE and return to user space
handling).

And the pending fake signal will never go away, because there is no
"return to user space" handling.

So I think the fix is to simply make freeze_task() not do that fake
signal thing for IO-uring threads either.

            Linus

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

[Linus Torvalds]

On Fri, Mar 12, 2021 at 1:24 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So I think the fix is to simply make freeze_task() not do that fake
> signal thing for IO-uring threads either.

Note: I've pulled your tree, I just want you to dig deeper, verify,
and check this for perhaps re-instating freezability.

              Linus

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

[Linus Torvalds]

On Fri, Mar 12, 2021 at 1:25 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Note: I've pulled your tree, I just want you to dig deeper, verify,
> and check this for perhaps re-instating freezability.

Also note that I don't think it's _just_ that freeze_task() thing that
is needed for the fix.

I think the io_uring threads then need to do the whole
"try_to_freeze()" dance in the main loop or something, so that it does
actually freeze.

           Linus

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

[Jens Axboe]

On 3/12/21 2:34 PM, Linus Torvalds wrote:
> On Fri, Mar 12, 2021 at 1:25 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Note: I've pulled your tree, I just want you to dig deeper, verify,
>> and check this for perhaps re-instating freezability.
> 
> Also note that I don't think it's _just_ that freeze_task() thing that
> is needed for the fix.
> 
> I think the io_uring threads then need to do the whole
> "try_to_freeze()" dance in the main loop or something, so that it does
> actually freeze.

Right, and they did before the change. The freezing did work, the thaw
just left us with that sigpending and caused the never-scheduler busy
behavior. But I'll unify it all when the thawing is sorted (which I
think it is), and then enable it for all three types.

-- 
Jens Axboe

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

[Jens Axboe]

On 3/12/21 2:24 PM, Linus Torvalds wrote:
> On Fri, Mar 12, 2021 at 1:17 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I'm _guessing_ it's just that now those threads are user threads, and
>> then the freezing logic expects them to freeze/thaw using a signal
>> machinery or something like that. And that doesn't work when there is
>> no signal handling for those threads.
> 
> IOW, I think it's this logic in freeze_task():
> 
>         if (!(p->flags & PF_KTHREAD))
>                 fake_signal_wake_up(p);
>         else
>                 wake_up_state(p, TASK_INTERRUPTIBLE);
> 
> where that "not a PF_KTHREAD" test will trigger for the io_uring
> threads, and it does that fake_signal_wake_up(), and then
> signal_wake_up() does that
> 
>         set_tsk_thread_flag(t, TIF_SIGPENDING);
> 
> but the io_uring thread has no way to react to it.
> 
> So now the io_uring thread will see "I have pending signals" (even if
> there is no actual pending signal - it's just a way to get normal
> processes to get out of TASK_INTERRUPTIBLE and return to user space
> handling).
> 
> And the pending fake signal will never go away, because there is no
> "return to user space" handling.
> 
> So I think the fix is to simply make freeze_task() not do that fake
> signal thing for IO-uring threads either.

Ah good catch, I missed it. Yes I bet this is exactly what it is, and
it just needs the one liner doing:

         if (!(p->flags & (PF_IO_WORKER | PF_KTHREAD)))
                 fake_signal_wake_up(p);
         else
                 wake_up_state(p, TASK_INTERRUPTIBLE);

instead. I'll try this out and test it, then we can drop the PF_NOFREEZE
business going forward. Thanks!

-- 
Jens Axboe

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

[Jens Axboe]

On 3/12/21 2:17 PM, Linus Torvalds wrote:
> On Fri, Mar 12, 2021 at 11:48 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> - Make IO threads unfreezable by default, on account of a bug report
>>   that had them spinning on resume. Honestly not quite sure why thawing
>>   leaves us with a perpetual signal pending (causing the spin), but for
>>   now make them unfreezable like there were in 5.11 and prior.
> 
> That "not quite sure" doesn't exactly give my the warm and fuzzies,
> but not being new is ok, I guess. But I'd really like you to try to
> figure out what is actually going on.

Oh I agree, which is why I wanted to bring it up as I do feel like we're
just working around this issue.

> I'm _guessing_ it's just that now those threads are user threads, and
> then the freezing logic expects them to freeze/thaw using a signal
> machinery or something like that. And that doesn't work when there is
> no signal handling for those threads.
> 
> But it would be good to _know_.

That's very much my guess too, since the symptom is that we loop all
the time because we think there's a signal pending. I am investigating
it and reached out to Rafael to try and figure this out, but at the same
time I did not want to have an -rc3 that caused resume issues for users.
Hence the "let's just disable freezing for now so that things work, get
it fixed for real when we can" kind of solution.

-- 
Jens Axboe

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

[pr-tracker-bot]

The pull request you sent on Fri, 12 Mar 2021 12:48:29 -0700:

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

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

Thank you!

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