[GIT PULL] io_uring fixes for 5.6-rc

[GIT PULL] io_uring fixes for 5.6-rc

[Jens Axboe]

Hi Linus,

Set of fixes for io_uring that should go into this release. This pull
request contains:

- Fix for a race with IOPOLL used with SQPOLL (Xiaoguang)

- Only show ->fdinfo if procfs is enabled (Tobias)

- Fix for a chain with multiple personalities in the SQEs

- Fix for a missing free of personality idr on exit

- Removal of the spin-for-work optimization

- Fix for next work lookup on request completion

- Fix for non-vec read/write result progation in case of links

- Fix for a fileset references on switch

- Fix for a recvmsg/sendmsg 32-bit compatability mode

Please pull!


  git://git.kernel.dk/linux-block.git tags/io_uring-5.6-2020-02-28


----------------------------------------------------------------
Jens Axboe (8):
      io_uring: handle multiple personalities in link chains
      io_uring: fix personality idr leak
      io-wq: remove spin-for-work optimization
      io-wq: ensure work->task_pid is cleared on init
      io_uring: pick up link work on submit reference drop
      io_uring: import_single_range() returns 0/-ERROR
      io_uring: drop file set ref put/get on switch
      io_uring: fix 32-bit compatability with sendmsg/recvmsg

Tobias Klauser (1):
      io_uring: define and set show_fdinfo only if procfs is enabled

Xiaoguang Wang (1):
      io_uring: fix poll_list race for SETUP_IOPOLL|SETUP_SQPOLL

 fs/io-wq.c    |  19 ---------
 fs/io-wq.h    |  14 ++-----
 fs/io_uring.c | 132 +++++++++++++++++++++++++++++++---------------------------
 3 files changed, 74 insertions(+), 91 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] io_uring fixes for 5.6-rc

[pr-tracker-bot]

The pull request you sent on Fri, 28 Feb 2020 11:42:44 -0700:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.6-2020-02-28

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

Thank you!

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

[GIT PULL] io_uring fixes for 5.6-rc

[Jens Axboe]

Hi Linus,

Here are a few io_uring fixes that should go into this release. This
pull request contains:

- Removal of (now) unused io_wq_flush() and associated flag (Pavel)

- Fix cancelation lockup with linked timeouts (Pavel)

- Fix for potential use-after-free when freeing percpu ref for fixed
  file sets

- io-wq cancelation fixups (Pavel)

Please pull!


  git://git.kernel.dk/linux-block.git tags/io_uring-5.6-2020-03-07


----------------------------------------------------------------
Jens Axboe (1):
      io_uring: free fixed_file_data after RCU grace period

Pavel Begunkov (3):
      io-wq: fix IO_WQ_WORK_NO_CANCEL cancellation
      io-wq: remove io_wq_flush and IO_WQ_WORK_INTERNAL
      io_uring: fix lockup with timeouts

 fs/io-wq.c    | 58 +++++++++++++++-------------------------------------------
 fs/io-wq.h    |  2 --
 fs/io_uring.c | 25 +++++++++++++++++++++++--
 3 files changed, 38 insertions(+), 47 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] io_uring fixes for 5.6-rc

[pr-tracker-bot]

The pull request you sent on Sat, 7 Mar 2020 12:16:34 -0700:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.6-2020-03-07

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

Thank you!

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

[GIT PULL] io_uring fixes for 5.6-rc

[Jens Axboe]

Hi Linus,

Just a single fix here, improving the RCU callback ordering from last
week. After a bit more perusing by Paul, he poked a hole in the
original.

Please pull!


  git://git.kernel.dk/linux-block.git tags/io_uring-5.6-2020-03-13


----------------------------------------------------------------
Jens Axboe (1):
      io_uring: ensure RCU callback ordering with rcu_barrier()

 fs/io_uring.c | 29 +++++++++++++----------------
 1 file changed, 13 insertions(+), 16 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] io_uring fixes for 5.6-rc

[Linus Torvalds]

On Fri, Mar 13, 2020 at 10:50 AM Jens Axboe <axboe@fb.com> wrote:
>
> Just a single fix here, improving the RCU callback ordering from last
> week. After a bit more perusing by Paul, he poked a hole in the
> original.

Ouch.

If I read this patch correctly, you're now adding a rcu_barrier() onto
the system workqueue for each io_uring context freeing op.

This makes me worry:

 - I think system_wq is unordered, so does it even guarantee that the
rcu_barrier happens after whatever work you're expecting it to be
after?

Or is it using a workqueue not because it wants to serialize with any
other work, but because it needs to use rcu_barrier in a context where
it can't sleep?

But the commit message does seem to imply that ordering is important..

 - doesn't this have the potential to flood the system_wq be full of
flushing things that all could take a while..

I've pulled it, and it may all be correct, just chalk this message up
to "Linus got nervous looking at it".

Added Paul and Tejun to the participants explicitly.

             Linus

Re: [GIT PULL] io_uring fixes for 5.6-rc

[pr-tracker-bot]

The pull request you sent on Fri, 13 Mar 2020 11:50:42 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.6-2020-03-13

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

Thank you!

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

Re: [GIT PULL] io_uring fixes for 5.6-rc

[Paul E. McKenney]

On Fri, Mar 13, 2020 at 01:18:30PM -0700, Linus Torvalds wrote:
> On Fri, Mar 13, 2020 at 10:50 AM Jens Axboe <axboe@fb.com> wrote:
> >
> > Just a single fix here, improving the RCU callback ordering from last
> > week. After a bit more perusing by Paul, he poked a hole in the
> > original.
> 
> Ouch.
> 
> If I read this patch correctly, you're now adding a rcu_barrier() onto
> the system workqueue for each io_uring context freeing op.
> 
> This makes me worry:
> 
>  - I think system_wq is unordered, so does it even guarantee that the
> rcu_barrier happens after whatever work you're expecting it to be
> after?
> 
> Or is it using a workqueue not because it wants to serialize with any
> other work, but because it needs to use rcu_barrier in a context where
> it can't sleep?
> 
> But the commit message does seem to imply that ordering is important..
> 
>  - doesn't this have the potential to flood the system_wq be full of
> flushing things that all could take a while..
> 
> I've pulled it, and it may all be correct, just chalk this message up
> to "Linus got nervous looking at it".
> 
> Added Paul and Tejun to the participants explicitly.

The idea is that rcu_barrier() waits for callbacks from all earlier
call_rcu()s to be invoked.  So as long as you know that the call_rcu()
happened earlier than the rcu_barrier(), the rcu_barrier() is guaranteed
to wait for that call_rcu()'s callback.

In this case (and Jens will correct me in the sadly likely event that
I get the story confused), we have a call_rcu() followed by scheduling
work on that same task.  The work has to start executing after it was
scheduled, so if that work does an rcu_barrier(), then that rcu_barrier()
will wait on the call_rcu()'s callback to be invoked.

Jens could invoke the rcu_barrier() just before scheduling the work,
but the synchronous delay from the rcu_barrier() is a problem.

Jens, what did I mess up in the above story?  ;-)

I defer to Jens and Tejun on the possibility of ending up with all
workqueue kthreads waiting on rcu_barrier().  If that is a problem,
there are some ways of dealing with it, though none that I can think of
that come for free.

							Thanx, Paul

Re: [GIT PULL] io_uring fixes for 5.6-rc

[Jens Axboe]

On 3/13/20 2:18 PM, Linus Torvalds wrote:
> On Fri, Mar 13, 2020 at 10:50 AM Jens Axboe <axboe@fb.com> wrote:
>>
>> Just a single fix here, improving the RCU callback ordering from last
>> week. After a bit more perusing by Paul, he poked a hole in the
>> original.
> 
> Ouch.
> 
> If I read this patch correctly, you're now adding a rcu_barrier() onto
> the system workqueue for each io_uring context freeing op.

It's actually not quite that bad, it's for every context that's used
registered file. That will generally be long term use cases, like server
backend kind of stuff, not for short lived or "normal" use cases.

> This makes me worry:
> 
>  - I think system_wq is unordered, so does it even guarantee that the
> rcu_barrier happens after whatever work you're expecting it to be
> after?

The ordering is wrt an rcu callback that's already queued. So we don't
care about ordering of other work at all, we just care about issuing
that rcu_barrier() before we exit + free, so we know that the existing
(if any) rcu callback has run.

> Or is it using a workqueue not because it wants to serialize with any
> other work, but because it needs to use rcu_barrier in a context where
> it can't sleep?

Really just using a workqueue because we already have one for this
particular item, and that takes the latency of needing the rcu barrier
out of the fast path for the application.

> But the commit message does seem to imply that ordering is important..

Only for a previous rcu callback, not for work items!

>  - doesn't this have the potential to flood the system_wq be full of
> flushing things that all could take a while..
> 
> I've pulled it, and it may all be correct, just chalk this message up
> to "Linus got nervous looking at it".

All good, always appreciate extra eyes on it! We could do the
rcu_barrier() inline and just take the hit there, and there's also room
to be a bit smarter and only do the barrier if we know we have to. But
since this is 5.6 material, I didn't want to complicate things further.

-- 
Jens Axboe

[GIT PULL] io_uring fixes for 5.6-rc

[Jens Axboe]

Hi Linus,

Two different fixes in here:

- Fix for a potential NULL pointer deref for links with async or drain
  marked (Pavel)

- Fix for not properly checking RLIMIT_NOFILE for async punted
  operations. This affects openat/openat2, which were added this cycle,
  and accept4. I did a full audit of other cases where we might check
  current->signal->rlim[] and found only RLIMIT_FSIZE for buffered
  writes and fallocate. That one is fixed and queued for 5.7 and marked
  stable.

Please pull!


  git://git.kernel.dk/linux-block.git tags/io_uring-5.6-20200320


----------------------------------------------------------------
Jens Axboe (2):
      io_uring: make sure openat/openat2 honor rlimit nofile
      io_uring: make sure accept honor rlimit nofile

Pavel Begunkov (1):
      io_uring: NULL-deref for IOSQE_{ASYNC,DRAIN}

 fs/file.c              |  7 ++++++-
 fs/io_uring.c          | 18 ++++++++++++++++--
 include/linux/file.h   |  1 +
 include/linux/socket.h |  3 ++-
 net/socket.c           |  8 +++++---
 5 files changed, 30 insertions(+), 7 deletions(-)

-- 
Jens Axboe

Re: [GIT PULL] io_uring fixes for 5.6-rc

[pr-tracker-bot]

The pull request you sent on Sat, 21 Mar 2020 12:38:34 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.6-20200320

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

Thank you!

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