2005-04-17 02:20:36 +04:00
/*
* An async IO implementation for Linux
* Written by Benjamin LaHaise < bcrl @ kvack . org >
*
* Implements an efficient asynchronous io interface .
*
* Copyright 2000 , 2001 , 2002 Red Hat , Inc . All Rights Reserved .
2018-07-16 10:08:20 +03:00
* Copyright 2018 Christoph Hellwig .
2005-04-17 02:20:36 +04:00
*
* See . . / COPYING for licensing terms .
*/
2013-05-08 03:18:35 +04:00
# define pr_fmt(fmt) "%s: " fmt, __func__
2005-04-17 02:20:36 +04:00
# include <linux/kernel.h>
# include <linux/init.h>
# include <linux/errno.h>
# include <linux/time.h>
# include <linux/aio_abi.h>
2011-11-17 08:57:37 +04:00
# include <linux/export.h>
2005-04-17 02:20:36 +04:00
# include <linux/syscalls.h>
2009-10-29 15:59:26 +03:00
# include <linux/backing-dev.h>
2018-07-24 12:36:37 +03:00
# include <linux/refcount.h>
2006-10-01 10:28:46 +04:00
# include <linux/uio.h>
2005-04-17 02:20:36 +04:00
2017-02-02 21:15:33 +03:00
# include <linux/sched/signal.h>
2005-04-17 02:20:36 +04:00
# include <linux/fs.h>
# include <linux/file.h>
# include <linux/mm.h>
# include <linux/mman.h>
2013-04-26 04:58:39 +04:00
# include <linux/percpu.h>
2005-04-17 02:20:36 +04:00
# include <linux/slab.h>
# include <linux/timer.h>
# include <linux/aio.h>
# include <linux/highmem.h>
# include <linux/workqueue.h>
# include <linux/security.h>
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 09:23:21 +04:00
# include <linux/eventfd.h>
2009-10-03 02:57:36 +04:00
# include <linux/blkdev.h>
2010-05-27 01:44:26 +04:00
# include <linux/compat.h>
2013-07-16 13:56:16 +04:00
# include <linux/migrate.h>
# include <linux/ramfs.h>
2013-05-29 02:14:48 +04:00
# include <linux/percpu-refcount.h>
2013-09-17 18:18:25 +04:00
# include <linux/mount.h>
2019-03-25 19:38:23 +03:00
# include <linux/pseudo_fs.h>
2005-04-17 02:20:36 +04:00
2016-12-24 22:46:01 +03:00
# include <linux/uaccess.h>
2018-12-11 20:37:49 +03:00
# include <linux/nospec.h>
2005-04-17 02:20:36 +04:00
2013-06-19 15:26:04 +04:00
# include "internal.h"
2018-03-30 12:19:25 +03:00
# define KIOCB_KEY 0
2013-05-08 03:18:33 +04:00
# define AIO_RING_MAGIC 0xa10a10a1
# define AIO_RING_COMPAT_FEATURES 1
# define AIO_RING_INCOMPAT_FEATURES 0
struct aio_ring {
unsigned id ; /* kernel internal index number */
unsigned nr ; /* number of io_events */
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
unsigned head ; /* Written to by userland or under ring_lock
* mutex by aio_read_events_ring ( ) . */
2013-05-08 03:18:33 +04:00
unsigned tail ;
unsigned magic ;
unsigned compat_features ;
unsigned incompat_features ;
unsigned header_length ; /* size of aio_ring */
2020-05-28 17:35:11 +03:00
struct io_event io_events [ ] ;
2013-05-08 03:18:33 +04:00
} ; /* 128 bytes + ring size */
2018-12-04 19:45:32 +03:00
/*
* Plugging is meant to work with larger batches of IOs . If we don ' t
* have more than the below , then don ' t bother setting up a plug .
*/
# define AIO_PLUG_THRESHOLD 2
2013-05-08 03:18:33 +04:00
# define AIO_RING_PAGES 8
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
struct kioctx_table {
2018-03-14 22:10:17 +03:00
struct rcu_head rcu ;
unsigned nr ;
struct kioctx __rcu * table [ ] ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
} ;
2013-04-26 04:58:39 +04:00
struct kioctx_cpu {
unsigned reqs_available ;
} ;
2015-04-15 20:17:23 +03:00
struct ctx_rq_wait {
struct completion comp ;
atomic_t count ;
} ;
2013-05-08 03:18:33 +04:00
struct kioctx {
2013-05-29 02:14:48 +04:00
struct percpu_ref users ;
2013-05-08 03:18:41 +04:00
atomic_t dead ;
2013-05-08 03:18:33 +04:00
2013-10-11 06:31:47 +04:00
struct percpu_ref reqs ;
2013-05-08 03:18:33 +04:00
unsigned long user_id ;
2013-04-26 04:58:39 +04:00
struct __percpu kioctx_cpu * cpu ;
/*
* For percpu reqs_available , number of slots we move to / from global
* counter at a time :
*/
unsigned req_batch ;
2013-05-08 03:18:51 +04:00
/*
* This is what userspace passed to io_setup ( ) , it ' s not used for
* anything but counting against the global max_reqs quota .
*
2013-05-08 03:18:55 +04:00
* The real limit is nr_events - 1 , which will be larger ( see
2013-05-08 03:18:51 +04:00
* aio_setup_ring ( ) )
*/
2013-05-08 03:18:33 +04:00
unsigned max_reqs ;
2013-05-08 03:18:55 +04:00
/* Size of ringbuffer, in units of struct io_event */
unsigned nr_events ;
2013-05-08 03:18:33 +04:00
2013-05-08 03:18:55 +04:00
unsigned long mmap_base ;
unsigned long mmap_size ;
struct page * * ring_pages ;
long nr_pages ;
2018-03-14 22:45:15 +03:00
struct rcu_work free_rwork ; /* see free_ioctx() */
2013-05-08 03:18:56 +04:00
2014-04-15 22:31:33 +04:00
/*
* signals when all in - flight requests are done
*/
2015-04-15 20:17:23 +03:00
struct ctx_rq_wait * rq_wait ;
2014-04-15 22:31:33 +04:00
2013-05-08 03:18:56 +04:00
struct {
2013-04-26 04:58:39 +04:00
/*
* This counts the number of available slots in the ringbuffer ,
* so we avoid overflowing it : it ' s decremented ( if positive )
* when allocating a kiocb and incremented when the resulting
* io_event is pulled off the ringbuffer .
2013-04-26 04:58:39 +04:00
*
* We batch accesses to it with a percpu version .
2013-04-26 04:58:39 +04:00
*/
atomic_t reqs_available ;
2013-05-08 03:18:56 +04:00
} ____cacheline_aligned_in_smp ;
struct {
spinlock_t ctx_lock ;
struct list_head active_reqs ; /* used for cancellation */
} ____cacheline_aligned_in_smp ;
2013-05-08 03:18:55 +04:00
struct {
struct mutex ring_lock ;
2013-05-08 03:18:56 +04:00
wait_queue_head_t wait ;
} ____cacheline_aligned_in_smp ;
2013-05-08 03:18:55 +04:00
struct {
unsigned tail ;
2014-08-24 21:14:05 +04:00
unsigned completed_events ;
2013-05-08 03:18:55 +04:00
spinlock_t completion_lock ;
2013-05-08 03:18:56 +04:00
} ____cacheline_aligned_in_smp ;
2013-05-08 03:18:55 +04:00
struct page * internal_pages [ AIO_RING_PAGES ] ;
2013-07-16 13:56:16 +04:00
struct file * aio_ring_file ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
unsigned id ;
2013-05-08 03:18:33 +04:00
} ;
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
/*
* First field must be the file pointer in all the
* iocb unions ! See also ' struct kiocb ' in < linux / fs . h >
*/
2018-03-27 20:18:57 +03:00
struct fsync_iocb {
struct file * file ;
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
struct work_struct work ;
2018-03-27 20:18:57 +03:00
bool datasync ;
2020-05-14 17:44:24 +03:00
struct cred * creds ;
2018-03-27 20:18:57 +03:00
} ;
2018-07-16 10:08:20 +03:00
struct poll_iocb {
struct file * file ;
struct wait_queue_head * head ;
__poll_t events ;
bool cancelled ;
2021-12-09 04:04:54 +03:00
bool work_scheduled ;
bool work_need_resched ;
2018-07-16 10:08:20 +03:00
struct wait_queue_entry wait ;
struct work_struct work ;
} ;
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
/*
* NOTE ! Each of the iocb union members has the file pointer
* as the first entry in their struct definition . So you can
* access the file pointer through any of the sub - structs ,
* or directly as just ' ki_filp ' in this struct .
*/
2015-02-02 16:49:06 +03:00
struct aio_kiocb {
2018-05-02 20:57:21 +03:00
union {
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
struct file * ki_filp ;
2018-05-02 20:57:21 +03:00
struct kiocb rw ;
2018-03-27 20:18:57 +03:00
struct fsync_iocb fsync ;
2018-07-16 10:08:20 +03:00
struct poll_iocb poll ;
2018-05-02 20:57:21 +03:00
} ;
2015-02-02 16:49:06 +03:00
struct kioctx * ki_ctx ;
kiocb_cancel_fn * ki_cancel ;
2019-03-08 03:43:45 +03:00
struct io_event ki_res ;
2015-02-02 16:49:06 +03:00
struct list_head ki_list ; /* the aio core uses this
* for cancellation */
2018-07-24 12:36:37 +03:00
refcount_t ki_refcnt ;
2015-02-02 16:49:06 +03:00
/*
* If the aio_resfd field of the userspace iocb is not zero ,
* this is the underlying eventfd context to deliver events to .
*/
struct eventfd_ctx * ki_eventfd ;
} ;
2005-04-17 02:20:36 +04:00
/*------ sysctl variables----*/
2005-11-07 11:59:31 +03:00
static DEFINE_SPINLOCK ( aio_nr_lock ) ;
2022-01-22 09:11:24 +03:00
static unsigned long aio_nr ; /* current system wide number of aio requests */
static unsigned long aio_max_nr = 0x10000 ; /* system wide maximum number of aio requests */
2005-04-17 02:20:36 +04:00
/*----end sysctl variables---*/
2022-01-22 09:11:24 +03:00
# ifdef CONFIG_SYSCTL
static struct ctl_table aio_sysctls [ ] = {
{
. procname = " aio-nr " ,
. data = & aio_nr ,
. maxlen = sizeof ( aio_nr ) ,
. mode = 0444 ,
. proc_handler = proc_doulongvec_minmax ,
} ,
{
. procname = " aio-max-nr " ,
. data = & aio_max_nr ,
. maxlen = sizeof ( aio_max_nr ) ,
. mode = 0644 ,
. proc_handler = proc_doulongvec_minmax ,
} ,
{ }
} ;
static void __init aio_sysctl_init ( void )
{
register_sysctl_init ( " fs " , aio_sysctls ) ;
}
# else
# define aio_sysctl_init() do { } while (0)
# endif
2005-04-17 02:20:36 +04:00
2006-12-07 07:33:20 +03:00
static struct kmem_cache * kiocb_cachep ;
static struct kmem_cache * kioctx_cachep ;
2005-04-17 02:20:36 +04:00
2013-09-17 18:18:25 +04:00
static struct vfsmount * aio_mnt ;
static const struct file_operations aio_ring_fops ;
static const struct address_space_operations aio_ctx_aops ;
static struct file * aio_private_file ( struct kioctx * ctx , loff_t nr_pages )
{
struct file * file ;
struct inode * inode = alloc_anon_inode ( aio_mnt - > mnt_sb ) ;
2013-11-13 11:49:40 +04:00
if ( IS_ERR ( inode ) )
return ERR_CAST ( inode ) ;
2013-09-17 18:18:25 +04:00
inode - > i_mapping - > a_ops = & aio_ctx_aops ;
inode - > i_mapping - > private_data = ctx ;
inode - > i_size = PAGE_SIZE * nr_pages ;
2018-06-09 16:40:05 +03:00
file = alloc_file_pseudo ( inode , aio_mnt , " [aio] " ,
O_RDWR , & aio_ring_fops ) ;
2018-07-11 21:19:04 +03:00
if ( IS_ERR ( file ) )
2013-09-17 18:18:25 +04:00
iput ( inode ) ;
return file ;
}
2019-03-25 19:38:23 +03:00
static int aio_init_fs_context ( struct fs_context * fc )
2013-09-17 18:18:25 +04:00
{
2019-03-25 19:38:23 +03:00
if ( ! init_pseudo ( fc , AIO_RING_MAGIC ) )
return - ENOMEM ;
fc - > s_iflags | = SB_I_NOEXEC ;
return 0 ;
2013-09-17 18:18:25 +04:00
}
2005-04-17 02:20:36 +04:00
/* aio_setup
* Creates the slab caches used by the aio routines , panic on
* failure as this is done early during the boot sequence .
*/
static int __init aio_setup ( void )
{
2013-09-17 18:18:25 +04:00
static struct file_system_type aio_fs = {
. name = " aio " ,
2019-03-25 19:38:23 +03:00
. init_fs_context = aio_init_fs_context ,
2013-09-17 18:18:25 +04:00
. kill_sb = kill_anon_super ,
} ;
aio_mnt = kern_mount ( & aio_fs ) ;
if ( IS_ERR ( aio_mnt ) )
panic ( " Failed to create aio fs mount. " ) ;
2015-02-02 16:49:06 +03:00
kiocb_cachep = KMEM_CACHE ( aio_kiocb , SLAB_HWCACHE_ALIGN | SLAB_PANIC ) ;
2007-05-07 01:49:57 +04:00
kioctx_cachep = KMEM_CACHE ( kioctx , SLAB_HWCACHE_ALIGN | SLAB_PANIC ) ;
2022-01-22 09:11:24 +03:00
aio_sysctl_init ( ) ;
2005-04-17 02:20:36 +04:00
return 0 ;
}
2009-09-23 03:43:53 +04:00
__initcall ( aio_setup ) ;
2005-04-17 02:20:36 +04:00
2013-09-27 04:34:51 +04:00
static void put_aio_ring_file ( struct kioctx * ctx )
{
struct file * aio_ring_file = ctx - > aio_ring_file ;
2016-09-15 01:25:03 +03:00
struct address_space * i_mapping ;
2013-09-27 04:34:51 +04:00
if ( aio_ring_file ) {
2016-12-05 02:24:56 +03:00
truncate_setsize ( file_inode ( aio_ring_file ) , 0 ) ;
2013-09-27 04:34:51 +04:00
/* Prevent further access to the kioctx from migratepages */
2016-12-05 02:24:56 +03:00
i_mapping = aio_ring_file - > f_mapping ;
2016-09-15 01:25:03 +03:00
spin_lock ( & i_mapping - > private_lock ) ;
i_mapping - > private_data = NULL ;
2013-09-27 04:34:51 +04:00
ctx - > aio_ring_file = NULL ;
2016-09-15 01:25:03 +03:00
spin_unlock ( & i_mapping - > private_lock ) ;
2013-09-27 04:34:51 +04:00
fput ( aio_ring_file ) ;
}
}
2005-04-17 02:20:36 +04:00
static void aio_free_ring ( struct kioctx * ctx )
{
2013-07-16 13:56:16 +04:00
int i ;
2005-04-17 02:20:36 +04:00
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* Disconnect the kiotx from the ring file. This prevents future
* accesses to the kioctx from page migration .
*/
put_aio_ring_file ( ctx ) ;
2013-07-16 13:56:16 +04:00
for ( i = 0 ; i < ctx - > nr_pages ; i + + ) {
2013-12-22 02:56:08 +04:00
struct page * page ;
2013-07-16 13:56:16 +04:00
pr_debug ( " pid(%d) [%d] page->count=%d \n " , current - > pid , i ,
page_count ( ctx - > ring_pages [ i ] ) ) ;
2013-12-22 02:56:08 +04:00
page = ctx - > ring_pages [ i ] ;
if ( ! page )
continue ;
ctx - > ring_pages [ i ] = NULL ;
put_page ( page ) ;
2013-07-16 13:56:16 +04:00
}
2005-04-17 02:20:36 +04:00
2013-11-20 02:33:03 +04:00
if ( ctx - > ring_pages & & ctx - > ring_pages ! = ctx - > internal_pages ) {
2013-05-08 03:18:55 +04:00
kfree ( ctx - > ring_pages ) ;
2013-11-20 02:33:03 +04:00
ctx - > ring_pages = NULL ;
}
2013-07-16 13:56:16 +04:00
}
2021-04-30 08:57:48 +03:00
static int aio_ring_mremap ( struct vm_area_struct * vma )
2014-09-18 19:56:17 +04:00
{
2015-09-05 01:48:04 +03:00
struct file * file = vma - > vm_file ;
2014-09-18 19:56:17 +04:00
struct mm_struct * mm = vma - > vm_mm ;
struct kioctx_table * table ;
2015-04-07 00:48:54 +03:00
int i , res = - EINVAL ;
2014-09-18 19:56:17 +04:00
spin_lock ( & mm - > ioctx_lock ) ;
rcu_read_lock ( ) ;
table = rcu_dereference ( mm - > ioctx_table ) ;
for ( i = 0 ; i < table - > nr ; i + + ) {
struct kioctx * ctx ;
2018-03-14 22:10:17 +03:00
ctx = rcu_dereference ( table - > table [ i ] ) ;
2014-09-18 19:56:17 +04:00
if ( ctx & & ctx - > aio_ring_file = = file ) {
2015-04-07 00:48:54 +03:00
if ( ! atomic_read ( & ctx - > dead ) ) {
ctx - > user_id = ctx - > mmap_base = vma - > vm_start ;
res = 0 ;
}
2014-09-18 19:56:17 +04:00
break ;
}
}
rcu_read_unlock ( ) ;
spin_unlock ( & mm - > ioctx_lock ) ;
2015-04-07 00:48:54 +03:00
return res ;
2014-09-18 19:56:17 +04:00
}
2015-09-05 01:48:04 +03:00
static const struct vm_operations_struct aio_ring_vm_ops = {
. mremap = aio_ring_mremap ,
# if IS_ENABLED(CONFIG_MMU)
. fault = filemap_fault ,
. map_pages = filemap_map_pages ,
. page_mkwrite = filemap_page_mkwrite ,
# endif
} ;
static int aio_ring_mmap ( struct file * file , struct vm_area_struct * vma )
{
vma - > vm_flags | = VM_DONTEXPAND ;
vma - > vm_ops = & aio_ring_vm_ops ;
return 0 ;
}
2013-07-16 13:56:16 +04:00
static const struct file_operations aio_ring_fops = {
. mmap = aio_ring_mmap ,
} ;
2013-07-17 17:34:24 +04:00
# if IS_ENABLED(CONFIG_MIGRATION)
2022-06-06 17:47:21 +03:00
static int aio_migrate_folio ( struct address_space * mapping , struct folio * dst ,
struct folio * src , enum migrate_mode mode )
2013-07-16 13:56:16 +04:00
{
2013-09-27 04:34:51 +04:00
struct kioctx * ctx ;
2013-07-16 13:56:16 +04:00
unsigned long flags ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
pgoff_t idx ;
2013-07-16 13:56:16 +04:00
int rc ;
2017-09-09 02:12:06 +03:00
/*
* We cannot support the _NO_COPY case here , because copy needs to
* happen under the ctx - > completion_lock . That does not work with the
* migration workflow of MIGRATE_SYNC_NO_COPY .
*/
if ( mode = = MIGRATE_SYNC_NO_COPY )
return - EINVAL ;
2013-12-22 02:56:08 +04:00
rc = 0 ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* mapping->private_lock here protects against the kioctx teardown. */
2013-12-22 02:56:08 +04:00
spin_lock ( & mapping - > private_lock ) ;
ctx = mapping - > private_data ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
if ( ! ctx ) {
rc = - EINVAL ;
goto out ;
}
/* The ring_lock mutex. The prevents aio_read_events() from writing
* to the ring ' s head , and prevents page migration from mucking in
* a partially initialized kiotx .
*/
if ( ! mutex_trylock ( & ctx - > ring_lock ) ) {
rc = - EAGAIN ;
goto out ;
}
2022-06-06 17:47:21 +03:00
idx = src - > index ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
if ( idx < ( pgoff_t ) ctx - > nr_pages ) {
2022-06-06 17:47:21 +03:00
/* Make sure the old folio hasn't already been changed */
if ( ctx - > ring_pages [ idx ] ! = & src - > page )
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
rc = - EAGAIN ;
2013-12-22 02:56:08 +04:00
} else
rc = - EINVAL ;
if ( rc ! = 0 )
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
goto out_unlock ;
2013-12-22 02:56:08 +04:00
2013-07-16 13:56:16 +04:00
/* Writeback must be complete */
2022-06-06 17:47:21 +03:00
BUG_ON ( folio_test_writeback ( src ) ) ;
folio_get ( dst ) ;
2013-07-16 13:56:16 +04:00
2022-06-06 17:47:21 +03:00
rc = folio_migrate_mapping ( mapping , dst , src , 1 ) ;
2013-07-16 13:56:16 +04:00
if ( rc ! = MIGRATEPAGE_SUCCESS ) {
2022-06-06 17:47:21 +03:00
folio_put ( dst ) ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
goto out_unlock ;
2013-07-16 13:56:16 +04:00
}
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* Take completion_lock to prevent other writes to the ring buffer
2022-06-06 17:47:21 +03:00
* while the old folio is copied to the new . This prevents new
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
* events from being lost .
2013-09-27 04:34:51 +04:00
*/
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
spin_lock_irqsave ( & ctx - > completion_lock , flags ) ;
2022-06-06 17:47:21 +03:00
folio_migrate_copy ( dst , src ) ;
BUG_ON ( ctx - > ring_pages [ idx ] ! = & src - > page ) ;
ctx - > ring_pages [ idx ] = & dst - > page ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
spin_unlock_irqrestore ( & ctx - > completion_lock , flags ) ;
2013-07-16 13:56:16 +04:00
2022-06-06 17:47:21 +03:00
/* The old folio is no longer accessible. */
folio_put ( src ) ;
2013-12-22 02:56:08 +04:00
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
out_unlock :
mutex_unlock ( & ctx - > ring_lock ) ;
out :
spin_unlock ( & mapping - > private_lock ) ;
2013-07-16 13:56:16 +04:00
return rc ;
2005-04-17 02:20:36 +04:00
}
2022-06-06 17:47:21 +03:00
# else
# define aio_migrate_folio NULL
2013-07-17 17:34:24 +04:00
# endif
2005-04-17 02:20:36 +04:00
2013-07-16 13:56:16 +04:00
static const struct address_space_operations aio_ctx_aops = {
2022-02-09 23:22:13 +03:00
. dirty_folio = noop_dirty_folio ,
2022-06-06 17:47:21 +03:00
. migrate_folio = aio_migrate_folio ,
2013-07-16 13:56:16 +04:00
} ;
2017-07-05 16:53:16 +03:00
static int aio_setup_ring ( struct kioctx * ctx , unsigned int nr_events )
2005-04-17 02:20:36 +04:00
{
struct aio_ring * ring ;
2013-05-08 03:18:25 +04:00
struct mm_struct * mm = current - > mm ;
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 00:11:12 +04:00
unsigned long size , unused ;
2005-04-17 02:20:36 +04:00
int nr_pages ;
2013-07-16 13:56:16 +04:00
int i ;
struct file * file ;
2005-04-17 02:20:36 +04:00
/* Compensate for the ring buffer's head/tail overlap entry */
nr_events + = 2 ; /* 1 is required, 2 for good luck */
size = sizeof ( struct aio_ring ) ;
size + = sizeof ( struct io_event ) * nr_events ;
2013-07-16 13:56:16 +04:00
nr_pages = PFN_UP ( size ) ;
2005-04-17 02:20:36 +04:00
if ( nr_pages < 0 )
return - EINVAL ;
2013-09-17 18:18:25 +04:00
file = aio_private_file ( ctx , nr_pages ) ;
2013-07-16 13:56:16 +04:00
if ( IS_ERR ( file ) ) {
ctx - > aio_ring_file = NULL ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
return - ENOMEM ;
2013-07-16 13:56:16 +04:00
}
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 00:11:12 +04:00
ctx - > aio_ring_file = file ;
nr_events = ( PAGE_SIZE * nr_pages - sizeof ( struct aio_ring ) )
/ sizeof ( struct io_event ) ;
ctx - > ring_pages = ctx - > internal_pages ;
if ( nr_pages > AIO_RING_PAGES ) {
ctx - > ring_pages = kcalloc ( nr_pages , sizeof ( struct page * ) ,
GFP_KERNEL ) ;
if ( ! ctx - > ring_pages ) {
put_aio_ring_file ( ctx ) ;
return - ENOMEM ;
}
}
2013-07-16 13:56:16 +04:00
for ( i = 0 ; i < nr_pages ; i + + ) {
struct page * page ;
2016-12-05 02:24:56 +03:00
page = find_or_create_page ( file - > f_mapping ,
2013-07-16 13:56:16 +04:00
i , GFP_HIGHUSER | __GFP_ZERO ) ;
if ( ! page )
break ;
pr_debug ( " pid(%d) page[%d]->count=%d \n " ,
current - > pid , i , page_count ( page ) ) ;
SetPageUptodate ( page ) ;
unlock_page ( page ) ;
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 00:11:12 +04:00
ctx - > ring_pages [ i ] = page ;
2013-07-16 13:56:16 +04:00
}
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 00:11:12 +04:00
ctx - > nr_pages = i ;
2005-04-17 02:20:36 +04:00
aio: clean up and fix aio_setup_ring page mapping
Since commit 36bc08cc01709 ("fs/aio: Add support to aio ring pages
migration") the aio ring setup code has used a special per-ring backing
inode for the page allocations, rather than just using random anonymous
pages.
However, rather than remembering the pages as it allocated them, it
would allocate the pages, insert them into the file mapping (dirty, so
that they couldn't be free'd), and then forget about them. And then to
look them up again, it would mmap the mapping, and then use
"get_user_pages()" to get back an array of the pages we just created.
Now, not only is that incredibly inefficient, it also leaked all the
pages if the mmap failed (which could happen due to excessive number of
mappings, for example).
So clean it all up, making it much more straightforward. Also remove
some left-overs of the previous (broken) mm_populate() usage that was
removed in commit d6c355c7dabc ("aio: fix race in ring buffer page
lookup introduced by page migration support") but left the pointless and
now misleading MAP_POPULATE flag around.
Tested-and-acked-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-20 00:11:12 +04:00
if ( unlikely ( i ! = nr_pages ) ) {
aio_free_ring ( ctx ) ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
return - ENOMEM ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:18:55 +04:00
ctx - > mmap_size = nr_pages * PAGE_SIZE ;
pr_debug ( " attempting mmap of %lu bytes \n " , ctx - > mmap_size ) ;
2013-07-16 13:56:16 +04:00
2020-06-09 07:33:25 +03:00
if ( mmap_write_lock_killable ( mm ) ) {
2016-05-24 02:25:59 +03:00
ctx - > mmap_size = 0 ;
aio_free_ring ( ctx ) ;
return - EINTR ;
}
2020-08-07 09:23:37 +03:00
ctx - > mmap_base = do_mmap ( ctx - > aio_ring_file , 0 , ctx - > mmap_size ,
PROT_READ | PROT_WRITE ,
MAP_SHARED , 0 , & unused , NULL ) ;
2020-06-09 07:33:25 +03:00
mmap_write_unlock ( mm ) ;
2013-05-08 03:18:55 +04:00
if ( IS_ERR ( ( void * ) ctx - > mmap_base ) ) {
ctx - > mmap_size = 0 ;
2005-04-17 02:20:36 +04:00
aio_free_ring ( ctx ) ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
return - ENOMEM ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:18:55 +04:00
pr_debug ( " mmap address: 0x%08lx \n " , ctx - > mmap_base ) ;
2013-09-09 19:57:59 +04:00
2013-05-08 03:18:55 +04:00
ctx - > user_id = ctx - > mmap_base ;
ctx - > nr_events = nr_events ; /* trusted copy */
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:55 +04:00
ring = kmap_atomic ( ctx - > ring_pages [ 0 ] ) ;
2005-04-17 02:20:36 +04:00
ring - > nr = nr_events ; /* user copy */
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
ring - > id = ~ 0U ;
2005-04-17 02:20:36 +04:00
ring - > head = ring - > tail = 0 ;
ring - > magic = AIO_RING_MAGIC ;
ring - > compat_features = AIO_RING_COMPAT_FEATURES ;
ring - > incompat_features = AIO_RING_INCOMPAT_FEATURES ;
ring - > header_length = sizeof ( struct aio_ring ) ;
2011-11-25 19:14:27 +04:00
kunmap_atomic ( ring ) ;
2013-05-08 03:18:55 +04:00
flush_dcache_page ( ctx - > ring_pages [ 0 ] ) ;
2005-04-17 02:20:36 +04:00
return 0 ;
}
# define AIO_EVENTS_PER_PAGE (PAGE_SIZE / sizeof(struct io_event))
# define AIO_EVENTS_FIRST_PAGE ((PAGE_SIZE - sizeof(struct aio_ring)) / sizeof(struct io_event))
# define AIO_EVENTS_OFFSET (AIO_EVENTS_PER_PAGE - AIO_EVENTS_FIRST_PAGE)
2015-02-02 16:49:06 +03:00
void kiocb_set_cancel_fn ( struct kiocb * iocb , kiocb_cancel_fn * cancel )
2013-05-08 03:18:49 +04:00
{
2018-05-02 20:57:21 +03:00
struct aio_kiocb * req = container_of ( iocb , struct aio_kiocb , rw ) ;
2013-05-08 03:18:49 +04:00
struct kioctx * ctx = req - > ki_ctx ;
unsigned long flags ;
2018-04-09 15:57:56 +03:00
if ( WARN_ON_ONCE ( ! list_empty ( & req - > ki_list ) ) )
return ;
2013-05-08 03:18:49 +04:00
2018-04-09 15:57:56 +03:00
spin_lock_irqsave ( & ctx - > ctx_lock , flags ) ;
list_add_tail ( & req - > ki_list , & ctx - > active_reqs ) ;
2013-05-08 03:18:49 +04:00
req - > ki_cancel = cancel ;
spin_unlock_irqrestore ( & ctx - > ctx_lock , flags ) ;
}
EXPORT_SYMBOL ( kiocb_set_cancel_fn ) ;
2018-03-14 22:10:17 +03:00
/*
* free_ioctx ( ) should be RCU delayed to synchronize against the RCU
* protected lookup_ioctx ( ) and also needs process context to call
2018-03-14 22:45:15 +03:00
* aio_free_ring ( ) . Use rcu_work .
2018-03-14 22:10:17 +03:00
*/
2013-10-11 06:31:47 +04:00
static void free_ioctx ( struct work_struct * work )
2013-05-08 03:18:41 +04:00
{
2018-03-14 22:45:15 +03:00
struct kioctx * ctx = container_of ( to_rcu_work ( work ) , struct kioctx ,
free_rwork ) ;
2013-10-11 06:31:47 +04:00
pr_debug ( " freeing %p \n " , ctx ) ;
2013-04-26 04:58:39 +04:00
2013-10-11 06:31:47 +04:00
aio_free_ring ( ctx ) ;
2013-04-26 04:58:39 +04:00
free_percpu ( ctx - > cpu ) ;
2014-06-28 16:10:14 +04:00
percpu_ref_exit ( & ctx - > reqs ) ;
percpu_ref_exit ( & ctx - > users ) ;
2013-05-08 03:18:41 +04:00
kmem_cache_free ( kioctx_cachep , ctx ) ;
}
2013-10-11 06:31:47 +04:00
static void free_ioctx_reqs ( struct percpu_ref * ref )
{
struct kioctx * ctx = container_of ( ref , struct kioctx , reqs ) ;
2014-04-15 22:31:33 +04:00
/* At this point we know that there are no any in-flight requests */
2015-04-15 20:17:23 +03:00
if ( ctx - > rq_wait & & atomic_dec_and_test ( & ctx - > rq_wait - > count ) )
complete ( & ctx - > rq_wait - > comp ) ;
2014-04-15 22:31:33 +04:00
2018-03-14 22:10:17 +03:00
/* Synchronize against RCU protected table->table[] dereferences */
2018-03-14 22:45:15 +03:00
INIT_RCU_WORK ( & ctx - > free_rwork , free_ioctx ) ;
queue_rcu_work ( system_wq , & ctx - > free_rwork ) ;
2013-10-11 06:31:47 +04:00
}
2013-05-08 03:18:41 +04:00
/*
* When this function runs , the kioctx has been removed from the " hash table "
* and ctx - > users has dropped to 0 , so we know no more kiocbs can be submitted -
* now it ' s safe to cancel any that need to be .
*/
2013-10-11 06:31:47 +04:00
static void free_ioctx_users ( struct percpu_ref * ref )
2013-05-08 03:18:41 +04:00
{
2013-10-11 06:31:47 +04:00
struct kioctx * ctx = container_of ( ref , struct kioctx , users ) ;
2015-02-02 16:49:06 +03:00
struct aio_kiocb * req ;
2013-05-08 03:18:41 +04:00
spin_lock_irq ( & ctx - > ctx_lock ) ;
while ( ! list_empty ( & ctx - > active_reqs ) ) {
req = list_first_entry ( & ctx - > active_reqs ,
2015-02-02 16:49:06 +03:00
struct aio_kiocb , ki_list ) ;
2018-05-23 15:11:02 +03:00
req - > ki_cancel ( & req - > rw ) ;
2018-05-24 05:53:22 +03:00
list_del_init ( & req - > ki_list ) ;
2013-05-08 03:18:41 +04:00
}
spin_unlock_irq ( & ctx - > ctx_lock ) ;
2013-10-11 06:31:47 +04:00
percpu_ref_kill ( & ctx - > reqs ) ;
percpu_ref_put ( & ctx - > reqs ) ;
2013-05-08 03:18:41 +04:00
}
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
static int ioctx_add_table ( struct kioctx * ctx , struct mm_struct * mm )
{
unsigned i , new_nr ;
struct kioctx_table * table , * old ;
struct aio_ring * ring ;
spin_lock ( & mm - > ioctx_lock ) ;
2014-04-30 18:16:36 +04:00
table = rcu_dereference_raw ( mm - > ioctx_table ) ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
while ( 1 ) {
if ( table )
for ( i = 0 ; i < table - > nr ; i + + )
2018-03-14 22:10:17 +03:00
if ( ! rcu_access_pointer ( table - > table [ i ] ) ) {
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
ctx - > id = i ;
2018-03-14 22:10:17 +03:00
rcu_assign_pointer ( table - > table [ i ] , ctx ) ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
spin_unlock ( & mm - > ioctx_lock ) ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* While kioctx setup is in progress,
* we are protected from page migration
* changes ring_pages by - > ring_lock .
*/
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
ring = kmap_atomic ( ctx - > ring_pages [ 0 ] ) ;
ring - > id = ctx - > id ;
kunmap_atomic ( ring ) ;
return 0 ;
}
new_nr = ( table ? table - > nr : 1 ) * 4 ;
spin_unlock ( & mm - > ioctx_lock ) ;
2021-09-19 12:45:39 +03:00
table = kzalloc ( struct_size ( table , table , new_nr ) , GFP_KERNEL ) ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
if ( ! table )
return - ENOMEM ;
table - > nr = new_nr ;
spin_lock ( & mm - > ioctx_lock ) ;
2014-04-30 18:16:36 +04:00
old = rcu_dereference_raw ( mm - > ioctx_table ) ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
if ( ! old ) {
rcu_assign_pointer ( mm - > ioctx_table , table ) ;
} else if ( table - > nr > old - > nr ) {
memcpy ( table - > table , old - > table ,
old - > nr * sizeof ( struct kioctx * ) ) ;
rcu_assign_pointer ( mm - > ioctx_table , table ) ;
kfree_rcu ( old , rcu ) ;
} else {
kfree ( table ) ;
table = old ;
}
}
}
2013-10-11 06:31:47 +04:00
static void aio_nr_sub ( unsigned nr )
{
spin_lock ( & aio_nr_lock ) ;
if ( WARN_ON ( aio_nr - nr > aio_nr ) )
aio_nr = 0 ;
else
aio_nr - = nr ;
spin_unlock ( & aio_nr_lock ) ;
}
2005-04-17 02:20:36 +04:00
/* ioctx_alloc
* Allocates and initializes an ioctx . Returns an ERR_PTR if it failed .
*/
static struct kioctx * ioctx_alloc ( unsigned nr_events )
{
2013-05-08 03:18:25 +04:00
struct mm_struct * mm = current - > mm ;
2005-04-17 02:20:36 +04:00
struct kioctx * ctx ;
2012-03-06 23:33:22 +04:00
int err = - ENOMEM ;
2005-04-17 02:20:36 +04:00
2017-07-05 16:53:16 +03:00
/*
* Store the original nr_events - - what userspace passed to io_setup ( ) ,
* for counting against the global limit - - before it changes .
*/
unsigned int max_reqs = nr_events ;
2013-04-26 04:58:39 +04:00
/*
* We keep track of the number of available ringbuffer slots , to prevent
* overflow ( reqs_available ) , and we also use percpu counters for this .
*
* So since up to half the slots might be on other cpu ' s percpu counters
* and unavailable , double nr_events so userspace sees what they
* expected : additionally , we move req_batch slots to / from percpu
* counters at a time , so make sure that isn ' t 0 :
*/
nr_events = max ( nr_events , num_possible_cpus ( ) * 4 ) ;
nr_events * = 2 ;
2005-04-17 02:20:36 +04:00
/* Prevent overflows */
2015-03-31 18:43:52 +03:00
if ( nr_events > ( 0x10000000U / sizeof ( struct io_event ) ) ) {
2005-04-17 02:20:36 +04:00
pr_debug ( " ENOMEM: nr_events too high \n " ) ;
return ERR_PTR ( - EINVAL ) ;
}
2017-07-05 16:53:16 +03:00
if ( ! nr_events | | ( unsigned long ) max_reqs > aio_max_nr )
2005-04-17 02:20:36 +04:00
return ERR_PTR ( - EAGAIN ) ;
2007-02-10 12:45:03 +03:00
ctx = kmem_cache_zalloc ( kioctx_cachep , GFP_KERNEL ) ;
2005-04-17 02:20:36 +04:00
if ( ! ctx )
return ERR_PTR ( - ENOMEM ) ;
2017-07-05 16:53:16 +03:00
ctx - > max_reqs = max_reqs ;
2005-04-17 02:20:36 +04:00
spin_lock_init ( & ctx - > ctx_lock ) ;
2013-05-08 03:18:49 +04:00
spin_lock_init ( & ctx - > completion_lock ) ;
2013-05-08 03:18:55 +04:00
mutex_init ( & ctx - > ring_lock ) ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* Protect against page migration throughout kiotx setup by keeping
* the ring_lock mutex held until setup is complete . */
mutex_lock ( & ctx - > ring_lock ) ;
2005-04-17 02:20:36 +04:00
init_waitqueue_head ( & ctx - > wait ) ;
INIT_LIST_HEAD ( & ctx - > active_reqs ) ;
2014-09-24 21:31:50 +04:00
if ( percpu_ref_init ( & ctx - > users , free_ioctx_users , 0 , GFP_KERNEL ) )
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
goto err ;
2014-09-24 21:31:50 +04:00
if ( percpu_ref_init ( & ctx - > reqs , free_ioctx_reqs , 0 , GFP_KERNEL ) )
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
goto err ;
2013-04-26 04:58:39 +04:00
ctx - > cpu = alloc_percpu ( struct kioctx_cpu ) ;
if ( ! ctx - > cpu )
2013-10-11 06:31:47 +04:00
goto err ;
2005-04-17 02:20:36 +04:00
2017-07-05 16:53:16 +03:00
err = aio_setup_ring ( ctx , nr_events ) ;
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
if ( err < 0 )
2013-10-11 06:31:47 +04:00
goto err ;
2013-04-26 04:58:39 +04:00
2013-04-26 04:58:39 +04:00
atomic_set ( & ctx - > reqs_available , ctx - > nr_events - 1 ) ;
2013-04-26 04:58:39 +04:00
ctx - > req_batch = ( ctx - > nr_events - 1 ) / ( num_possible_cpus ( ) * 4 ) ;
2013-07-31 18:34:18 +04:00
if ( ctx - > req_batch < 1 )
ctx - > req_batch = 1 ;
2013-04-26 04:58:39 +04:00
2005-04-17 02:20:36 +04:00
/* limit the number of system wide aios */
2012-03-11 08:14:05 +04:00
spin_lock ( & aio_nr_lock ) ;
2017-07-05 16:53:16 +03:00
if ( aio_nr + ctx - > max_reqs > aio_max_nr | |
aio_nr + ctx - > max_reqs < aio_nr ) {
2012-03-11 08:14:05 +04:00
spin_unlock ( & aio_nr_lock ) ;
2013-10-11 06:31:47 +04:00
err = - EAGAIN ;
2013-12-04 14:19:06 +04:00
goto err_ctx ;
2012-03-11 08:10:35 +04:00
}
aio_nr + = ctx - > max_reqs ;
2012-03-11 08:14:05 +04:00
spin_unlock ( & aio_nr_lock ) ;
2005-04-17 02:20:36 +04:00
2013-12-22 00:49:28 +04:00
percpu_ref_get ( & ctx - > users ) ; /* io_setup() will drop this ref */
percpu_ref_get ( & ctx - > reqs ) ; /* free_ioctx_users() will drop this */
2013-05-29 02:14:48 +04:00
2013-08-05 21:21:43 +04:00
err = ioctx_add_table ( ctx , mm ) ;
if ( err )
2013-10-11 06:31:47 +04:00
goto err_cleanup ;
2013-08-05 21:21:43 +04:00
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* Release the ring_lock mutex now that all setup is complete. */
mutex_unlock ( & ctx - > ring_lock ) ;
2013-05-08 03:18:35 +04:00
pr_debug ( " allocated ioctx %p[%ld]: mm=%p mask=0x%x \n " ,
2013-05-08 03:18:55 +04:00
ctx , ctx - > user_id , mm , ctx - > nr_events ) ;
2005-04-17 02:20:36 +04:00
return ctx ;
2013-10-11 06:31:47 +04:00
err_cleanup :
aio_nr_sub ( ctx - > max_reqs ) ;
2013-12-04 14:19:06 +04:00
err_ctx :
ioctx_alloc(): fix vma (and file) leak on failure
If we fail past the aio_setup_ring(), we need to destroy the
mapping. We don't need to care about anybody having found ctx,
or added requests to it, since the last failure exit is exactly
the failure to make ctx visible to lookups.
Reproducer (based on one by Joe Mario <jmario@redhat.com>):
void count(char *p)
{
char s[80];
printf("%s: ", p);
fflush(stdout);
sprintf(s, "/bin/cat /proc/%d/maps|/bin/fgrep -c '/[aio] (deleted)'", getpid());
system(s);
}
int main()
{
io_context_t *ctx;
int created, limit, i, destroyed;
FILE *f;
count("before");
if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL)
perror("opening aio-max-nr");
else if (fscanf(f, "%d", &limit) != 1)
fprintf(stderr, "can't parse aio-max-nr\n");
else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL)
perror("allocating aio_context_t array");
else {
for (i = 0, created = 0; i < limit; i++) {
if (io_setup(1000, ctx + created) == 0)
created++;
}
for (i = 0, destroyed = 0; i < created; i++)
if (io_destroy(ctx[i]) == 0)
destroyed++;
printf("created %d, failed %d, destroyed %d\n",
created, limit - created, destroyed);
count("after");
}
}
Found-by: Joe Mario <jmario@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-04-07 00:57:44 +03:00
atomic_set ( & ctx - > dead , 1 ) ;
if ( ctx - > mmap_size )
vm_munmap ( ctx - > mmap_base , ctx - > mmap_size ) ;
2013-12-04 14:19:06 +04:00
aio_free_ring ( ctx ) ;
2013-10-11 06:31:47 +04:00
err :
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
mutex_unlock ( & ctx - > ring_lock ) ;
2013-04-26 04:58:39 +04:00
free_percpu ( ctx - > cpu ) ;
2014-06-28 16:10:14 +04:00
percpu_ref_exit ( & ctx - > reqs ) ;
percpu_ref_exit ( & ctx - > users ) ;
2005-04-17 02:20:36 +04:00
kmem_cache_free ( kioctx_cachep , ctx ) ;
2013-05-08 03:18:35 +04:00
pr_debug ( " error allocating ioctx %d \n " , err ) ;
2012-03-06 23:33:22 +04:00
return ERR_PTR ( err ) ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:18:41 +04:00
/* kill_ioctx
* Cancels all outstanding aio requests on an aio context . Used
* when the processes owning a context have all exited to encourage
* the rapid destruction of the kioctx .
*/
2014-04-29 20:45:17 +04:00
static int kill_ioctx ( struct mm_struct * mm , struct kioctx * ctx ,
2015-04-15 20:17:23 +03:00
struct ctx_rq_wait * wait )
2013-05-08 03:18:41 +04:00
{
2014-04-29 20:55:48 +04:00
struct kioctx_table * table ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
2015-04-07 00:48:54 +03:00
spin_lock ( & mm - > ioctx_lock ) ;
if ( atomic_xchg ( & ctx - > dead , 1 ) ) {
spin_unlock ( & mm - > ioctx_lock ) ;
2014-04-29 20:55:48 +04:00
return - EINVAL ;
2015-04-07 00:48:54 +03:00
}
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
2014-04-30 18:16:36 +04:00
table = rcu_dereference_raw ( mm - > ioctx_table ) ;
2018-03-14 22:10:17 +03:00
WARN_ON ( ctx ! = rcu_access_pointer ( table - > table [ ctx - > id ] ) ) ;
RCU_INIT_POINTER ( table - > table [ ctx - > id ] , NULL ) ;
2014-04-29 20:55:48 +04:00
spin_unlock ( & mm - > ioctx_lock ) ;
2013-06-13 01:04:59 +04:00
2018-03-14 22:10:17 +03:00
/* free_ioctx_reqs() will do the necessary RCU synchronization */
2014-04-29 20:55:48 +04:00
wake_up_all ( & ctx - > wait ) ;
2013-06-13 01:04:59 +04:00
2014-04-29 20:55:48 +04:00
/*
* It ' d be more correct to do this in free_ioctx ( ) , after all
* the outstanding kiocbs have finished - but by then io_destroy
* has already returned , so io_setup ( ) could potentially return
* - EAGAIN with no ioctxs actually in use ( as far as userspace
* could tell ) .
*/
aio_nr_sub ( ctx - > max_reqs ) ;
2013-06-13 01:04:59 +04:00
2014-04-29 20:55:48 +04:00
if ( ctx - > mmap_size )
vm_munmap ( ctx - > mmap_base , ctx - > mmap_size ) ;
2014-04-29 20:45:17 +04:00
2015-04-15 20:17:23 +03:00
ctx - > rq_wait = wait ;
2014-04-29 20:55:48 +04:00
percpu_ref_kill ( & ctx - > users ) ;
return 0 ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:18:41 +04:00
/*
* exit_aio : called when the last user of mm goes away . At this point , there is
* no way for any new requests to be submited or any of the io_ * syscalls to be
* called on the context .
*
* There may be outstanding kiocbs , but free_ioctx ( ) will explicitly wait on
* them .
2005-04-17 02:20:36 +04:00
*/
2008-02-08 15:19:52 +03:00
void exit_aio ( struct mm_struct * mm )
2005-04-17 02:20:36 +04:00
{
aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
On 04/30, Benjamin LaHaise wrote:
>
> > - ctx->mmap_size = 0;
> > -
> > - kill_ioctx(mm, ctx, NULL);
> > + if (ctx) {
> > + ctx->mmap_size = 0;
> > + kill_ioctx(mm, ctx, NULL);
> > + }
>
> Rather than indenting and moving the two lines changing mmap_size and the
> kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces
> the number of lines changed and avoid excessive indentation.
OK. To me the code looks better/simpler with "if (ctx)", but this is subjective
of course, I won't argue.
The patch still removes the empty line between mmap_size = 0 and kill_ioctx(),
we reset mmap_size only for kill_ioctx(). But feel free to remove this change.
-------------------------------------------------------------------------------
Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
1. We can read ->ioctx_table only once and we do not read rcu_read_lock()
or even rcu_dereference().
This mm has no users, nobody else can play with ->ioctx_table. Otherwise
the code is buggy anyway, if we need rcu_read_lock() in a loop because
->ioctx_table can be updated then kfree(table) is obviously wrong.
2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid
munmap(), but another reason is that we simply can't do vm_munmap() unless
current->mm == mm and this is not true in general, the caller is mmput().
3. We do not really need to nullify mm->ioctx_table before return, probably
the current code does this to catch the potential problems. But in this
case RCU_INIT_POINTER(NULL) looks better.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-04-30 21:02:48 +04:00
struct kioctx_table * table = rcu_dereference_raw ( mm - > ioctx_table ) ;
2015-04-15 20:17:23 +03:00
struct ctx_rq_wait wait ;
int i , skipped ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
On 04/30, Benjamin LaHaise wrote:
>
> > - ctx->mmap_size = 0;
> > -
> > - kill_ioctx(mm, ctx, NULL);
> > + if (ctx) {
> > + ctx->mmap_size = 0;
> > + kill_ioctx(mm, ctx, NULL);
> > + }
>
> Rather than indenting and moving the two lines changing mmap_size and the
> kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces
> the number of lines changed and avoid excessive indentation.
OK. To me the code looks better/simpler with "if (ctx)", but this is subjective
of course, I won't argue.
The patch still removes the empty line between mmap_size = 0 and kill_ioctx(),
we reset mmap_size only for kill_ioctx(). But feel free to remove this change.
-------------------------------------------------------------------------------
Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
1. We can read ->ioctx_table only once and we do not read rcu_read_lock()
or even rcu_dereference().
This mm has no users, nobody else can play with ->ioctx_table. Otherwise
the code is buggy anyway, if we need rcu_read_lock() in a loop because
->ioctx_table can be updated then kfree(table) is obviously wrong.
2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid
munmap(), but another reason is that we simply can't do vm_munmap() unless
current->mm == mm and this is not true in general, the caller is mmput().
3. We do not really need to nullify mm->ioctx_table before return, probably
the current code does this to catch the potential problems. But in this
case RCU_INIT_POINTER(NULL) looks better.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-04-30 21:02:48 +04:00
if ( ! table )
return ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
2015-04-15 20:17:23 +03:00
atomic_set ( & wait . count , table - > nr ) ;
init_completion ( & wait . comp ) ;
skipped = 0 ;
aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
On 04/30, Benjamin LaHaise wrote:
>
> > - ctx->mmap_size = 0;
> > -
> > - kill_ioctx(mm, ctx, NULL);
> > + if (ctx) {
> > + ctx->mmap_size = 0;
> > + kill_ioctx(mm, ctx, NULL);
> > + }
>
> Rather than indenting and moving the two lines changing mmap_size and the
> kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces
> the number of lines changed and avoid excessive indentation.
OK. To me the code looks better/simpler with "if (ctx)", but this is subjective
of course, I won't argue.
The patch still removes the empty line between mmap_size = 0 and kill_ioctx(),
we reset mmap_size only for kill_ioctx(). But feel free to remove this change.
-------------------------------------------------------------------------------
Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
1. We can read ->ioctx_table only once and we do not read rcu_read_lock()
or even rcu_dereference().
This mm has no users, nobody else can play with ->ioctx_table. Otherwise
the code is buggy anyway, if we need rcu_read_lock() in a loop because
->ioctx_table can be updated then kfree(table) is obviously wrong.
2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid
munmap(), but another reason is that we simply can't do vm_munmap() unless
current->mm == mm and this is not true in general, the caller is mmput().
3. We do not really need to nullify mm->ioctx_table before return, probably
the current code does this to catch the potential problems. But in this
case RCU_INIT_POINTER(NULL) looks better.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-04-30 21:02:48 +04:00
for ( i = 0 ; i < table - > nr ; + + i ) {
2018-03-14 22:10:17 +03:00
struct kioctx * ctx =
rcu_dereference_protected ( table - > table [ i ] , true ) ;
2008-12-09 10:11:22 +03:00
2015-04-15 20:17:23 +03:00
if ( ! ctx ) {
skipped + + ;
aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
On 04/30, Benjamin LaHaise wrote:
>
> > - ctx->mmap_size = 0;
> > -
> > - kill_ioctx(mm, ctx, NULL);
> > + if (ctx) {
> > + ctx->mmap_size = 0;
> > + kill_ioctx(mm, ctx, NULL);
> > + }
>
> Rather than indenting and moving the two lines changing mmap_size and the
> kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces
> the number of lines changed and avoid excessive indentation.
OK. To me the code looks better/simpler with "if (ctx)", but this is subjective
of course, I won't argue.
The patch still removes the empty line between mmap_size = 0 and kill_ioctx(),
we reset mmap_size only for kill_ioctx(). But feel free to remove this change.
-------------------------------------------------------------------------------
Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
1. We can read ->ioctx_table only once and we do not read rcu_read_lock()
or even rcu_dereference().
This mm has no users, nobody else can play with ->ioctx_table. Otherwise
the code is buggy anyway, if we need rcu_read_lock() in a loop because
->ioctx_table can be updated then kfree(table) is obviously wrong.
2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid
munmap(), but another reason is that we simply can't do vm_munmap() unless
current->mm == mm and this is not true in general, the caller is mmput().
3. We do not really need to nullify mm->ioctx_table before return, probably
the current code does this to catch the potential problems. But in this
case RCU_INIT_POINTER(NULL) looks better.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-04-30 21:02:48 +04:00
continue ;
2015-04-15 20:17:23 +03:00
}
2012-04-21 05:49:41 +04:00
/*
aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
On 04/30, Benjamin LaHaise wrote:
>
> > - ctx->mmap_size = 0;
> > -
> > - kill_ioctx(mm, ctx, NULL);
> > + if (ctx) {
> > + ctx->mmap_size = 0;
> > + kill_ioctx(mm, ctx, NULL);
> > + }
>
> Rather than indenting and moving the two lines changing mmap_size and the
> kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces
> the number of lines changed and avoid excessive indentation.
OK. To me the code looks better/simpler with "if (ctx)", but this is subjective
of course, I won't argue.
The patch still removes the empty line between mmap_size = 0 and kill_ioctx(),
we reset mmap_size only for kill_ioctx(). But feel free to remove this change.
-------------------------------------------------------------------------------
Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
1. We can read ->ioctx_table only once and we do not read rcu_read_lock()
or even rcu_dereference().
This mm has no users, nobody else can play with ->ioctx_table. Otherwise
the code is buggy anyway, if we need rcu_read_lock() in a loop because
->ioctx_table can be updated then kfree(table) is obviously wrong.
2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid
munmap(), but another reason is that we simply can't do vm_munmap() unless
current->mm == mm and this is not true in general, the caller is mmput().
3. We do not really need to nullify mm->ioctx_table before return, probably
the current code does this to catch the potential problems. But in this
case RCU_INIT_POINTER(NULL) looks better.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-04-30 21:02:48 +04:00
* We don ' t need to bother with munmap ( ) here - exit_mmap ( mm )
* is coming and it ' ll unmap everything . And we simply can ' t ,
* this is not necessarily our - > mm .
* Since kill_ioctx ( ) uses non - zero - > mmap_size as indicator
* that it needs to unmap the area , just set it to 0.
2012-04-21 05:49:41 +04:00
*/
2013-05-08 03:18:55 +04:00
ctx - > mmap_size = 0 ;
2015-04-15 20:17:23 +03:00
kill_ioctx ( mm , ctx , & wait ) ;
}
2013-05-08 03:18:41 +04:00
2015-04-15 20:17:23 +03:00
if ( ! atomic_sub_and_test ( skipped , & wait . count ) ) {
2014-09-03 13:45:44 +04:00
/* Wait until all IO for the context are done. */
2015-04-15 20:17:23 +03:00
wait_for_completion ( & wait . comp ) ;
2005-04-17 02:20:36 +04:00
}
aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
On 04/30, Benjamin LaHaise wrote:
>
> > - ctx->mmap_size = 0;
> > -
> > - kill_ioctx(mm, ctx, NULL);
> > + if (ctx) {
> > + ctx->mmap_size = 0;
> > + kill_ioctx(mm, ctx, NULL);
> > + }
>
> Rather than indenting and moving the two lines changing mmap_size and the
> kill_ioctx() call, why not just do "if (!ctx) ... continue;"? That reduces
> the number of lines changed and avoid excessive indentation.
OK. To me the code looks better/simpler with "if (ctx)", but this is subjective
of course, I won't argue.
The patch still removes the empty line between mmap_size = 0 and kill_ioctx(),
we reset mmap_size only for kill_ioctx(). But feel free to remove this change.
-------------------------------------------------------------------------------
Subject: [PATCH v3 1/2] aio: change exit_aio() to load mm->ioctx_table once and avoid rcu_read_lock()
1. We can read ->ioctx_table only once and we do not read rcu_read_lock()
or even rcu_dereference().
This mm has no users, nobody else can play with ->ioctx_table. Otherwise
the code is buggy anyway, if we need rcu_read_lock() in a loop because
->ioctx_table can be updated then kfree(table) is obviously wrong.
2. Update the comment. "exit_mmap(mm) is coming" is the good reason to avoid
munmap(), but another reason is that we simply can't do vm_munmap() unless
current->mm == mm and this is not true in general, the caller is mmput().
3. We do not really need to nullify mm->ioctx_table before return, probably
the current code does this to catch the potential problems. But in this
case RCU_INIT_POINTER(NULL) looks better.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-04-30 21:02:48 +04:00
RCU_INIT_POINTER ( mm - > ioctx_table , NULL ) ;
kfree ( table ) ;
2005-04-17 02:20:36 +04:00
}
2013-04-26 04:58:39 +04:00
static void put_reqs_available ( struct kioctx * ctx , unsigned nr )
{
struct kioctx_cpu * kcpu ;
2014-07-14 20:49:26 +04:00
unsigned long flags ;
2013-04-26 04:58:39 +04:00
2014-07-14 20:49:26 +04:00
local_irq_save ( flags ) ;
2014-07-22 17:56:56 +04:00
kcpu = this_cpu_ptr ( ctx - > cpu ) ;
2013-04-26 04:58:39 +04:00
kcpu - > reqs_available + = nr ;
2014-07-14 20:49:26 +04:00
2013-04-26 04:58:39 +04:00
while ( kcpu - > reqs_available > = ctx - > req_batch * 2 ) {
kcpu - > reqs_available - = ctx - > req_batch ;
atomic_add ( ctx - > req_batch , & ctx - > reqs_available ) ;
}
2014-07-14 20:49:26 +04:00
local_irq_restore ( flags ) ;
2013-04-26 04:58:39 +04:00
}
2018-11-20 01:57:42 +03:00
static bool __get_reqs_available ( struct kioctx * ctx )
2013-04-26 04:58:39 +04:00
{
struct kioctx_cpu * kcpu ;
bool ret = false ;
2014-07-14 20:49:26 +04:00
unsigned long flags ;
2013-04-26 04:58:39 +04:00
2014-07-14 20:49:26 +04:00
local_irq_save ( flags ) ;
2014-07-22 17:56:56 +04:00
kcpu = this_cpu_ptr ( ctx - > cpu ) ;
2013-04-26 04:58:39 +04:00
if ( ! kcpu - > reqs_available ) {
2022-07-14 19:48:51 +03:00
int avail = atomic_read ( & ctx - > reqs_available ) ;
2013-04-26 04:58:39 +04:00
do {
if ( avail < ctx - > req_batch )
goto out ;
2022-07-14 19:48:51 +03:00
} while ( ! atomic_try_cmpxchg ( & ctx - > reqs_available ,
& avail , avail - ctx - > req_batch ) ) ;
2013-04-26 04:58:39 +04:00
kcpu - > reqs_available + = ctx - > req_batch ;
}
ret = true ;
kcpu - > reqs_available - - ;
out :
2014-07-14 20:49:26 +04:00
local_irq_restore ( flags ) ;
2013-04-26 04:58:39 +04:00
return ret ;
}
2014-08-24 21:14:05 +04:00
/* refill_reqs_available
* Updates the reqs_available reference counts used for tracking the
* number of free slots in the completion ring . This can be called
* from aio_complete ( ) ( to optimistically update reqs_available ) or
* from aio_get_req ( ) ( the we ' re out of events case ) . It must be
* called holding ctx - > completion_lock .
*/
static void refill_reqs_available ( struct kioctx * ctx , unsigned head ,
unsigned tail )
{
unsigned events_in_ring , completed ;
/* Clamp head since userland can write to it. */
head % = ctx - > nr_events ;
if ( head < = tail )
events_in_ring = tail - head ;
else
events_in_ring = ctx - > nr_events - ( head - tail ) ;
completed = ctx - > completed_events ;
if ( events_in_ring < completed )
completed - = events_in_ring ;
else
completed = 0 ;
if ( ! completed )
return ;
ctx - > completed_events - = completed ;
put_reqs_available ( ctx , completed ) ;
}
/* user_refill_reqs_available
* Called to refill reqs_available when aio_get_req ( ) encounters an
* out of space in the completion ring .
*/
static void user_refill_reqs_available ( struct kioctx * ctx )
{
spin_lock_irq ( & ctx - > completion_lock ) ;
if ( ctx - > completed_events ) {
struct aio_ring * ring ;
unsigned head ;
/* Access of ring->head may race with aio_read_events_ring()
* here , but that ' s okay since whether we read the old version
* or the new version , and either will be valid . The important
* part is that head cannot pass tail since we prevent
* aio_complete ( ) from updating tail by holding
* ctx - > completion_lock . Even if head is invalid , the check
* against ctx - > completed_events below will make sure we do the
* safe / right thing .
*/
ring = kmap_atomic ( ctx - > ring_pages [ 0 ] ) ;
head = ring - > head ;
kunmap_atomic ( ring ) ;
refill_reqs_available ( ctx , head , ctx - > tail ) ;
}
spin_unlock_irq ( & ctx - > completion_lock ) ;
}
2018-11-20 01:57:42 +03:00
static bool get_reqs_available ( struct kioctx * ctx )
{
if ( __get_reqs_available ( ctx ) )
return true ;
user_refill_reqs_available ( ctx ) ;
return __get_reqs_available ( ctx ) ;
}
2005-04-17 02:20:36 +04:00
/* aio_get_req
2013-05-14 00:42:52 +04:00
* Allocate a slot for an aio request .
* Returns NULL if no requests are free .
2019-03-07 04:22:54 +03:00
*
* The refcount is initialized to 2 - one for the async op completion ,
* one for the synchronous code that does this .
2005-04-17 02:20:36 +04:00
*/
2015-02-02 16:49:06 +03:00
static inline struct aio_kiocb * aio_get_req ( struct kioctx * ctx )
2005-04-17 02:20:36 +04:00
{
2015-02-02 16:49:06 +03:00
struct aio_kiocb * req ;
2013-05-08 03:18:53 +04:00
2018-12-04 19:44:49 +03:00
req = kmem_cache_alloc ( kiocb_cachep , GFP_KERNEL ) ;
2005-04-17 02:20:36 +04:00
if ( unlikely ( ! req ) )
2018-11-20 01:57:42 +03:00
return NULL ;
2005-04-17 02:20:36 +04:00
2019-03-07 02:21:08 +03:00
if ( unlikely ( ! get_reqs_available ( ctx ) ) ) {
2019-04-04 11:44:05 +03:00
kmem_cache_free ( kiocb_cachep , req ) ;
2019-03-07 02:21:08 +03:00
return NULL ;
}
2013-10-11 06:31:47 +04:00
percpu_ref_get ( & ctx - > reqs ) ;
2018-12-04 19:44:49 +03:00
req - > ki_ctx = ctx ;
2018-04-09 15:57:56 +03:00
INIT_LIST_HEAD ( & req - > ki_list ) ;
2019-03-07 04:22:54 +03:00
refcount_set ( & req - > ki_refcnt , 2 ) ;
2018-12-04 19:44:49 +03:00
req - > ki_eventfd = NULL ;
2011-11-03 00:40:10 +04:00
return req ;
2005-04-17 02:20:36 +04:00
}
2008-04-29 11:58:57 +04:00
static struct kioctx * lookup_ioctx ( unsigned long ctx_id )
2005-04-17 02:20:36 +04:00
{
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
struct aio_ring __user * ring = ( void __user * ) ctx_id ;
2008-12-09 10:11:22 +03:00
struct mm_struct * mm = current - > mm ;
2009-03-19 03:04:21 +03:00
struct kioctx * ctx , * ret = NULL ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
struct kioctx_table * table ;
unsigned id ;
if ( get_user ( id , & ring - > id ) )
return NULL ;
2005-04-17 02:20:36 +04:00
2008-12-09 10:11:22 +03:00
rcu_read_lock ( ) ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
table = rcu_dereference ( mm - > ioctx_table ) ;
2008-12-09 10:11:22 +03:00
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
if ( ! table | | id > = table - > nr )
goto out ;
2005-04-17 02:20:36 +04:00
2018-12-11 20:37:49 +03:00
id = array_index_nospec ( id , table - > nr ) ;
2018-03-14 22:10:17 +03:00
ctx = rcu_dereference ( table - > table [ id ] ) ;
2013-08-08 02:23:48 +04:00
if ( ctx & & ctx - > user_id = = ctx_id ) {
aio: fix io_destroy(2) vs. lookup_ioctx() race
kill_ioctx() used to have an explicit RCU delay between removing the
reference from ->ioctx_table and percpu_ref_kill() dropping the refcount.
At some point that delay had been removed, on the theory that
percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was
the wrong kind of RCU delay and it didn't care about rcu_read_lock() used
by lookup_ioctx(). As the result, we could get ctx freed right under
lookup_ioctx(). Tejun has fixed that in a6d7cff472e ("fs/aio: Add explicit
RCU grace period when freeing kioctx"); however, that fix is not enough.
Suppose io_destroy() from one thread races with e.g. io_setup() from another;
CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2
has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the
refcount, getting it to 0 and triggering a call of free_ioctx_users(),
which proceeds to drop the secondary refcount and once that reaches zero
calls free_ioctx_reqs(). That does
INIT_RCU_WORK(&ctx->free_rwork, free_ioctx);
queue_rcu_work(system_wq, &ctx->free_rwork);
and schedules freeing the whole thing after RCU delay.
In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the
refcount from 0 to 1 and returned the reference to io_setup().
Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get
freed until after percpu_ref_get(). Sure, we'd increment the counter before
ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to
stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it
has grabbed the reference, ctx is *NOT* going away until it gets around to
dropping that reference.
The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss.
It's not costlier than what we currently do in normal case, it's safe to
call since freeing *is* delayed and it closes the race window - either
lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users
won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx()
fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see
the object in question at all.
Cc: stable@kernel.org
Fixes: a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-20 23:46:23 +03:00
if ( percpu_ref_tryget_live ( & ctx - > users ) )
ret = ctx ;
aio: convert the ioctx list to table lookup v3
On Wed, Jun 12, 2013 at 11:14:40AM -0700, Kent Overstreet wrote:
> On Mon, Apr 15, 2013 at 02:40:55PM +0300, Octavian Purdila wrote:
> > When using a large number of threads performing AIO operations the
> > IOCTX list may get a significant number of entries which will cause
> > significant overhead. For example, when running this fio script:
> >
> > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=512; thread; loops=100
> >
> > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
> > 30% CPU time spent by lookup_ioctx:
> >
> > 32.51% [guest.kernel] [g] lookup_ioctx
> > 9.19% [guest.kernel] [g] __lock_acquire.isra.28
> > 4.40% [guest.kernel] [g] lock_release
> > 4.19% [guest.kernel] [g] sched_clock_local
> > 3.86% [guest.kernel] [g] local_clock
> > 3.68% [guest.kernel] [g] native_sched_clock
> > 3.08% [guest.kernel] [g] sched_clock_cpu
> > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11
> > 2.60% [guest.kernel] [g] memcpy
> > 2.33% [guest.kernel] [g] lock_acquired
> > 2.25% [guest.kernel] [g] lock_acquire
> > 1.84% [guest.kernel] [g] do_io_submit
> >
> > This patchs converts the ioctx list to a radix tree. For a performance
> > comparison the above FIO script was run on a 2 sockets 8 core
> > machine. This are the results (average and %rsd of 10 runs) for the
> > original list based implementation and for the radix tree based
> > implementation:
> >
> > cores 1 2 4 8 16 32
> > list 109376 ms 69119 ms 35682 ms 22671 ms 19724 ms 16408 ms
> > %rsd 0.69% 1.15% 1.17% 1.21% 1.71% 1.43%
> > radix 73651 ms 41748 ms 23028 ms 16766 ms 15232 ms 13787 ms
> > %rsd 1.19% 0.98% 0.69% 1.13% 0.72% 0.75%
> > % of radix
> > relative 66.12% 65.59% 66.63% 72.31% 77.26% 83.66%
> > to list
> >
> > To consider the impact of the patch on the typical case of having
> > only one ctx per process the following FIO script was run:
> >
> > rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
> > blocksize=1024; numjobs=1; thread; loops=100
> >
> > on the same system and the results are the following:
> >
> > list 58892 ms
> > %rsd 0.91%
> > radix 59404 ms
> > %rsd 0.81%
> > % of radix
> > relative 100.87%
> > to list
>
> So, I was just doing some benchmarking/profiling to get ready to send
> out the aio patches I've got for 3.11 - and it looks like your patch is
> causing a ~1.5% throughput regression in my testing :/
... <snip>
I've got an alternate approach for fixing this wart in lookup_ioctx()...
Instead of using an rbtree, just use the reserved id in the ring buffer
header to index an array pointing the ioctx. It's not finished yet, and
it needs to be tidied up, but is most of the way there.
-ben
--
"Thought is the essence of where you are now."
--
kmo> And, a rework of Ben's code, but this was entirely his idea
kmo> -Kent
bcrl> And fix the code to use the right mm_struct in kill_ioctx(), actually
free memory.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2013-07-30 20:54:40 +04:00
}
out :
2008-12-09 10:11:22 +03:00
rcu_read_unlock ( ) ;
2009-03-19 03:04:21 +03:00
return ret ;
2005-04-17 02:20:36 +04:00
}
2019-03-07 04:22:54 +03:00
static inline void iocb_destroy ( struct aio_kiocb * iocb )
{
2019-03-07 02:18:31 +03:00
if ( iocb - > ki_eventfd )
eventfd_ctx_put ( iocb - > ki_eventfd ) ;
2019-03-07 04:22:54 +03:00
if ( iocb - > ki_filp )
fput ( iocb - > ki_filp ) ;
percpu_ref_put ( & iocb - > ki_ctx - > reqs ) ;
kmem_cache_free ( kiocb_cachep , iocb ) ;
}
2005-04-17 02:20:36 +04:00
/* aio_complete
* Called when the io request on the given iocb is complete .
*/
2019-03-08 03:49:55 +03:00
static void aio_complete ( struct aio_kiocb * iocb )
2005-04-17 02:20:36 +04:00
{
struct kioctx * ctx = iocb - > ki_ctx ;
struct aio_ring * ring ;
2013-05-08 03:18:47 +04:00
struct io_event * ev_page , * event ;
2014-08-24 21:14:05 +04:00
unsigned tail , pos , head ;
2005-04-17 02:20:36 +04:00
unsigned long flags ;
2013-05-08 03:18:49 +04:00
/*
* Add a completion event to the ring buffer . Must be done holding
2013-07-04 02:09:16 +04:00
* ctx - > completion_lock to prevent other code from messing with the tail
2013-05-08 03:18:49 +04:00
* pointer since we might be called from irq context .
*/
spin_lock_irqsave ( & ctx - > completion_lock , flags ) ;
2013-05-08 03:18:55 +04:00
tail = ctx - > tail ;
2013-05-08 03:18:47 +04:00
pos = tail + AIO_EVENTS_OFFSET ;
2013-05-08 03:18:55 +04:00
if ( + + tail > = ctx - > nr_events )
2005-05-01 19:59:15 +04:00
tail = 0 ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:55 +04:00
ev_page = kmap_atomic ( ctx - > ring_pages [ pos / AIO_EVENTS_PER_PAGE ] ) ;
2013-05-08 03:18:47 +04:00
event = ev_page + pos % AIO_EVENTS_PER_PAGE ;
2019-03-08 03:43:45 +03:00
* event = iocb - > ki_res ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:47 +04:00
kunmap_atomic ( ev_page ) ;
2013-05-08 03:18:55 +04:00
flush_dcache_page ( ctx - > ring_pages [ pos / AIO_EVENTS_PER_PAGE ] ) ;
2013-05-08 03:18:47 +04:00
2019-03-08 03:43:45 +03:00
pr_debug ( " %p[%u]: %p: %p %Lx %Lx %Lx \n " , ctx , tail , iocb ,
( void __user * ) ( unsigned long ) iocb - > ki_res . obj ,
iocb - > ki_res . data , iocb - > ki_res . res , iocb - > ki_res . res2 ) ;
2005-04-17 02:20:36 +04:00
/* after flagging the request as done, we
* must never even look at it again
*/
smp_wmb ( ) ; /* make event visible before updating tail */
2013-05-08 03:18:55 +04:00
ctx - > tail = tail ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:55 +04:00
ring = kmap_atomic ( ctx - > ring_pages [ 0 ] ) ;
2014-08-24 21:14:05 +04:00
head = ring - > head ;
2013-05-08 03:18:47 +04:00
ring - > tail = tail ;
2011-11-25 19:14:27 +04:00
kunmap_atomic ( ring ) ;
2013-05-08 03:18:55 +04:00
flush_dcache_page ( ctx - > ring_pages [ 0 ] ) ;
2005-04-17 02:20:36 +04:00
2014-08-24 21:14:05 +04:00
ctx - > completed_events + + ;
if ( ctx - > completed_events > 1 )
refill_reqs_available ( ctx , head , tail ) ;
2013-05-08 03:18:49 +04:00
spin_unlock_irqrestore ( & ctx - > completion_lock , flags ) ;
2013-05-08 03:18:47 +04:00
pr_debug ( " added to ring %p at [%u] \n " , iocb , tail ) ;
2008-04-11 08:29:19 +04:00
/*
* Check if the user asked us to deliver the result through an
* eventfd . The eventfd_signal ( ) function is safe to be called
* from IRQ context .
*/
2019-03-07 02:18:31 +03:00
if ( iocb - > ki_eventfd )
2008-04-11 08:29:19 +04:00
eventfd_signal ( iocb - > ki_eventfd , 1 ) ;
aio: bad AIO race in aio_complete() leads to process hang
My group ran into a AIO process hang on a 2.6.24 kernel with the process
sleeping indefinitely in io_getevents(2) waiting for the last wakeup to come
and it never would.
We ran the tests on x86_64 SMP. The hang only occurred on a Xeon box
("Clovertown") but not a Core2Duo ("Conroe"). On the Xeon, the L2 cache isn't
shared between all eight processors, but is L2 is shared between between all
two processors on the Core2Duo we use.
My analysis of the hang is if you go down to the second while-loop
in read_events(), what happens on processor #1:
1) add_wait_queue_exclusive() adds thread to ctx->wait
2) aio_read_evt() to check tail
3) if aio_read_evt() returned 0, call [io_]schedule() and sleep
In aio_complete() with processor #2:
A) info->tail = tail;
B) waitqueue_active(&ctx->wait)
C) if waitqueue_active() returned non-0, call wake_up()
The way the code is written, step 1 must be seen by all other processors
before processor 1 checks for pending events in step 2 (that were recorded by
step A) and step A by processor 2 must be seen by all other processors
(checked in step 2) before step B is done.
The race I believed I was seeing is that steps 1 and 2 were
effectively swapped due to the __list_add() being delayed by the L2
cache not shared by some of the other processors. Imagine:
proc 2: just before step A
proc 1, step 1: adds to ctx->wait, but is not visible by other processors yet
proc 1, step 2: checks tail and sees no pending events
proc 2, step A: updates tail
proc 1, step 3: calls [io_]schedule() and sleeps
proc 2, step B: checks ctx->wait, but sees no one waiting, skips wakeup
so proc 1 sleeps indefinitely
My patch adds a memory barrier between steps A and B. It ensures that the
update in step 1 gets seen on processor 2 before continuing. If processor 1
was just before step 1, the memory barrier makes sure that step A (update
tail) gets seen by the time processor 1 makes it to step 2 (check tail).
Before the patch our AIO process would hang virtually 100% of the time. After
the patch, we have yet to see the process ever hang.
Signed-off-by: Quentin Barnes <qbarnes+linux@yahoo-inc.com>
Reviewed-by: Zach Brown <zach.brown@oracle.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: <stable@kernel.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ We should probably disallow that "if (waitqueue_active()) wake_up()"
coding pattern, because it's so often buggy wrt memory ordering ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-20 03:00:39 +03:00
/*
* We have to order our ring_info tail store above and test
* of the wait list below outside the wait lock . This is
* like in wake_up_bit ( ) where clearing a bit has to be
* ordered with the unlocked test .
*/
smp_mb ( ) ;
2005-04-17 02:20:36 +04:00
if ( waitqueue_active ( & ctx - > wait ) )
wake_up ( & ctx - > wait ) ;
2019-03-08 03:49:55 +03:00
}
static inline void iocb_put ( struct aio_kiocb * iocb )
{
if ( refcount_dec_and_test ( & iocb - > ki_refcnt ) ) {
aio_complete ( iocb ) ;
iocb_destroy ( iocb ) ;
}
2005-04-17 02:20:36 +04:00
}
2014-07-23 14:03:53 +04:00
/* aio_read_events_ring
2013-05-08 03:18:45 +04:00
* Pull an event off of the ioctx ' s event ring . Returns the number of
* events fetched
2005-04-17 02:20:36 +04:00
*/
2013-05-08 03:18:45 +04:00
static long aio_read_events_ring ( struct kioctx * ctx ,
struct io_event __user * event , long nr )
2005-04-17 02:20:36 +04:00
{
struct aio_ring * ring ;
2013-05-10 02:36:07 +04:00
unsigned head , tail , pos ;
2013-05-08 03:18:45 +04:00
long ret = 0 ;
int copy_ret ;
2015-02-04 03:29:05 +03:00
/*
* The mutex can block and wake us up and that will cause
* wait_event_interruptible_hrtimeout ( ) to schedule without sleeping
* and repeat . This should be rare enough that it doesn ' t cause
* peformance issues . See the comment in read_events ( ) for more detail .
*/
sched_annotate_sleep ( ) ;
2013-05-08 03:18:55 +04:00
mutex_lock ( & ctx - > ring_lock ) ;
2005-04-17 02:20:36 +04:00
aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration
As reported by Tang Chen, Gu Zheng and Yasuaki Isimatsu, the following issues
exist in the aio ring page migration support.
As a result, for example, we have the following problem:
thread 1 | thread 2
|
aio_migratepage() |
|-> take ctx->completion_lock |
|-> migrate_page_copy(new, old) |
| *NOW*, ctx->ring_pages[idx] == old |
|
| *NOW*, ctx->ring_pages[idx] == old
| aio_read_events_ring()
| |-> ring = kmap_atomic(ctx->ring_pages[0])
| |-> ring->head = head; *HERE, write to the old ring page*
| |-> kunmap_atomic(ring);
|
|-> ctx->ring_pages[idx] = new |
| *BUT NOW*, the content of |
| ring_pages[idx] is old. |
|-> release ctx->completion_lock |
As above, the new ring page will not be updated.
Fix this issue, as well as prevent races in aio_ring_setup() by holding
the ring_lock mutex during kioctx setup and page migration. This avoids
the overhead of taking another spinlock in aio_read_events_ring() as Tang's
and Gu's original fix did, pushing the overhead into the migration code.
Note that to handle the nesting of ring_lock inside of mmap_sem, the
migratepage operation uses mutex_trylock(). Page migration is not a 100%
critical operation in this case, so the ocassional failure can be
tolerated. This issue was reported by Sasha Levin.
Based on feedback from Linus, avoid the extra taking of ctx->completion_lock.
Instead, make page migration fully serialised by mapping->private_lock, and
have aio_free_ring() simply disconnect the kioctx from the mapping by calling
put_aio_ring_file() before touching ctx->ring_pages[]. This simplifies the
error handling logic in aio_migratepage(), and should improve robustness.
v4: always do mutex_unlock() in cases when kioctx setup fails.
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable@vger.kernel.org
2014-03-28 18:14:45 +04:00
/* Access to ->ring_pages here is protected by ctx->ring_lock. */
2013-05-08 03:18:55 +04:00
ring = kmap_atomic ( ctx - > ring_pages [ 0 ] ) ;
2013-05-08 03:18:45 +04:00
head = ring - > head ;
2013-05-10 02:36:07 +04:00
tail = ring - > tail ;
2013-05-08 03:18:45 +04:00
kunmap_atomic ( ring ) ;
2014-09-02 21:17:00 +04:00
/*
* Ensure that once we ' ve read the current tail pointer , that
* we also see the events that were stored up to the tail .
*/
smp_rmb ( ) ;
2013-05-10 02:36:07 +04:00
pr_debug ( " h%u t%u m%u \n " , head , tail , ctx - > nr_events ) ;
2005-04-17 02:20:36 +04:00
2013-05-10 02:36:07 +04:00
if ( head = = tail )
2005-04-17 02:20:36 +04:00
goto out ;
2014-06-24 21:32:51 +04:00
head % = ctx - > nr_events ;
tail % = ctx - > nr_events ;
2013-05-08 03:18:45 +04:00
while ( ret < nr ) {
long avail ;
struct io_event * ev ;
struct page * page ;
2013-05-10 02:36:07 +04:00
avail = ( head < = tail ? tail : ctx - > nr_events ) - head ;
if ( head = = tail )
2013-05-08 03:18:45 +04:00
break ;
pos = head + AIO_EVENTS_OFFSET ;
2013-05-08 03:18:55 +04:00
page = ctx - > ring_pages [ pos / AIO_EVENTS_PER_PAGE ] ;
2013-05-08 03:18:45 +04:00
pos % = AIO_EVENTS_PER_PAGE ;
2018-05-27 02:13:10 +03:00
avail = min ( avail , nr - ret ) ;
avail = min_t ( long , avail , AIO_EVENTS_PER_PAGE - pos ) ;
2013-05-08 03:18:45 +04:00
ev = kmap ( page ) ;
copy_ret = copy_to_user ( event + ret , ev + pos ,
sizeof ( * ev ) * avail ) ;
kunmap ( page ) ;
if ( unlikely ( copy_ret ) ) {
ret = - EFAULT ;
goto out ;
}
ret + = avail ;
head + = avail ;
2013-05-08 03:18:55 +04:00
head % = ctx - > nr_events ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:18:55 +04:00
ring = kmap_atomic ( ctx - > ring_pages [ 0 ] ) ;
2013-05-08 03:18:45 +04:00
ring - > head = head ;
2013-04-26 07:03:53 +04:00
kunmap_atomic ( ring ) ;
2013-05-08 03:18:55 +04:00
flush_dcache_page ( ctx - > ring_pages [ 0 ] ) ;
2013-05-08 03:18:45 +04:00
2013-05-10 02:36:07 +04:00
pr_debug ( " %li h%u t%u \n " , ret , head , tail ) ;
2013-05-08 03:18:45 +04:00
out :
2013-05-08 03:18:55 +04:00
mutex_unlock ( & ctx - > ring_lock ) ;
2013-05-08 03:18:45 +04:00
2005-04-17 02:20:36 +04:00
return ret ;
}
2013-05-08 03:18:45 +04:00
static bool aio_read_events ( struct kioctx * ctx , long min_nr , long nr ,
struct io_event __user * event , long * i )
2005-04-17 02:20:36 +04:00
{
2013-05-08 03:18:45 +04:00
long ret = aio_read_events_ring ( ctx , event + * i , nr - * i ) ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
if ( ret > 0 )
* i + = ret ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
if ( unlikely ( atomic_read ( & ctx - > dead ) ) )
ret = - EINVAL ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
if ( ! * i )
* i = ret ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
return ret < 0 | | * i > = min_nr ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:18:45 +04:00
static long read_events ( struct kioctx * ctx , long min_nr , long nr ,
2005-04-17 02:20:36 +04:00
struct io_event __user * event ,
2017-08-05 07:12:32 +03:00
ktime_t until )
2005-04-17 02:20:36 +04:00
{
2013-05-08 03:18:45 +04:00
long ret = 0 ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
/*
* Note that aio_read_events ( ) is being called as the conditional - i . e .
* we ' re calling it after prepare_to_wait ( ) has set task state to
* TASK_INTERRUPTIBLE .
*
* But aio_read_events ( ) can block , and if it blocks it ' s going to flip
* the task state back to TASK_RUNNING .
*
* This should be ok , provided it doesn ' t flip the state back to
* TASK_RUNNING and return 0 too much - that causes us to spin . That
* will only happen if the mutex_lock ( ) call blocks , and we then find
* the ringbuffer empty . So in practice we should be ok , but it ' s
* something to be aware of when touching this code .
*/
2016-12-25 13:38:40 +03:00
if ( until = = 0 )
2014-11-06 15:44:36 +03:00
aio_read_events ( ctx , min_nr , nr , event , & ret ) ;
else
wait_event_interruptible_hrtimeout ( ctx - > wait ,
aio_read_events ( ctx , min_nr , nr , event , & ret ) ,
until ) ;
2013-05-08 03:18:45 +04:00
return ret ;
2005-04-17 02:20:36 +04:00
}
/* sys_io_setup:
* Create an aio_context capable of receiving at least nr_events .
* ctxp must not point to an aio_context that already exists , and
* must be initialized to 0 prior to the call . On successful
* creation of the aio_context , * ctxp is filled in with the resulting
* handle . May fail with - EINVAL if * ctxp is not initialized ,
* if the specified nr_events exceeds internal limits . May fail
* with - EAGAIN if the specified nr_events exceeds the user ' s limit
* of available events . May fail with - ENOMEM if insufficient kernel
* resources are available . May fail with - EFAULT if an invalid
* pointer is passed for ctxp . Will fail with - ENOSYS if not
* implemented .
*/
2009-01-14 16:14:18 +03:00
SYSCALL_DEFINE2 ( io_setup , unsigned , nr_events , aio_context_t __user * , ctxp )
2005-04-17 02:20:36 +04:00
{
struct kioctx * ioctx = NULL ;
unsigned long ctx ;
long ret ;
ret = get_user ( ctx , ctxp ) ;
if ( unlikely ( ret ) )
goto out ;
ret = - EINVAL ;
2005-11-07 11:59:31 +03:00
if ( unlikely ( ctx | | nr_events = = 0 ) ) {
2015-02-04 16:15:59 +03:00
pr_debug ( " EINVAL: ctx %lu nr_events %u \n " ,
2005-11-07 11:59:31 +03:00
ctx , nr_events ) ;
2005-04-17 02:20:36 +04:00
goto out ;
}
ioctx = ioctx_alloc ( nr_events ) ;
ret = PTR_ERR ( ioctx ) ;
if ( ! IS_ERR ( ioctx ) ) {
ret = put_user ( ioctx - > user_id , ctxp ) ;
2012-03-21 00:27:57 +04:00
if ( ret )
2014-04-15 22:31:33 +04:00
kill_ioctx ( current - > mm , ioctx , NULL ) ;
2013-05-29 02:14:48 +04:00
percpu_ref_put ( & ioctx - > users ) ;
2005-04-17 02:20:36 +04:00
}
out :
return ret ;
}
2016-12-20 15:04:57 +03:00
# ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE2 ( io_setup , unsigned , nr_events , u32 __user * , ctx32p )
{
struct kioctx * ioctx = NULL ;
unsigned long ctx ;
long ret ;
ret = get_user ( ctx , ctx32p ) ;
if ( unlikely ( ret ) )
goto out ;
ret = - EINVAL ;
if ( unlikely ( ctx | | nr_events = = 0 ) ) {
pr_debug ( " EINVAL: ctx %lu nr_events %u \n " ,
ctx , nr_events ) ;
goto out ;
}
ioctx = ioctx_alloc ( nr_events ) ;
ret = PTR_ERR ( ioctx ) ;
if ( ! IS_ERR ( ioctx ) ) {
/* truncating is ok because it's a user address */
ret = put_user ( ( u32 ) ioctx - > user_id , ctx32p ) ;
if ( ret )
kill_ioctx ( current - > mm , ioctx , NULL ) ;
percpu_ref_put ( & ioctx - > users ) ;
}
out :
return ret ;
}
# endif
2005-04-17 02:20:36 +04:00
/* sys_io_destroy:
* Destroy the aio_context specified . May cancel any outstanding
* AIOs and block on completion . Will fail with - ENOSYS if not
2010-08-05 22:23:11 +04:00
* implemented . May fail with - EINVAL if the context pointed to
2005-04-17 02:20:36 +04:00
* is invalid .
*/
2009-01-14 16:14:18 +03:00
SYSCALL_DEFINE1 ( io_destroy , aio_context_t , ctx )
2005-04-17 02:20:36 +04:00
{
struct kioctx * ioctx = lookup_ioctx ( ctx ) ;
if ( likely ( NULL ! = ioctx ) ) {
2015-04-15 20:17:23 +03:00
struct ctx_rq_wait wait ;
2014-04-29 20:45:17 +04:00
int ret ;
2014-04-15 22:31:33 +04:00
2015-04-15 20:17:23 +03:00
init_completion ( & wait . comp ) ;
atomic_set ( & wait . count , 1 ) ;
2014-04-15 22:31:33 +04:00
/* Pass requests_done to kill_ioctx() where it can be set
* in a thread - safe way . If we try to set it here then we have
* a race condition if two io_destroy ( ) called simultaneously .
*/
2015-04-15 20:17:23 +03:00
ret = kill_ioctx ( current - > mm , ioctx , & wait ) ;
2013-05-29 02:14:48 +04:00
percpu_ref_put ( & ioctx - > users ) ;
2014-04-15 22:31:33 +04:00
/* Wait until all IO for the context are done. Otherwise kernel
* keep using user - space buffers even if user thinks the context
* is destroyed .
*/
2014-04-29 20:45:17 +04:00
if ( ! ret )
2015-04-15 20:17:23 +03:00
wait_for_completion ( & wait . comp ) ;
2014-04-15 22:31:33 +04:00
2014-04-29 20:45:17 +04:00
return ret ;
2005-04-17 02:20:36 +04:00
}
2015-02-04 16:15:59 +03:00
pr_debug ( " EINVAL: invalid context id \n " ) ;
2005-04-17 02:20:36 +04:00
return - EINVAL ;
}
2018-05-28 20:37:43 +03:00
static void aio_remove_iocb ( struct aio_kiocb * iocb )
{
struct kioctx * ctx = iocb - > ki_ctx ;
unsigned long flags ;
spin_lock_irqsave ( & ctx - > ctx_lock , flags ) ;
list_del ( & iocb - > ki_list ) ;
spin_unlock_irqrestore ( & ctx - > ctx_lock , flags ) ;
}
2021-10-21 18:22:35 +03:00
static void aio_complete_rw ( struct kiocb * kiocb , long res )
2018-05-02 20:57:21 +03:00
{
struct aio_kiocb * iocb = container_of ( kiocb , struct aio_kiocb , rw ) ;
2018-05-28 20:37:43 +03:00
if ( ! list_empty_careful ( & iocb - > ki_list ) )
aio_remove_iocb ( iocb ) ;
2018-05-02 20:57:21 +03:00
if ( kiocb - > ki_flags & IOCB_WRITE ) {
struct inode * inode = file_inode ( kiocb - > ki_filp ) ;
/*
* Tell lockdep we inherited freeze protection from submission
* thread .
*/
if ( S_ISREG ( inode - > i_mode ) )
__sb_writers_acquired ( inode - > i_sb , SB_FREEZE_WRITE ) ;
file_end_write ( kiocb - > ki_filp ) ;
}
2019-03-08 03:49:55 +03:00
iocb - > ki_res . res = res ;
2021-10-21 18:22:35 +03:00
iocb - > ki_res . res2 = 0 ;
2019-03-08 03:49:55 +03:00
iocb_put ( iocb ) ;
2018-05-02 20:57:21 +03:00
}
2018-11-25 00:46:14 +03:00
static int aio_prep_rw ( struct kiocb * req , const struct iocb * iocb )
2018-05-02 20:57:21 +03:00
{
int ret ;
req - > ki_complete = aio_complete_rw ;
2019-02-05 22:13:35 +03:00
req - > private = NULL ;
2018-05-02 20:57:21 +03:00
req - > ki_pos = iocb - > aio_offset ;
2022-05-22 18:38:11 +03:00
req - > ki_flags = req - > ki_filp - > f_iocb_flags ;
2018-05-02 20:57:21 +03:00
if ( iocb - > aio_flags & IOCB_FLAG_RESFD )
req - > ki_flags | = IOCB_EVENTFD ;
2018-05-22 20:52:19 +03:00
if ( iocb - > aio_flags & IOCB_FLAG_IOPRIO ) {
/*
* If the IOCB_FLAG_IOPRIO flag of aio_flags is set , then
* aio_reqprio is interpreted as an I / O scheduling
* class and priority .
*/
ret = ioprio_check_cap ( iocb - > aio_reqprio ) ;
if ( ret ) {
2018-06-04 20:59:57 +03:00
pr_debug ( " aio ioprio check cap error: %d \n " , ret ) ;
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return ret ;
2018-05-22 20:52:19 +03:00
}
req - > ki_ioprio = iocb - > aio_reqprio ;
} else
2018-11-20 04:52:36 +03:00
req - > ki_ioprio = get_current_ioprio ( ) ;
2018-05-22 20:52:19 +03:00
2018-05-02 20:57:21 +03:00
ret = kiocb_set_rw_flags ( req , iocb - > aio_rw_flags ) ;
if ( unlikely ( ret ) )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return ret ;
2018-11-22 18:44:07 +03:00
req - > ki_flags & = ~ IOCB_HIPRI ; /* no one is going to poll for this I/O */
return 0 ;
2018-05-02 20:57:21 +03:00
}
2019-05-15 01:02:22 +03:00
static ssize_t aio_setup_rw ( int rw , const struct iocb * iocb ,
struct iovec * * iovec , bool vectored , bool compat ,
struct iov_iter * iter )
2006-10-01 10:28:49 +04:00
{
2016-10-30 19:42:03 +03:00
void __user * buf = ( void __user * ) ( uintptr_t ) iocb - > aio_buf ;
size_t len = iocb - > aio_nbytes ;
if ( ! vectored ) {
ssize_t ret = import_single_range ( rw , buf , len , * iovec , iter ) ;
* iovec = NULL ;
return ret ;
}
2020-09-25 07:51:41 +03:00
return __import_iovec ( rw , buf , len , UIO_FASTIOV , iovec , iter , compat ) ;
2006-10-01 10:28:49 +04:00
}
2018-05-27 02:11:40 +03:00
static inline void aio_rw_done ( struct kiocb * req , ssize_t ret )
2016-10-30 19:42:03 +03:00
{
switch ( ret ) {
case - EIOCBQUEUED :
2018-05-27 02:11:40 +03:00
break ;
2016-10-30 19:42:03 +03:00
case - ERESTARTSYS :
case - ERESTARTNOINTR :
case - ERESTARTNOHAND :
case - ERESTART_RESTARTBLOCK :
/*
* There ' s no easy way to restart the syscall since other AIO ' s
* may be already running . Just fail this IO with EINTR .
*/
ret = - EINTR ;
2020-08-24 01:36:59 +03:00
fallthrough ;
2016-10-30 19:42:03 +03:00
default :
2021-10-21 18:22:35 +03:00
req - > ki_complete ( req , ret ) ;
2016-10-30 19:42:03 +03:00
}
}
2019-03-07 02:13:00 +03:00
static int aio_read ( struct kiocb * req , const struct iocb * iocb ,
2018-11-25 00:46:14 +03:00
bool vectored , bool compat )
2005-04-17 02:20:36 +04:00
{
2014-07-23 14:03:54 +04:00
struct iovec inline_vecs [ UIO_FASTIOV ] , * iovec = inline_vecs ;
2014-02-12 03:37:41 +04:00
struct iov_iter iter ;
2018-05-02 20:57:21 +03:00
struct file * file ;
2019-03-07 02:13:00 +03:00
int ret ;
2005-04-17 02:20:36 +04:00
2018-05-02 20:57:21 +03:00
ret = aio_prep_rw ( req , iocb ) ;
if ( ret )
return ret ;
file = req - > ki_filp ;
2016-10-30 19:42:03 +03:00
if ( unlikely ( ! ( file - > f_mode & FMODE_READ ) ) )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return - EBADF ;
2016-10-30 19:42:03 +03:00
if ( unlikely ( ! file - > f_op - > read_iter ) )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return - EINVAL ;
2013-05-10 02:03:42 +04:00
2016-10-30 19:42:03 +03:00
ret = aio_setup_rw ( READ , iocb , & iovec , vectored , compat , & iter ) ;
2019-05-15 01:02:22 +03:00
if ( ret < 0 )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return ret ;
2016-10-30 19:42:03 +03:00
ret = rw_verify_area ( READ , file , & req - > ki_pos , iov_iter_count ( & iter ) ) ;
if ( ! ret )
2018-05-27 02:11:40 +03:00
aio_rw_done ( req , call_read_iter ( file , req , & iter ) ) ;
2016-10-30 19:42:03 +03:00
kfree ( iovec ) ;
return ret ;
}
2013-05-10 02:03:42 +04:00
2019-03-07 02:13:00 +03:00
static int aio_write ( struct kiocb * req , const struct iocb * iocb ,
2018-11-25 00:46:14 +03:00
bool vectored , bool compat )
2016-10-30 19:42:03 +03:00
{
struct iovec inline_vecs [ UIO_FASTIOV ] , * iovec = inline_vecs ;
struct iov_iter iter ;
2018-05-02 20:57:21 +03:00
struct file * file ;
2019-03-07 02:13:00 +03:00
int ret ;
2013-05-08 03:19:11 +04:00
2018-05-02 20:57:21 +03:00
ret = aio_prep_rw ( req , iocb ) ;
if ( ret )
return ret ;
file = req - > ki_filp ;
2016-10-30 19:42:03 +03:00
if ( unlikely ( ! ( file - > f_mode & FMODE_WRITE ) ) )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return - EBADF ;
2016-10-30 19:42:03 +03:00
if ( unlikely ( ! file - > f_op - > write_iter ) )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return - EINVAL ;
2005-04-17 02:20:36 +04:00
2016-10-30 19:42:03 +03:00
ret = aio_setup_rw ( WRITE , iocb , & iovec , vectored , compat , & iter ) ;
2019-05-15 01:02:22 +03:00
if ( ret < 0 )
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
return ret ;
2016-10-30 19:42:03 +03:00
ret = rw_verify_area ( WRITE , file , & req - > ki_pos , iov_iter_count ( & iter ) ) ;
if ( ! ret ) {
2016-10-30 19:42:04 +03:00
/*
2018-04-06 10:28:17 +03:00
* Open - code file_start_write here to grab freeze protection ,
2018-05-02 20:57:21 +03:00
* which will be released by another thread in
* aio_complete_rw ( ) . Fool lockdep by telling it the lock got
* released so that it doesn ' t complain about the held lock when
* we return to userspace .
2016-10-30 19:42:04 +03:00
*/
2018-04-06 10:28:17 +03:00
if ( S_ISREG ( file_inode ( file ) - > i_mode ) ) {
2020-11-11 03:50:21 +03:00
sb_start_write ( file_inode ( file ) - > i_sb ) ;
2016-12-13 23:09:56 +03:00
__sb_writers_release ( file_inode ( file ) - > i_sb , SB_FREEZE_WRITE ) ;
2018-04-06 10:28:17 +03:00
}
req - > ki_flags | = IOCB_WRITE ;
2018-05-27 02:11:40 +03:00
aio_rw_done ( req , call_write_iter ( file , req , & iter ) ) ;
2013-05-08 03:19:11 +04:00
}
2016-10-30 19:42:03 +03:00
kfree ( iovec ) ;
return ret ;
2005-04-17 02:20:36 +04:00
}
2018-03-27 20:18:57 +03:00
static void aio_fsync_work ( struct work_struct * work )
{
2019-03-08 03:49:55 +03:00
struct aio_kiocb * iocb = container_of ( work , struct aio_kiocb , fsync . work ) ;
2020-05-14 17:44:24 +03:00
const struct cred * old_cred = override_creds ( iocb - > fsync . creds ) ;
2018-03-27 20:18:57 +03:00
2019-03-08 03:49:55 +03:00
iocb - > ki_res . res = vfs_fsync ( iocb - > fsync . file , iocb - > fsync . datasync ) ;
2020-05-14 17:44:24 +03:00
revert_creds ( old_cred ) ;
put_cred ( iocb - > fsync . creds ) ;
2019-03-08 03:49:55 +03:00
iocb_put ( iocb ) ;
2018-03-27 20:18:57 +03:00
}
2018-11-25 00:46:14 +03:00
static int aio_fsync ( struct fsync_iocb * req , const struct iocb * iocb ,
bool datasync )
2018-03-27 20:18:57 +03:00
{
if ( unlikely ( iocb - > aio_buf | | iocb - > aio_offset | | iocb - > aio_nbytes | |
iocb - > aio_rw_flags ) )
return - EINVAL ;
2018-06-28 19:43:44 +03:00
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
if ( unlikely ( ! req - > file - > f_op - > fsync ) )
2018-03-27 20:18:57 +03:00
return - EINVAL ;
2020-05-14 17:44:24 +03:00
req - > creds = prepare_creds ( ) ;
if ( ! req - > creds )
return - ENOMEM ;
2018-03-27 20:18:57 +03:00
req - > datasync = datasync ;
INIT_WORK ( & req - > work , aio_fsync_work ) ;
schedule_work ( & req - > work ) ;
2018-05-27 02:11:40 +03:00
return 0 ;
2018-03-27 20:18:57 +03:00
}
2020-02-03 20:33:42 +03:00
static void aio_poll_put_work ( struct work_struct * work )
{
struct poll_iocb * req = container_of ( work , struct poll_iocb , work ) ;
struct aio_kiocb * iocb = container_of ( req , struct aio_kiocb , poll ) ;
iocb_put ( iocb ) ;
}
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
/*
* Safely lock the waitqueue which the request is on , synchronizing with the
* case where the - > poll ( ) provider decides to free its waitqueue early .
*
* Returns true on success , meaning that req - > head - > lock was locked , req - > wait
* is on req - > head , and an RCU read lock was taken . Returns false if the
* request was already removed from its waitqueue ( which might no longer exist ) .
*/
static bool poll_iocb_lock_wq ( struct poll_iocb * req )
{
wait_queue_head_t * head ;
/*
* While we hold the waitqueue lock and the waitqueue is nonempty ,
* wake_up_pollfree ( ) will wait for us . However , taking the waitqueue
* lock in the first place can race with the waitqueue being freed .
*
* We solve this as eventpoll does : by taking advantage of the fact that
* all users of wake_up_pollfree ( ) will RCU - delay the actual free . If
* we enter rcu_read_lock ( ) and see that the pointer to the queue is
* non - NULL , we can then lock it without the memory being freed out from
* under us , then check whether the request is still on the queue .
*
* Keep holding rcu_read_lock ( ) as long as we hold the queue lock , in
* case the caller deletes the entry from the queue , leaving it empty .
* In that case , only RCU prevents the queue memory from being freed .
*/
rcu_read_lock ( ) ;
head = smp_load_acquire ( & req - > head ) ;
if ( head ) {
spin_lock ( & head - > lock ) ;
if ( ! list_empty ( & req - > wait . entry ) )
return true ;
spin_unlock ( & head - > lock ) ;
}
rcu_read_unlock ( ) ;
return false ;
}
static void poll_iocb_unlock_wq ( struct poll_iocb * req )
{
spin_unlock ( & req - > head - > lock ) ;
rcu_read_unlock ( ) ;
}
2018-07-16 10:08:20 +03:00
static void aio_poll_complete_work ( struct work_struct * work )
{
struct poll_iocb * req = container_of ( work , struct poll_iocb , work ) ;
struct aio_kiocb * iocb = container_of ( req , struct aio_kiocb , poll ) ;
struct poll_table_struct pt = { . _key = req - > events } ;
struct kioctx * ctx = iocb - > ki_ctx ;
__poll_t mask = 0 ;
if ( ! READ_ONCE ( req - > cancelled ) )
mask = vfs_poll ( req - > file , & pt ) & req - > events ;
/*
* Note that - > ki_cancel callers also delete iocb from active_reqs after
* calling - > ki_cancel . We need the ctx_lock roundtrip here to
* synchronize with them . In the cancellation case the list_del_init
* itself is not actually needed , but harmless so we keep it in to
* avoid further branches in the fast path .
*/
spin_lock_irq ( & ctx - > ctx_lock ) ;
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
if ( poll_iocb_lock_wq ( req ) ) {
if ( ! mask & & ! READ_ONCE ( req - > cancelled ) ) {
/*
* The request isn ' t actually ready to be completed yet .
* Reschedule completion if another wakeup came in .
*/
if ( req - > work_need_resched ) {
schedule_work ( & req - > work ) ;
req - > work_need_resched = false ;
} else {
req - > work_scheduled = false ;
}
poll_iocb_unlock_wq ( req ) ;
spin_unlock_irq ( & ctx - > ctx_lock ) ;
return ;
2021-12-09 04:04:54 +03:00
}
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
list_del_init ( & req - > wait . entry ) ;
poll_iocb_unlock_wq ( req ) ;
} /* else, POLLFREE has freed the waitqueue, so we must complete */
2018-07-16 10:08:20 +03:00
list_del_init ( & iocb - > ki_list ) ;
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
iocb - > ki_res . res = mangle_poll ( mask ) ;
2018-07-16 10:08:20 +03:00
spin_unlock_irq ( & ctx - > ctx_lock ) ;
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
iocb_put ( iocb ) ;
2018-07-16 10:08:20 +03:00
}
/* assumes we are called with irqs disabled */
static int aio_poll_cancel ( struct kiocb * iocb )
{
struct aio_kiocb * aiocb = container_of ( iocb , struct aio_kiocb , rw ) ;
struct poll_iocb * req = & aiocb - > poll ;
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
if ( poll_iocb_lock_wq ( req ) ) {
WRITE_ONCE ( req - > cancelled , true ) ;
if ( ! req - > work_scheduled ) {
schedule_work ( & aiocb - > poll . work ) ;
req - > work_scheduled = true ;
}
poll_iocb_unlock_wq ( req ) ;
} /* else, the request was force-cancelled by POLLFREE already */
2018-07-16 10:08:20 +03:00
return 0 ;
}
static int aio_poll_wake ( struct wait_queue_entry * wait , unsigned mode , int sync ,
void * key )
{
struct poll_iocb * req = container_of ( wait , struct poll_iocb , wait ) ;
2018-07-16 13:25:17 +03:00
struct aio_kiocb * iocb = container_of ( req , struct aio_kiocb , poll ) ;
2018-07-16 10:08:20 +03:00
__poll_t mask = key_to_poll ( key ) ;
aio: Fix locking in aio_poll()
wake_up_locked() may but does not have to be called with interrupts
disabled. Since the fuse filesystem calls wake_up_locked() without
disabling interrupts aio_poll_wake() may be called with interrupts
enabled. Since the kioctx.ctx_lock may be acquired from IRQ context,
all code that acquires that lock from thread context must disable
interrupts. Hence change the spin_trylock() call in aio_poll_wake()
into a spin_trylock_irqsave() call. This patch fixes the following
lockdep complaint:
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
5.0.0-rc4-next-20190131 #23 Not tainted
-----------------------------------------------------
syz-executor2/13779 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
0000000098ac1230 (&fiq->waitq){+.+.}, at: spin_lock include/linux/spinlock.h:329 [inline]
0000000098ac1230 (&fiq->waitq){+.+.}, at: aio_poll fs/aio.c:1772 [inline]
0000000098ac1230 (&fiq->waitq){+.+.}, at: __io_submit_one fs/aio.c:1875 [inline]
0000000098ac1230 (&fiq->waitq){+.+.}, at: io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
and this task is already holding:
000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq include/linux/spinlock.h:354 [inline]
000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll fs/aio.c:1771 [inline]
000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: __io_submit_one fs/aio.c:1875 [inline]
000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: io_submit_one+0xeb6/0x1cf0 fs/aio.c:1908
which would create a new lock dependency:
(&(&ctx->ctx_lock)->rlock){..-.} -> (&fiq->waitq){+.+.}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(&(&ctx->ctx_lock)->rlock){..-.}
... which became SOFTIRQ-irq-safe at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock_irq include/linux/spinlock_api_smp.h:128 [inline]
_raw_spin_lock_irq+0x60/0x80 kernel/locking/spinlock.c:160
spin_lock_irq include/linux/spinlock.h:354 [inline]
free_ioctx_users+0x2d/0x4a0 fs/aio.c:610
percpu_ref_put_many include/linux/percpu-refcount.h:285 [inline]
percpu_ref_put include/linux/percpu-refcount.h:301 [inline]
percpu_ref_call_confirm_rcu lib/percpu-refcount.c:123 [inline]
percpu_ref_switch_to_atomic_rcu+0x3e7/0x520 lib/percpu-refcount.c:158
__rcu_reclaim kernel/rcu/rcu.h:240 [inline]
rcu_do_batch kernel/rcu/tree.c:2486 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2799 [inline]
rcu_core+0x928/0x1390 kernel/rcu/tree.c:2780
__do_softirq+0x266/0x95a kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:654 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
kthread+0x357/0x430 kernel/kthread.c:247
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
to a SOFTIRQ-irq-unsafe lock:
(&fiq->waitq){+.+.}
... which became SOFTIRQ-irq-unsafe at:
...
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
fuse_send_init fs/fuse/inode.c:989 [inline]
fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
mount_nodev+0x68/0x110 fs/super.c:1392
fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
vfs_get_tree+0x123/0x450 fs/super.c:1481
do_new_mount fs/namespace.c:2610 [inline]
do_mount+0x1436/0x2c40 fs/namespace.c:2932
ksys_mount+0xdb/0x150 fs/namespace.c:3148
__do_sys_mount fs/namespace.c:3162 [inline]
__se_sys_mount fs/namespace.c:3159 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fiq->waitq);
local_irq_disable();
lock(&(&ctx->ctx_lock)->rlock);
lock(&fiq->waitq);
<Interrupt>
lock(&(&ctx->ctx_lock)->rlock);
*** DEADLOCK ***
1 lock held by syz-executor2/13779:
#0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq include/linux/spinlock.h:354 [inline]
#0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll fs/aio.c:1771 [inline]
#0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: __io_submit_one fs/aio.c:1875 [inline]
#0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: io_submit_one+0xeb6/0x1cf0 fs/aio.c:1908
the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
-> (&(&ctx->ctx_lock)->rlock){..-.} {
IN-SOFTIRQ-W at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock_irq include/linux/spinlock_api_smp.h:128 [inline]
_raw_spin_lock_irq+0x60/0x80 kernel/locking/spinlock.c:160
spin_lock_irq include/linux/spinlock.h:354 [inline]
free_ioctx_users+0x2d/0x4a0 fs/aio.c:610
percpu_ref_put_many include/linux/percpu-refcount.h:285 [inline]
percpu_ref_put include/linux/percpu-refcount.h:301 [inline]
percpu_ref_call_confirm_rcu lib/percpu-refcount.c:123 [inline]
percpu_ref_switch_to_atomic_rcu+0x3e7/0x520 lib/percpu-refcount.c:158
__rcu_reclaim kernel/rcu/rcu.h:240 [inline]
rcu_do_batch kernel/rcu/tree.c:2486 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2799 [inline]
rcu_core+0x928/0x1390 kernel/rcu/tree.c:2780
__do_softirq+0x266/0x95a kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:654 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
kthread+0x357/0x430 kernel/kthread.c:247
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
INITIAL USE at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock_irq include/linux/spinlock_api_smp.h:128 [inline]
_raw_spin_lock_irq+0x60/0x80 kernel/locking/spinlock.c:160
spin_lock_irq include/linux/spinlock.h:354 [inline]
__do_sys_io_cancel fs/aio.c:2052 [inline]
__se_sys_io_cancel fs/aio.c:2035 [inline]
__x64_sys_io_cancel+0xd5/0x5a0 fs/aio.c:2035
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
}
... key at: [<ffffffff8a574140>] __key.52370+0x0/0x40
... acquired at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
aio_poll fs/aio.c:1772 [inline]
__io_submit_one fs/aio.c:1875 [inline]
io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
__do_sys_io_submit fs/aio.c:1953 [inline]
__se_sys_io_submit fs/aio.c:1923 [inline]
__x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1923
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
the dependencies between the lock to be acquired
and SOFTIRQ-irq-unsafe lock:
-> (&fiq->waitq){+.+.} {
HARDIRQ-ON-W at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
fuse_send_init fs/fuse/inode.c:989 [inline]
fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
mount_nodev+0x68/0x110 fs/super.c:1392
fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
vfs_get_tree+0x123/0x450 fs/super.c:1481
do_new_mount fs/namespace.c:2610 [inline]
do_mount+0x1436/0x2c40 fs/namespace.c:2932
ksys_mount+0xdb/0x150 fs/namespace.c:3148
__do_sys_mount fs/namespace.c:3162 [inline]
__se_sys_mount fs/namespace.c:3159 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
SOFTIRQ-ON-W at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
fuse_send_init fs/fuse/inode.c:989 [inline]
fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
mount_nodev+0x68/0x110 fs/super.c:1392
fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
vfs_get_tree+0x123/0x450 fs/super.c:1481
do_new_mount fs/namespace.c:2610 [inline]
do_mount+0x1436/0x2c40 fs/namespace.c:2932
ksys_mount+0xdb/0x150 fs/namespace.c:3148
__do_sys_mount fs/namespace.c:3162 [inline]
__se_sys_mount fs/namespace.c:3159 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
INITIAL USE at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
fuse_send_init fs/fuse/inode.c:989 [inline]
fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
mount_nodev+0x68/0x110 fs/super.c:1392
fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
vfs_get_tree+0x123/0x450 fs/super.c:1481
do_new_mount fs/namespace.c:2610 [inline]
do_mount+0x1436/0x2c40 fs/namespace.c:2932
ksys_mount+0xdb/0x150 fs/namespace.c:3148
__do_sys_mount fs/namespace.c:3162 [inline]
__se_sys_mount fs/namespace.c:3159 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
}
... key at: [<ffffffff8a60dec0>] __key.43450+0x0/0x40
... acquired at:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
aio_poll fs/aio.c:1772 [inline]
__io_submit_one fs/aio.c:1875 [inline]
io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
__do_sys_io_submit fs/aio.c:1953 [inline]
__se_sys_io_submit fs/aio.c:1923 [inline]
__x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1923
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
stack backtrace:
CPU: 0 PID: 13779 Comm: syz-executor2 Not tainted 5.0.0-rc4-next-20190131 #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_bad_irq_dependency kernel/locking/lockdep.c:1573 [inline]
check_usage.cold+0x60f/0x940 kernel/locking/lockdep.c:1605
check_irq_usage kernel/locking/lockdep.c:1650 [inline]
check_prev_add_irq kernel/locking/lockdep_states.h:8 [inline]
check_prev_add kernel/locking/lockdep.c:1860 [inline]
check_prevs_add kernel/locking/lockdep.c:1968 [inline]
validate_chain kernel/locking/lockdep.c:2339 [inline]
__lock_acquire+0x1f12/0x4790 kernel/locking/lockdep.c:3320
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
aio_poll fs/aio.c:1772 [inline]
__io_submit_one fs/aio.c:1875 [inline]
io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
__do_sys_io_submit fs/aio.c:1953 [inline]
__se_sys_io_submit fs/aio.c:1923 [inline]
__x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1923
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Avi Kivity <avi@scylladb.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org>
Fixes: e8693bcfa0b4 ("aio: allow direct aio poll comletions for keyed wakeups") # v4.19
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
[ bvanassche: added a comment ]
Reluctantly-Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-02-09 03:59:49 +03:00
unsigned long flags ;
2018-07-16 10:08:20 +03:00
/* for instances that support it check for an event match first: */
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
if ( mask & & ! ( mask & req - > events ) )
return 0 ;
2018-07-16 13:25:17 +03:00
2021-12-09 04:04:54 +03:00
/*
* Complete the request inline if possible . This requires that three
* conditions be met :
* 1. An event mask must have been passed . If a plain wakeup was done
* instead , then mask = = 0 and we have to call vfs_poll ( ) to get
* the events , so inline completion isn ' t possible .
* 2. The completion work must not have already been scheduled .
* 3. ctx_lock must not be busy . We have to use trylock because we
* already hold the waitqueue lock , so this inverts the normal
* locking order . Use irqsave / irqrestore because not all
* filesystems ( e . g . fuse ) call this function with IRQs disabled ,
* yet IRQs have to be disabled before ctx_lock is obtained .
*/
if ( mask & & ! req - > work_scheduled & &
spin_trylock_irqsave ( & iocb - > ki_ctx - > ctx_lock , flags ) ) {
2020-02-03 20:33:42 +03:00
struct kioctx * ctx = iocb - > ki_ctx ;
2021-12-09 04:04:54 +03:00
list_del_init ( & req - > wait . entry ) ;
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
list_del ( & iocb - > ki_list ) ;
iocb - > ki_res . res = mangle_poll ( mask ) ;
2021-09-13 14:19:28 +03:00
if ( iocb - > ki_eventfd & & ! eventfd_signal_allowed ( ) ) {
2020-02-03 20:33:42 +03:00
iocb = NULL ;
INIT_WORK ( & req - > work , aio_poll_put_work ) ;
schedule_work ( & req - > work ) ;
}
spin_unlock_irqrestore ( & ctx - > ctx_lock , flags ) ;
if ( iocb )
iocb_put ( iocb ) ;
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
} else {
2021-12-09 04:04:54 +03:00
/*
* Schedule the completion work if needed . If it was already
* scheduled , record that another wakeup came in .
*
* Don ' t remove the request from the waitqueue here , as it might
* not actually be complete yet ( we won ' t know until vfs_poll ( )
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
* is called ) , and we must not miss any wakeups . POLLFREE is an
* exception to this ; see below .
2021-12-09 04:04:54 +03:00
*/
if ( req - > work_scheduled ) {
req - > work_need_resched = true ;
} else {
schedule_work ( & req - > work ) ;
req - > work_scheduled = true ;
}
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
/*
* If the waitqueue is being freed early but we can ' t complete
* the request inline , we have to tear down the request as best
* we can . That means immediately removing the request from its
* waitqueue and preventing all further accesses to the
* waitqueue via the request . We also need to schedule the
* completion work ( done above ) . Also mark the request as
* cancelled , to potentially skip an unneeded call to - > poll ( ) .
*/
if ( mask & POLLFREE ) {
WRITE_ONCE ( req - > cancelled , true ) ;
list_del_init ( & req - > wait . entry ) ;
/*
* Careful : this * must * be the last step , since as soon
* as req - > head is NULL ' ed out , the request can be
* completed and freed , since aio_poll_complete_work ( )
* will no longer need to take the waitqueue lock .
*/
smp_store_release ( & req - > head , NULL ) ;
}
2018-07-16 13:25:17 +03:00
}
2018-07-16 10:08:20 +03:00
return 1 ;
}
struct aio_poll_table {
struct poll_table_struct pt ;
struct aio_kiocb * iocb ;
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
bool queued ;
2018-07-16 10:08:20 +03:00
int error ;
} ;
static void
aio_poll_queue_proc ( struct file * file , struct wait_queue_head * head ,
struct poll_table_struct * p )
{
struct aio_poll_table * pt = container_of ( p , struct aio_poll_table , pt ) ;
/* multiple wait queues per file are not supported */
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
if ( unlikely ( pt - > queued ) ) {
2018-07-16 10:08:20 +03:00
pt - > error = - EINVAL ;
return ;
}
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
pt - > queued = true ;
2018-07-16 10:08:20 +03:00
pt - > error = 0 ;
pt - > iocb - > poll . head = head ;
add_wait_queue ( head , & pt - > iocb - > poll . wait ) ;
}
2019-03-07 02:13:00 +03:00
static int aio_poll ( struct aio_kiocb * aiocb , const struct iocb * iocb )
2018-07-16 10:08:20 +03:00
{
struct kioctx * ctx = aiocb - > ki_ctx ;
struct poll_iocb * req = & aiocb - > poll ;
struct aio_poll_table apt ;
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
bool cancel = false ;
2018-07-16 10:08:20 +03:00
__poll_t mask ;
/* reject any unknown events outside the normal event mask. */
if ( ( u16 ) iocb - > aio_buf ! = iocb - > aio_buf )
return - EINVAL ;
/* reject fields that are not defined for poll */
if ( iocb - > aio_offset | | iocb - > aio_nbytes | | iocb - > aio_rw_flags )
return - EINVAL ;
INIT_WORK ( & req - > work , aio_poll_complete_work ) ;
req - > events = demangle_poll ( iocb - > aio_buf ) | EPOLLERR | EPOLLHUP ;
2018-12-04 19:44:49 +03:00
req - > head = NULL ;
req - > cancelled = false ;
2021-12-09 04:04:54 +03:00
req - > work_scheduled = false ;
req - > work_need_resched = false ;
2018-12-04 19:44:49 +03:00
2018-07-16 10:08:20 +03:00
apt . pt . _qproc = aio_poll_queue_proc ;
apt . pt . _key = req - > events ;
apt . iocb = aiocb ;
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
apt . queued = false ;
2018-07-16 10:08:20 +03:00
apt . error = - EINVAL ; /* same as no support for IOCB_CMD_POLL */
/* initialized the list so that we can do list_empty checks */
INIT_LIST_HEAD ( & req - > wait . entry ) ;
init_waitqueue_func_entry ( & req - > wait , aio_poll_wake ) ;
mask = vfs_poll ( req - > file , & apt . pt ) & req - > events ;
spin_lock_irq ( & ctx - > ctx_lock ) ;
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
if ( likely ( apt . queued ) ) {
bool on_queue = poll_iocb_lock_wq ( req ) ;
if ( ! on_queue | | req - > work_scheduled ) {
2021-12-09 04:04:54 +03:00
/*
* aio_poll_wake ( ) already either scheduled the async
* completion work , or completed the request inline .
*/
if ( apt . error ) /* unsupported case: multiple queues */
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
cancel = true ;
apt . error = 0 ;
mask = 0 ;
}
if ( mask | | apt . error ) {
2021-12-09 04:04:54 +03:00
/* Steal to complete synchronously. */
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
list_del_init ( & req - > wait . entry ) ;
} else if ( cancel ) {
2021-12-09 04:04:54 +03:00
/* Cancel if possible (may be too late though). */
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
WRITE_ONCE ( req - > cancelled , true ) ;
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
} else if ( on_queue ) {
2021-12-09 04:04:54 +03:00
/*
* Actually waiting for an event , so add the request to
* active_reqs so that it can be cancelled if needed .
*/
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
list_add_tail ( & aiocb - > ki_list , & ctx - > active_reqs ) ;
aiocb - > ki_cancel = aio_poll_cancel ;
}
aio: fix use-after-free due to missing POLLFREE handling
signalfd_poll() and binder_poll() are special in that they use a
waitqueue whose lifetime is the current task, rather than the struct
file as is normally the case. This is okay for blocking polls, since a
blocking poll occurs within one task; however, non-blocking polls
require another solution. This solution is for the queue to be cleared
before it is freed, by sending a POLLFREE notification to all waiters.
Unfortunately, only eventpoll handles POLLFREE. A second type of
non-blocking poll, aio poll, was added in kernel v4.18, and it doesn't
handle POLLFREE. This allows a use-after-free to occur if a signalfd or
binder fd is polled with aio poll, and the waitqueue gets freed.
Fix this by making aio poll handle POLLFREE.
A patch by Ramji Jiyani <ramjiyani@google.com>
(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)
tried to do this by making aio_poll_wake() always complete the request
inline if POLLFREE is seen. However, that solution had two bugs.
First, it introduced a deadlock, as it unconditionally locked the aio
context while holding the waitqueue lock, which inverts the normal
locking order. Second, it didn't consider that POLLFREE notifications
are missed while the request has been temporarily de-queued.
The second problem was solved by my previous patch. This patch then
properly fixes the use-after-free by handling POLLFREE in a
deadlock-free way. It does this by taking advantage of the fact that
freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.
Fixes: 2c14fa838cbe ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://lore.kernel.org/r/20211209010455.42744-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2021-12-09 04:04:55 +03:00
if ( on_queue )
poll_iocb_unlock_wq ( req ) ;
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
}
if ( mask ) { /* no async, we'd stolen it */
aiocb - > ki_res . res = mangle_poll ( mask ) ;
2018-07-16 10:08:20 +03:00
apt . error = 0 ;
}
spin_unlock_irq ( & ctx - > ctx_lock ) ;
if ( mask )
Fix aio_poll() races
aio_poll() has to cope with several unpleasant problems:
* requests that might stay around indefinitely need to
be made visible for io_cancel(2); that must not be done to
a request already completed, though.
* in cases when ->poll() has placed us on a waitqueue,
wakeup might have happened (and request completed) before ->poll()
returns.
* worse, in some early wakeup cases request might end
up re-added into the queue later - we can't treat "woken up and
currently not in the queue" as "it's not going to stick around
indefinitely"
* ... moreover, ->poll() might have decided not to
put it on any queues to start with, and that needs to be distinguished
from the previous case
* ->poll() might have tried to put us on more than one queue.
Only the first will succeed for aio poll, so we might end up missing
wakeups. OTOH, we might very well notice that only after the
wakeup hits and request gets completed (all before ->poll() gets
around to the second poll_wait()). In that case it's too late to
decide that we have an error.
req->woken was an attempt to deal with that. Unfortunately, it was
broken. What we need to keep track of is not that wakeup has happened -
the thing might come back after that. It's that async reference is
already gone and won't come back, so we can't (and needn't) put the
request on the list of cancellables.
The easiest case is "request hadn't been put on any waitqueues"; we
can tell by seeing NULL apt.head, and in that case there won't be
anything async. We should either complete the request ourselves
(if vfs_poll() reports anything of interest) or return an error.
In all other cases we get exclusion with wakeups by grabbing the
queue lock.
If request is currently on queue and we have something interesting
from vfs_poll(), we can steal it and complete the request ourselves.
If it's on queue and vfs_poll() has not reported anything interesting,
we either put it on the cancellable list, or, if we know that it
hadn't been put on all queues ->poll() wanted it on, we steal it and
return an error.
If it's _not_ on queue, it's either been already dealt with (in which
case we do nothing), or there's aio_poll_complete_work() about to be
executed. In that case we either put it on the cancellable list,
or, if we know it hadn't been put on all queues ->poll() wanted it on,
simulate what cancel would've done.
It's a lot more convoluted than I'd like it to be. Single-consumer APIs
suck, and unfortunately aio is not an exception...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-03-08 05:45:41 +03:00
iocb_put ( aiocb ) ;
return apt . error ;
2018-07-16 10:08:20 +03:00
}
2018-11-25 00:46:14 +03:00
static int __io_submit_one ( struct kioctx * ctx , const struct iocb * iocb ,
2019-03-07 02:24:51 +03:00
struct iocb __user * user_iocb , struct aio_kiocb * req ,
bool compat )
2005-04-17 02:20:36 +04:00
{
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
req - > ki_filp = fget ( iocb - > aio_fildes ) ;
if ( unlikely ( ! req - > ki_filp ) )
2019-03-07 02:24:51 +03:00
return - EBADF ;
aio: simplify - and fix - fget/fput for io_submit()
Al Viro root-caused a race where the IOCB_CMD_POLL handling of
fget/fput() could cause us to access the file pointer after it had
already been freed:
"In more details - normally IOCB_CMD_POLL handling looks so:
1) io_submit(2) allocates aio_kiocb instance and passes it to
aio_poll()
2) aio_poll() resolves the descriptor to struct file by req->file =
fget(iocb->aio_fildes)
3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
aio_kiocb to 2 (bumps by 1, that is).
4) aio_poll() calls vfs_poll(). After sanity checks (basically,
"poll_wait() had been called and only once") it locks the queue.
That's what the extra reference to iocb had been for - we know we
can safely access it.
5) With queue locked, we check if ->woken has already been set to
true (by aio_poll_wake()) and, if it had been, we unlock the
queue, drop a reference to aio_kiocb and bugger off - at that
point it's a responsibility to aio_poll_wake() and the stuff
called/scheduled by it. That code will drop the reference to file
in req->file, along with the other reference to our aio_kiocb.
6) otherwise, we see whether we need to wait. If we do, we unlock the
queue, drop one reference to aio_kiocb and go away - eventual
wakeup (or cancel) will deal with the reference to file and with
the other reference to aio_kiocb
7) otherwise we remove ourselves from waitqueue (still under the
queue lock), so that wakeup won't get us. No async activity will
be happening, so we can safely drop req->file and iocb ourselves.
If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
won't get freed under us, so we can do all the checks and locking
safely. And we don't touch ->file if we detect that case.
However, vfs_poll() most certainly *does* touch the file it had been
given. So wakeup coming while we are still in ->poll() might end up
doing fput() on that file. That case is not too rare, and usually we
are saved by the still present reference from descriptor table - that
fput() is not the final one.
But if another thread closes that descriptor right after our fget()
and wakeup does happen before ->poll() returns, we are in trouble -
final fput() done while we are in the middle of a method:
Al also wrote a patch to take an extra reference to the file descriptor
to fix this, but I instead suggested we just streamline the whole file
pointer handling by submit_io() so that the generic aio submission code
simply keeps the file pointer around until the aio has completed.
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: syzbot+503d4cc169fcec1cb18c@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-03-04 01:23:33 +03:00
2018-11-25 00:46:14 +03:00
if ( iocb - > aio_flags & IOCB_FLAG_RESFD ) {
2019-03-07 02:18:31 +03:00
struct eventfd_ctx * eventfd ;
signal/timer/event: KAIO eventfd support example
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd (hence
compatible with POSIX select/poll). The KAIO code simply signals the eventfd
fd when events are ready, and this triggers a POLLIN in the fd. This patch
uses a reserved for future use member of the struct iocb to pass an eventfd
file descriptor, that KAIO will use to post events every time a request
completes. At that point, an aio_getevents() will return the completed result
to a struct io_event. I made a quick test program to verify the patch, and it
runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and epoll
too.
This can allow to schedule both block I/O and other poll-able devices
requests, and wait for results using select/poll/epoll. In a typical
scenario, an application would submit KAIO request using aio_submit(), and
will also use epoll_ctl() on the whole other class of devices (that with the
addition of signals, timers and user events, now it's pretty much complete),
and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11 09:23:21 +04:00
/*
* If the IOCB_FLAG_RESFD flag of aio_flags is set , get an
* instance of the file * now . The file descriptor must be
* an eventfd ( ) fd , and will be signaled for each completed
* event using the eventfd_signal ( ) function .
*/
2019-03-07 02:18:31 +03:00
eventfd = eventfd_ctx_fdget ( iocb - > aio_resfd ) ;
2019-03-07 02:24:51 +03:00
if ( IS_ERR ( eventfd ) )
2019-04-03 09:22:35 +03:00
return PTR_ERR ( eventfd ) ;
2019-03-07 02:24:51 +03:00
2019-03-07 02:18:31 +03:00
req - > ki_eventfd = eventfd ;
2017-06-20 15:05:42 +03:00
}
2019-03-07 02:24:51 +03:00
if ( unlikely ( put_user ( KIOCB_KEY , & user_iocb - > aio_key ) ) ) {
2013-05-08 03:18:35 +04:00
pr_debug ( " EFAULT: aio_key \n " ) ;
2019-03-07 02:24:51 +03:00
return - EFAULT ;
2005-04-17 02:20:36 +04:00
}
2019-03-08 03:43:45 +03:00
req - > ki_res . obj = ( u64 ) ( unsigned long ) user_iocb ;
req - > ki_res . data = iocb - > aio_data ;
req - > ki_res . res = 0 ;
req - > ki_res . res2 = 0 ;
2005-04-17 02:20:36 +04:00
2018-11-25 00:46:14 +03:00
switch ( iocb - > aio_lio_opcode ) {
2016-10-30 19:42:03 +03:00
case IOCB_CMD_PREAD :
2019-03-07 02:24:51 +03:00
return aio_read ( & req - > rw , iocb , false , compat ) ;
2016-10-30 19:42:03 +03:00
case IOCB_CMD_PWRITE :
2019-03-07 02:24:51 +03:00
return aio_write ( & req - > rw , iocb , false , compat ) ;
2016-10-30 19:42:03 +03:00
case IOCB_CMD_PREADV :
2019-03-07 02:24:51 +03:00
return aio_read ( & req - > rw , iocb , true , compat ) ;
2016-10-30 19:42:03 +03:00
case IOCB_CMD_PWRITEV :
2019-03-07 02:24:51 +03:00
return aio_write ( & req - > rw , iocb , true , compat ) ;
2018-03-27 20:18:57 +03:00
case IOCB_CMD_FSYNC :
2019-03-07 02:24:51 +03:00
return aio_fsync ( & req - > fsync , iocb , false ) ;
2018-03-27 20:18:57 +03:00
case IOCB_CMD_FDSYNC :
2019-03-07 02:24:51 +03:00
return aio_fsync ( & req - > fsync , iocb , true ) ;
2018-07-16 10:08:20 +03:00
case IOCB_CMD_POLL :
2019-03-07 02:24:51 +03:00
return aio_poll ( req , iocb ) ;
2016-10-30 19:42:03 +03:00
default :
2018-11-25 00:46:14 +03:00
pr_debug ( " invalid aio operation %d \n " , iocb - > aio_lio_opcode ) ;
2019-03-07 02:24:51 +03:00
return - EINVAL ;
2016-10-30 19:42:03 +03:00
}
2005-04-17 02:20:36 +04:00
}
2018-11-25 00:46:14 +03:00
static int io_submit_one ( struct kioctx * ctx , struct iocb __user * user_iocb ,
bool compat )
{
2019-03-07 02:24:51 +03:00
struct aio_kiocb * req ;
2018-11-25 00:46:14 +03:00
struct iocb iocb ;
2019-03-07 02:24:51 +03:00
int err ;
2018-11-25 00:46:14 +03:00
if ( unlikely ( copy_from_user ( & iocb , user_iocb , sizeof ( iocb ) ) ) )
return - EFAULT ;
2019-03-07 02:24:51 +03:00
/* enforce forwards compatibility on users */
if ( unlikely ( iocb . aio_reserved2 ) ) {
pr_debug ( " EINVAL: reserve field set \n " ) ;
return - EINVAL ;
}
/* prevent overflows */
if ( unlikely (
( iocb . aio_buf ! = ( unsigned long ) iocb . aio_buf ) | |
( iocb . aio_nbytes ! = ( size_t ) iocb . aio_nbytes ) | |
( ( ssize_t ) iocb . aio_nbytes < 0 )
) ) {
pr_debug ( " EINVAL: overflow check \n " ) ;
return - EINVAL ;
}
req = aio_get_req ( ctx ) ;
if ( unlikely ( ! req ) )
return - EAGAIN ;
err = __io_submit_one ( ctx , & iocb , user_iocb , req , compat ) ;
/* Done with the synchronous reference */
iocb_put ( req ) ;
/*
* If err is 0 , we ' d either done aio_complete ( ) ourselves or have
* arranged for that to be done asynchronously . Anything non - zero
* means that we need to destroy req ourselves .
*/
if ( unlikely ( err ) ) {
iocb_destroy ( req ) ;
put_reqs_available ( ctx , 1 ) ;
}
return err ;
2018-11-25 00:46:14 +03:00
}
2018-05-27 03:10:07 +03:00
/* sys_io_submit:
* Queue the nr iocbs pointed to by iocbpp for processing . Returns
* the number of iocbs queued . May return - EINVAL if the aio_context
* specified by ctx_id is invalid , if nr is < 0 , if the iocb at
* * iocbpp [ 0 ] is not properly initialized , if the operation specified
* is invalid for the file descriptor in the iocb . May fail with
* - EFAULT if any of the data structures point to invalid data . May
* fail with - EBADF if the file descriptor specified in the first
* iocb is invalid . May fail with - EAGAIN if insufficient resources
* are available to queue any iocbs . Will return 0 if nr is 0. Will
* fail with - ENOSYS if not implemented .
*/
SYSCALL_DEFINE3 ( io_submit , aio_context_t , ctx_id , long , nr ,
struct iocb __user * __user * , iocbpp )
2005-04-17 02:20:36 +04:00
{
struct kioctx * ctx ;
long ret = 0 ;
2011-11-03 00:40:10 +04:00
int i = 0 ;
2010-07-01 09:55:01 +04:00
struct blk_plug plug ;
2005-04-17 02:20:36 +04:00
if ( unlikely ( nr < 0 ) )
return - EINVAL ;
ctx = lookup_ioctx ( ctx_id ) ;
if ( unlikely ( ! ctx ) ) {
2013-05-08 03:18:35 +04:00
pr_debug ( " EINVAL: invalid context id \n " ) ;
2005-04-17 02:20:36 +04:00
return - EINVAL ;
}
2018-05-27 03:10:07 +03:00
if ( nr > ctx - > nr_events )
nr = ctx - > nr_events ;
2018-12-04 19:45:32 +03:00
if ( nr > AIO_PLUG_THRESHOLD )
blk_start_plug ( & plug ) ;
2018-05-27 03:10:07 +03:00
for ( i = 0 ; i < nr ; i + + ) {
2005-04-17 02:20:36 +04:00
struct iocb __user * user_iocb ;
2018-05-27 03:10:07 +03:00
if ( unlikely ( get_user ( user_iocb , iocbpp + i ) ) ) {
2005-04-17 02:20:36 +04:00
ret = - EFAULT ;
break ;
}
2018-05-27 03:10:07 +03:00
ret = io_submit_one ( ctx , user_iocb , false ) ;
2005-04-17 02:20:36 +04:00
if ( ret )
break ;
}
2018-12-04 19:45:32 +03:00
if ( nr > AIO_PLUG_THRESHOLD )
blk_finish_plug ( & plug ) ;
2005-04-17 02:20:36 +04:00
2013-05-29 02:14:48 +04:00
percpu_ref_put ( & ctx - > users ) ;
2005-04-17 02:20:36 +04:00
return i ? i : ret ;
}
2016-12-20 15:04:57 +03:00
# ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE3 ( io_submit , compat_aio_context_t , ctx_id ,
2018-05-27 03:10:07 +03:00
int , nr , compat_uptr_t __user * , iocbpp )
2016-12-20 15:04:57 +03:00
{
2018-05-27 03:10:07 +03:00
struct kioctx * ctx ;
long ret = 0 ;
int i = 0 ;
struct blk_plug plug ;
2016-12-20 15:04:57 +03:00
if ( unlikely ( nr < 0 ) )
return - EINVAL ;
2018-05-27 03:10:07 +03:00
ctx = lookup_ioctx ( ctx_id ) ;
if ( unlikely ( ! ctx ) ) {
pr_debug ( " EINVAL: invalid context id \n " ) ;
return - EINVAL ;
}
2018-05-27 03:10:07 +03:00
if ( nr > ctx - > nr_events )
nr = ctx - > nr_events ;
2018-12-04 19:45:32 +03:00
if ( nr > AIO_PLUG_THRESHOLD )
blk_start_plug ( & plug ) ;
2018-05-27 03:10:07 +03:00
for ( i = 0 ; i < nr ; i + + ) {
compat_uptr_t user_iocb ;
if ( unlikely ( get_user ( user_iocb , iocbpp + i ) ) ) {
ret = - EFAULT ;
break ;
}
ret = io_submit_one ( ctx , compat_ptr ( user_iocb ) , true ) ;
if ( ret )
break ;
}
2018-12-04 19:45:32 +03:00
if ( nr > AIO_PLUG_THRESHOLD )
blk_finish_plug ( & plug ) ;
2018-05-27 03:10:07 +03:00
percpu_ref_put ( & ctx - > users ) ;
return i ? i : ret ;
2016-12-20 15:04:57 +03:00
}
# endif
2005-04-17 02:20:36 +04:00
/* sys_io_cancel:
* Attempts to cancel an iocb previously passed to io_submit . If
* the operation is successfully cancelled , the resulting event is
* copied into the memory pointed to by result without being placed
* into the completion queue and 0 is returned . May fail with
* - EFAULT if any of the data structures pointed to are invalid .
* May fail with - EINVAL if aio_context specified by ctx_id is
* invalid . May fail with - EAGAIN if the iocb specified was not
* cancelled . Will fail with - ENOSYS if not implemented .
*/
2009-01-14 16:14:18 +03:00
SYSCALL_DEFINE3 ( io_cancel , aio_context_t , ctx_id , struct iocb __user * , iocb ,
struct io_event __user * , result )
2005-04-17 02:20:36 +04:00
{
struct kioctx * ctx ;
2015-02-02 16:49:06 +03:00
struct aio_kiocb * kiocb ;
2018-05-23 15:11:02 +03:00
int ret = - EINVAL ;
2005-04-17 02:20:36 +04:00
u32 key ;
2019-03-08 03:43:45 +03:00
u64 obj = ( u64 ) ( unsigned long ) iocb ;
2005-04-17 02:20:36 +04:00
2018-03-30 12:19:25 +03:00
if ( unlikely ( get_user ( key , & iocb - > aio_key ) ) )
2005-04-17 02:20:36 +04:00
return - EFAULT ;
2018-03-30 12:19:25 +03:00
if ( unlikely ( key ! = KIOCB_KEY ) )
return - EINVAL ;
2005-04-17 02:20:36 +04:00
ctx = lookup_ioctx ( ctx_id ) ;
if ( unlikely ( ! ctx ) )
return - EINVAL ;
spin_lock_irq ( & ctx - > ctx_lock ) ;
2019-03-12 02:00:36 +03:00
/* TODO: use a hash or array, this sucks. */
list_for_each_entry ( kiocb , & ctx - > active_reqs , ki_list ) {
2019-03-08 03:43:45 +03:00
if ( kiocb - > ki_res . obj = = obj ) {
2019-03-12 02:00:36 +03:00
ret = kiocb - > ki_cancel ( & kiocb - > rw ) ;
list_del_init ( & kiocb - > ki_list ) ;
break ;
}
2018-05-23 15:11:02 +03:00
}
2005-04-17 02:20:36 +04:00
spin_unlock_irq ( & ctx - > ctx_lock ) ;
2013-05-08 03:18:31 +04:00
if ( ! ret ) {
2013-05-14 01:45:08 +04:00
/*
* The result argument is no longer used - the io_event is
* always delivered via the ring buffer . - EINPROGRESS indicates
* cancellation is progress :
2013-05-08 03:18:31 +04:00
*/
2013-05-14 01:45:08 +04:00
ret = - EINPROGRESS ;
2013-05-08 03:18:31 +04:00
}
2005-04-17 02:20:36 +04:00
2013-05-29 02:14:48 +04:00
percpu_ref_put ( & ctx - > users ) ;
2005-04-17 02:20:36 +04:00
return ret ;
}
2017-08-05 07:12:32 +03:00
static long do_io_getevents ( aio_context_t ctx_id ,
long min_nr ,
long nr ,
struct io_event __user * events ,
struct timespec64 * ts )
{
ktime_t until = ts ? timespec64_to_ktime ( * ts ) : KTIME_MAX ;
struct kioctx * ioctx = lookup_ioctx ( ctx_id ) ;
long ret = - EINVAL ;
if ( likely ( ioctx ) ) {
if ( likely ( min_nr < = nr & & min_nr > = 0 ) )
ret = read_events ( ioctx , min_nr , nr , events , until ) ;
percpu_ref_put ( & ioctx - > users ) ;
}
return ret ;
}
2005-04-17 02:20:36 +04:00
/* io_getevents:
* Attempts to read at least min_nr events and up to nr events from
2010-08-05 22:23:11 +04:00
* the completion queue for the aio_context specified by ctx_id . If
* it succeeds , the number of read events is returned . May fail with
* - EINVAL if ctx_id is invalid , if min_nr is out of range , if nr is
* out of range , if timeout is out of range . May fail with - EFAULT
* if any of the memory specified is invalid . May return 0 or
* < min_nr if the timeout specified by timeout has elapsed
* before sufficient events are available , where timeout = = NULL
* specifies an infinite timeout . Note that the timeout pointed to by
2013-05-25 02:55:24 +04:00
* timeout is relative . Will fail with - ENOSYS if not implemented .
2005-04-17 02:20:36 +04:00
*/
2019-04-23 18:43:50 +03:00
# ifdef CONFIG_64BIT
2018-09-20 07:41:08 +03:00
2009-01-14 16:14:18 +03:00
SYSCALL_DEFINE5 ( io_getevents , aio_context_t , ctx_id ,
long , min_nr ,
long , nr ,
struct io_event __user * , events ,
2018-09-20 07:41:08 +03:00
struct __kernel_timespec __user * , timeout )
2005-04-17 02:20:36 +04:00
{
2017-08-05 07:12:32 +03:00
struct timespec64 ts ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
int ret ;
if ( timeout & & unlikely ( get_timespec64 ( & ts , timeout ) ) )
return - EFAULT ;
ret = do_io_getevents ( ctx_id , min_nr , nr , events , timeout ? & ts : NULL ) ;
if ( ! ret & & signal_pending ( current ) )
ret = - EINTR ;
return ret ;
}
2005-04-17 02:20:36 +04:00
2018-09-20 07:41:08 +03:00
# endif
2018-07-11 16:48:46 +03:00
struct __aio_sigset {
const sigset_t __user * sigmask ;
size_t sigsetsize ;
} ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
SYSCALL_DEFINE6 ( io_pgetevents ,
aio_context_t , ctx_id ,
long , min_nr ,
long , nr ,
struct io_event __user * , events ,
2018-09-20 07:41:08 +03:00
struct __kernel_timespec __user * , timeout ,
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
const struct __aio_sigset __user * , usig )
{
struct __aio_sigset ksig = { NULL , } ;
struct timespec64 ts ;
2019-06-28 22:06:50 +03:00
bool interrupted ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
int ret ;
if ( timeout & & unlikely ( get_timespec64 ( & ts , timeout ) ) )
return - EFAULT ;
if ( usig & & copy_from_user ( & ksig , usig , sizeof ( ksig ) ) )
return - EFAULT ;
2019-07-17 02:29:53 +03:00
ret = set_user_sigmask ( ksig . sigmask , ksig . sigsetsize ) ;
2018-09-20 07:41:08 +03:00
if ( ret )
return ret ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
ret = do_io_getevents ( ctx_id , min_nr , nr , events , timeout ? & ts : NULL ) ;
2019-06-28 22:06:50 +03:00
interrupted = signal_pending ( current ) ;
2019-07-17 02:29:53 +03:00
restore_saved_sigmask_unless ( interrupted ) ;
2019-06-28 22:06:50 +03:00
if ( interrupted & & ! ret )
2018-09-20 07:41:08 +03:00
ret = - ERESTARTNOHAND ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
2018-09-20 07:41:08 +03:00
return ret ;
}
# if defined(CONFIG_COMPAT_32BIT_TIME) && !defined(CONFIG_64BIT)
SYSCALL_DEFINE6 ( io_pgetevents_time32 ,
aio_context_t , ctx_id ,
long , min_nr ,
long , nr ,
struct io_event __user * , events ,
struct old_timespec32 __user * , timeout ,
const struct __aio_sigset __user * , usig )
{
struct __aio_sigset ksig = { NULL , } ;
struct timespec64 ts ;
2019-06-28 22:06:50 +03:00
bool interrupted ;
2018-09-20 07:41:08 +03:00
int ret ;
if ( timeout & & unlikely ( get_old_timespec32 ( & ts , timeout ) ) )
return - EFAULT ;
if ( usig & & copy_from_user ( & ksig , usig , sizeof ( ksig ) ) )
return - EFAULT ;
2018-09-20 07:41:04 +03:00
2019-07-17 02:29:53 +03:00
ret = set_user_sigmask ( ksig . sigmask , ksig . sigsetsize ) ;
2018-09-20 07:41:04 +03:00
if ( ret )
return ret ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
ret = do_io_getevents ( ctx_id , min_nr , nr , events , timeout ? & ts : NULL ) ;
2019-06-28 22:06:50 +03:00
interrupted = signal_pending ( current ) ;
2019-07-17 02:29:53 +03:00
restore_saved_sigmask_unless ( interrupted ) ;
2019-06-28 22:06:50 +03:00
if ( interrupted & & ! ret )
2018-09-20 07:41:05 +03:00
ret = - ERESTARTNOHAND ;
2017-08-05 07:12:32 +03:00
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
return ret ;
2005-04-17 02:20:36 +04:00
}
2016-12-20 15:04:57 +03:00
2018-09-20 07:41:08 +03:00
# endif
# if defined(CONFIG_COMPAT_32BIT_TIME)
2019-01-07 02:33:08 +03:00
SYSCALL_DEFINE5 ( io_getevents_time32 , __u32 , ctx_id ,
__s32 , min_nr ,
__s32 , nr ,
struct io_event __user * , events ,
struct old_timespec32 __user * , timeout )
2016-12-20 15:04:57 +03:00
{
2017-08-05 07:12:32 +03:00
struct timespec64 t ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
int ret ;
y2038: globally rename compat_time to old_time32
Christoph Hellwig suggested a slightly different path for handling
backwards compatibility with the 32-bit time_t based system calls:
Rather than simply reusing the compat_sys_* entry points on 32-bit
architectures unchanged, we get rid of those entry points and the
compat_time types by renaming them to something that makes more sense
on 32-bit architectures (which don't have a compat mode otherwise),
and then share the entry points under the new name with the 64-bit
architectures that use them for implementing the compatibility.
The following types and interfaces are renamed here, and moved
from linux/compat_time.h to linux/time32.h:
old new
--- ---
compat_time_t old_time32_t
struct compat_timeval struct old_timeval32
struct compat_timespec struct old_timespec32
struct compat_itimerspec struct old_itimerspec32
ns_to_compat_timeval() ns_to_old_timeval32()
get_compat_itimerspec64() get_old_itimerspec32()
put_compat_itimerspec64() put_old_itimerspec32()
compat_get_timespec64() get_old_timespec32()
compat_put_timespec64() put_old_timespec32()
As we already have aliases in place, this patch addresses only the
instances that are relevant to the system call interface in particular,
not those that occur in device drivers and other modules. Those
will get handled separately, while providing the 64-bit version
of the respective interfaces.
I'm not renaming the timex, rusage and itimerval structures, as we are
still debating what the new interface will look like, and whether we
will need a replacement at all.
This also doesn't change the names of the syscall entry points, which can
be done more easily when we actually switch over the 32-bit architectures
to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-07-13 13:52:28 +03:00
if ( timeout & & get_old_timespec32 ( & t , timeout ) )
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
return - EFAULT ;
ret = do_io_getevents ( ctx_id , min_nr , nr , events , timeout ? & t : NULL ) ;
if ( ! ret & & signal_pending ( current ) )
ret = - EINTR ;
return ret ;
}
2018-09-20 07:41:08 +03:00
# endif
# ifdef CONFIG_COMPAT
2016-12-20 15:04:57 +03:00
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
struct __compat_aio_sigset {
2019-08-21 06:38:20 +03:00
compat_uptr_t sigmask ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
compat_size_t sigsetsize ;
} ;
2018-09-20 07:41:08 +03:00
# if defined(CONFIG_COMPAT_32BIT_TIME)
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
COMPAT_SYSCALL_DEFINE6 ( io_pgetevents ,
compat_aio_context_t , ctx_id ,
compat_long_t , min_nr ,
compat_long_t , nr ,
struct io_event __user * , events ,
y2038: globally rename compat_time to old_time32
Christoph Hellwig suggested a slightly different path for handling
backwards compatibility with the 32-bit time_t based system calls:
Rather than simply reusing the compat_sys_* entry points on 32-bit
architectures unchanged, we get rid of those entry points and the
compat_time types by renaming them to something that makes more sense
on 32-bit architectures (which don't have a compat mode otherwise),
and then share the entry points under the new name with the 64-bit
architectures that use them for implementing the compatibility.
The following types and interfaces are renamed here, and moved
from linux/compat_time.h to linux/time32.h:
old new
--- ---
compat_time_t old_time32_t
struct compat_timeval struct old_timeval32
struct compat_timespec struct old_timespec32
struct compat_itimerspec struct old_itimerspec32
ns_to_compat_timeval() ns_to_old_timeval32()
get_compat_itimerspec64() get_old_itimerspec32()
put_compat_itimerspec64() put_old_itimerspec32()
compat_get_timespec64() get_old_timespec32()
compat_put_timespec64() put_old_timespec32()
As we already have aliases in place, this patch addresses only the
instances that are relevant to the system call interface in particular,
not those that occur in device drivers and other modules. Those
will get handled separately, while providing the 64-bit version
of the respective interfaces.
I'm not renaming the timex, rusage and itimerval structures, as we are
still debating what the new interface will look like, and whether we
will need a replacement at all.
This also doesn't change the names of the syscall entry points, which can
be done more easily when we actually switch over the 32-bit architectures
to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-07-13 13:52:28 +03:00
struct old_timespec32 __user * , timeout ,
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
const struct __compat_aio_sigset __user * , usig )
{
2019-08-21 06:38:20 +03:00
struct __compat_aio_sigset ksig = { 0 , } ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
struct timespec64 t ;
2019-06-28 22:06:50 +03:00
bool interrupted ;
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
int ret ;
y2038: globally rename compat_time to old_time32
Christoph Hellwig suggested a slightly different path for handling
backwards compatibility with the 32-bit time_t based system calls:
Rather than simply reusing the compat_sys_* entry points on 32-bit
architectures unchanged, we get rid of those entry points and the
compat_time types by renaming them to something that makes more sense
on 32-bit architectures (which don't have a compat mode otherwise),
and then share the entry points under the new name with the 64-bit
architectures that use them for implementing the compatibility.
The following types and interfaces are renamed here, and moved
from linux/compat_time.h to linux/time32.h:
old new
--- ---
compat_time_t old_time32_t
struct compat_timeval struct old_timeval32
struct compat_timespec struct old_timespec32
struct compat_itimerspec struct old_itimerspec32
ns_to_compat_timeval() ns_to_old_timeval32()
get_compat_itimerspec64() get_old_itimerspec32()
put_compat_itimerspec64() put_old_itimerspec32()
compat_get_timespec64() get_old_timespec32()
compat_put_timespec64() put_old_timespec32()
As we already have aliases in place, this patch addresses only the
instances that are relevant to the system call interface in particular,
not those that occur in device drivers and other modules. Those
will get handled separately, while providing the 64-bit version
of the respective interfaces.
I'm not renaming the timex, rusage and itimerval structures, as we are
still debating what the new interface will look like, and whether we
will need a replacement at all.
This also doesn't change the names of the syscall entry points, which can
be done more easily when we actually switch over the 32-bit architectures
to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-07-13 13:52:28 +03:00
if ( timeout & & get_old_timespec32 ( & t , timeout ) )
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
return - EFAULT ;
if ( usig & & copy_from_user ( & ksig , usig , sizeof ( ksig ) ) )
return - EFAULT ;
2019-08-21 06:38:20 +03:00
ret = set_compat_user_sigmask ( compat_ptr ( ksig . sigmask ) , ksig . sigsetsize ) ;
2018-09-20 07:41:04 +03:00
if ( ret )
return ret ;
2016-12-20 15:04:57 +03:00
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
ret = do_io_getevents ( ctx_id , min_nr , nr , events , timeout ? & t : NULL ) ;
2019-06-28 22:06:50 +03:00
interrupted = signal_pending ( current ) ;
2019-07-17 02:29:53 +03:00
restore_saved_sigmask_unless ( interrupted ) ;
2019-06-28 22:06:50 +03:00
if ( interrupted & & ! ret )
2018-09-20 07:41:05 +03:00
ret = - ERESTARTNOHAND ;
2017-08-05 07:12:32 +03:00
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
return ret ;
2016-12-20 15:04:57 +03:00
}
2018-09-20 07:41:08 +03:00
# endif
COMPAT_SYSCALL_DEFINE6 ( io_pgetevents_time64 ,
compat_aio_context_t , ctx_id ,
compat_long_t , min_nr ,
compat_long_t , nr ,
struct io_event __user * , events ,
struct __kernel_timespec __user * , timeout ,
const struct __compat_aio_sigset __user * , usig )
{
2019-08-21 06:38:20 +03:00
struct __compat_aio_sigset ksig = { 0 , } ;
2018-09-20 07:41:08 +03:00
struct timespec64 t ;
2019-06-28 22:06:50 +03:00
bool interrupted ;
2018-09-20 07:41:08 +03:00
int ret ;
if ( timeout & & get_timespec64 ( & t , timeout ) )
return - EFAULT ;
if ( usig & & copy_from_user ( & ksig , usig , sizeof ( ksig ) ) )
return - EFAULT ;
2019-08-21 06:38:20 +03:00
ret = set_compat_user_sigmask ( compat_ptr ( ksig . sigmask ) , ksig . sigsetsize ) ;
2018-09-20 07:41:08 +03:00
if ( ret )
return ret ;
ret = do_io_getevents ( ctx_id , min_nr , nr , events , timeout ? & t : NULL ) ;
2019-06-28 22:06:50 +03:00
interrupted = signal_pending ( current ) ;
2019-07-17 02:29:53 +03:00
restore_saved_sigmask_unless ( interrupted ) ;
2019-06-28 22:06:50 +03:00
if ( interrupted & & ! ret )
2018-09-20 07:41:08 +03:00
ret = - ERESTARTNOHAND ;
2017-08-05 07:12:32 +03:00
aio: implement io_pgetevents
This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure. It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
2018-05-02 20:51:00 +03:00
return ret ;
2016-12-20 15:04:57 +03:00
}
# endif