* [GIT PULL] io_uring fixes for 5.6-rc
@ 2020-03-13 17:50 Jens Axboe
2020-03-13 20:18 ` Linus Torvalds
2020-03-13 20:25 ` pr-tracker-bot
0 siblings, 2 replies; 11+ messages in thread
From: Jens Axboe @ 2020-03-13 17:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [GIT PULL] io_uring fixes for 5.6-rc
2020-03-13 17:50 [GIT PULL] io_uring fixes for 5.6-rc Jens Axboe
@ 2020-03-13 20:18 ` Linus Torvalds
2020-03-13 20:33 ` Paul E. McKenney
2020-03-13 21:33 ` Jens Axboe
2020-03-13 20:25 ` pr-tracker-bot
1 sibling, 2 replies; 11+ messages in thread
From: Linus Torvalds @ 2020-03-13 20:18 UTC (permalink / raw)
To: Jens Axboe, Paul E. McKenney, Tejun Heo; +Cc: io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [GIT PULL] io_uring fixes for 5.6-rc
2020-03-13 20:18 ` Linus Torvalds
@ 2020-03-13 20:33 ` Paul E. McKenney
2020-03-13 21:33 ` Jens Axboe
1 sibling, 0 replies; 11+ messages in thread
From: Paul E. McKenney @ 2020-03-13 20:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jens Axboe, Tejun Heo, io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [GIT PULL] io_uring fixes for 5.6-rc
2020-03-13 20:18 ` Linus Torvalds
2020-03-13 20:33 ` Paul E. McKenney
@ 2020-03-13 21:33 ` Jens Axboe
1 sibling, 0 replies; 11+ messages in thread
From: Jens Axboe @ 2020-03-13 21:33 UTC (permalink / raw)
To: Linus Torvalds, Paul E. McKenney, Tejun Heo; +Cc: io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [GIT PULL] io_uring fixes for 5.6-rc
2020-03-13 17:50 [GIT PULL] io_uring fixes for 5.6-rc Jens Axboe
2020-03-13 20:18 ` Linus Torvalds
@ 2020-03-13 20:25 ` pr-tracker-bot
1 sibling, 0 replies; 11+ messages in thread
From: pr-tracker-bot @ 2020-03-13 20:25 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linus Torvalds, io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [GIT PULL] io_uring fixes for 5.6-rc
@ 2020-03-21 18:38 Jens Axboe
2020-03-21 19:15 ` pr-tracker-bot
0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2020-03-21 18:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread* [GIT PULL] io_uring fixes for 5.6-rc
@ 2020-03-07 19:16 Jens Axboe
2020-03-07 20:25 ` pr-tracker-bot
0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2020-03-07 19:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread* [GIT PULL] io_uring fixes for 5.6-rc
@ 2020-02-28 18:42 Jens Axboe
2020-02-28 19:55 ` pr-tracker-bot
0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2020-02-28 18:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: io-uring, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-03-21 19:15 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-13 17:50 [GIT PULL] io_uring fixes for 5.6-rc Jens Axboe
2020-03-13 20:18 ` Linus Torvalds
2020-03-13 20:33 ` Paul E. McKenney
2020-03-13 21:33 ` Jens Axboe
2020-03-13 20:25 ` pr-tracker-bot
-- strict thread matches above, loose matches on Subject: below --
2020-03-21 18:38 Jens Axboe
2020-03-21 19:15 ` pr-tracker-bot
2020-03-07 19:16 Jens Axboe
2020-03-07 20:25 ` pr-tracker-bot
2020-02-28 18:42 Jens Axboe
2020-02-28 19:55 ` pr-tracker-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).