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 .
*
* 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>
2006-10-01 10:28:46 +04:00
# include <linux/uio.h>
2005-04-17 02:20:36 +04:00
# include <linux/sched.h>
# include <linux/fs.h>
# include <linux/file.h>
# include <linux/mm.h>
# include <linux/mman.h>
2009-09-22 04:03:51 +04:00
# include <linux/mmu_context.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>
2005-04-17 02:20:36 +04:00
# include <asm/kmap_types.h>
# include <asm/uaccess.h>
2013-06-19 15:26:04 +04:00
# include "internal.h"
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 */
struct io_event io_events [ 0 ] ;
} ; /* 128 bytes + ring size */
# 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 {
struct rcu_head rcu ;
unsigned nr ;
struct kioctx * table [ ] ;
} ;
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 ;
2013-05-29 02:14:48 +04:00
struct work_struct free_work ;
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
} ;
2015-02-02 16:49:06 +03:00
/*
* We use ki_cancel = = KIOCB_CANCELLED to indicate that a kiocb has been either
* cancelled or completed ( this makes a certain amount of sense because
* successful cancellation - io_cancel ( ) - does deliver the completion to
* userspace ) .
*
* And since most things don ' t implement kiocb cancellation and we ' d really like
* kiocb completion to be lockless when possible , we use ki_cancel to
* synchronize cancellation and completion - we only set it to KIOCB_CANCELLED
* with xchg ( ) or cmpxchg ( ) , see batch_complete_aio ( ) and kiocb_cancel ( ) .
*/
# define KIOCB_CANCELLED ((void *) (~0ULL))
struct aio_kiocb {
struct kiocb common ;
struct kioctx * ki_ctx ;
kiocb_cancel_fn * ki_cancel ;
struct iocb __user * ki_user_iocb ; /* user's aiocb */
__u64 ki_user_data ; /* user's data for completion */
struct list_head ki_list ; /* the aio core uses this
* for cancellation */
/*
* 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 ) ;
unsigned long aio_nr ; /* current system wide number of aio requests */
unsigned long aio_max_nr = 0x10000 ; /* system wide maximum number of aio requests */
2005-04-17 02:20:36 +04:00
/*----end sysctl variables---*/
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 qstr this = QSTR_INIT ( " [aio] " , 5 ) ;
struct file * file ;
struct path path ;
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 ;
path . dentry = d_alloc_pseudo ( aio_mnt - > mnt_sb , & this ) ;
if ( ! path . dentry ) {
iput ( inode ) ;
return ERR_PTR ( - ENOMEM ) ;
}
path . mnt = mntget ( aio_mnt ) ;
d_instantiate ( path . dentry , inode ) ;
file = alloc_file ( & path , FMODE_READ | FMODE_WRITE , & aio_ring_fops ) ;
if ( IS_ERR ( file ) ) {
path_put ( & path ) ;
return file ;
}
file - > f_flags = O_RDWR ;
return file ;
}
static struct dentry * aio_mount ( struct file_system_type * fs_type ,
int flags , const char * dev_name , void * data )
{
static const struct dentry_operations ops = {
. d_dname = simple_dname ,
} ;
2014-07-23 14:03:52 +04:00
return mount_pseudo ( fs_type , " aio: " , NULL , & ops , AIO_RING_MAGIC ) ;
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 " ,
. mount = aio_mount ,
. 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 ) ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:35 +04:00
pr_debug ( " sizeof(struct page) = %zu \n " , sizeof ( struct page ) ) ;
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 ;
if ( aio_ring_file ) {
truncate_setsize ( aio_ring_file - > f_inode , 0 ) ;
/* Prevent further access to the kioctx from migratepages */
spin_lock ( & aio_ring_file - > f_inode - > i_mapping - > private_lock ) ;
aio_ring_file - > f_inode - > i_mapping - > private_data = NULL ;
ctx - > aio_ring_file = NULL ;
spin_unlock ( & aio_ring_file - > f_inode - > i_mapping - > private_lock ) ;
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
}
static int aio_ring_mmap ( struct file * file , struct vm_area_struct * vma )
{
2014-09-18 19:56:17 +04:00
vma - > vm_flags | = VM_DONTEXPAND ;
2013-07-16 13:56:16 +04:00
vma - > vm_ops = & generic_file_vm_ops ;
return 0 ;
}
2015-04-07 00:48:54 +03:00
static int aio_ring_remap ( struct file * file , struct vm_area_struct * vma )
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 ;
ctx = table - > table [ i ] ;
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
}
2013-07-16 13:56:16 +04:00
static const struct file_operations aio_ring_fops = {
. mmap = aio_ring_mmap ,
2014-09-18 19:56:17 +04:00
. mremap = aio_ring_remap ,
2013-07-16 13:56:16 +04:00
} ;
2013-07-17 17:34:24 +04:00
# if IS_ENABLED(CONFIG_MIGRATION)
2013-07-16 13:56:16 +04:00
static int aio_migratepage ( struct address_space * mapping , struct page * new ,
struct page * old , enum migrate_mode mode )
{
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 ;
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 ;
}
idx = old - > index ;
if ( idx < ( pgoff_t ) ctx - > nr_pages ) {
/* Make sure the old page hasn't already been changed */
if ( ctx - > ring_pages [ idx ] ! = old )
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 */
BUG_ON ( PageWriteback ( old ) ) ;
2013-12-22 02:56:08 +04:00
get_page ( new ) ;
2013-07-16 13:56:16 +04:00
2013-12-22 02:56:08 +04:00
rc = migrate_page_move_mapping ( mapping , new , old , NULL , mode , 1 ) ;
2013-07-16 13:56:16 +04:00
if ( rc ! = MIGRATEPAGE_SUCCESS ) {
2013-12-22 02:56:08 +04:00
put_page ( 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
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
* while the old page is copied to the new . This prevents new
* 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 ) ;
migrate_page_copy ( new , old ) ;
BUG_ON ( ctx - > ring_pages [ idx ] ! = old ) ;
ctx - > ring_pages [ idx ] = new ;
spin_unlock_irqrestore ( & ctx - > completion_lock , flags ) ;
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
/* The old page is no longer accessible. */
put_page ( old ) ;
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
}
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 = {
aio: fix uncorrent dirty pages accouting when truncating AIO ring buffer
https://bugzilla.kernel.org/show_bug.cgi?id=86831
Markus reported that when shutting down mysqld (with AIO support,
on a ext3 formatted Harddrive) leads to a negative number of dirty pages
(underrun to the counter). The negative number results in a drastic reduction
of the write performance because the page cache is not used, because the kernel
thinks it is still 2 ^ 32 dirty pages open.
Add a warn trace in __dec_zone_state will catch this easily:
static inline void __dec_zone_state(struct zone *zone, enum
zone_stat_item item)
{
atomic_long_dec(&zone->vm_stat[item]);
+ WARN_ON_ONCE(item == NR_FILE_DIRTY &&
atomic_long_read(&zone->vm_stat[item]) < 0);
atomic_long_dec(&vm_stat[item]);
}
[ 21.341632] ------------[ cut here ]------------
[ 21.346294] WARNING: CPU: 0 PID: 309 at include/linux/vmstat.h:242
cancel_dirty_page+0x164/0x224()
[ 21.355296] Modules linked in: wutbox_cp sata_mv
[ 21.359968] CPU: 0 PID: 309 Comm: kworker/0:1 Not tainted 3.14.21-WuT #80
[ 21.366793] Workqueue: events free_ioctx
[ 21.370760] [<c0016a64>] (unwind_backtrace) from [<c0012f88>]
(show_stack+0x20/0x24)
[ 21.378562] [<c0012f88>] (show_stack) from [<c03f8ccc>]
(dump_stack+0x24/0x28)
[ 21.385840] [<c03f8ccc>] (dump_stack) from [<c0023ae4>]
(warn_slowpath_common+0x84/0x9c)
[ 21.393976] [<c0023ae4>] (warn_slowpath_common) from [<c0023bb8>]
(warn_slowpath_null+0x2c/0x34)
[ 21.402800] [<c0023bb8>] (warn_slowpath_null) from [<c00c0688>]
(cancel_dirty_page+0x164/0x224)
[ 21.411524] [<c00c0688>] (cancel_dirty_page) from [<c00c080c>]
(truncate_inode_page+0x8c/0x158)
[ 21.420272] [<c00c080c>] (truncate_inode_page) from [<c00c0a94>]
(truncate_inode_pages_range+0x11c/0x53c)
[ 21.429890] [<c00c0a94>] (truncate_inode_pages_range) from
[<c00c0f6c>] (truncate_pagecache+0x88/0xac)
[ 21.439252] [<c00c0f6c>] (truncate_pagecache) from [<c00c0fec>]
(truncate_setsize+0x5c/0x74)
[ 21.447731] [<c00c0fec>] (truncate_setsize) from [<c013b3a8>]
(put_aio_ring_file.isra.14+0x34/0x90)
[ 21.456826] [<c013b3a8>] (put_aio_ring_file.isra.14) from
[<c013b424>] (aio_free_ring+0x20/0xcc)
[ 21.465660] [<c013b424>] (aio_free_ring) from [<c013b4f4>]
(free_ioctx+0x24/0x44)
[ 21.473190] [<c013b4f4>] (free_ioctx) from [<c003d8d8>]
(process_one_work+0x134/0x47c)
[ 21.481132] [<c003d8d8>] (process_one_work) from [<c003e988>]
(worker_thread+0x130/0x414)
[ 21.489350] [<c003e988>] (worker_thread) from [<c00448ac>]
(kthread+0xd4/0xec)
[ 21.496621] [<c00448ac>] (kthread) from [<c000ec18>]
(ret_from_fork+0x14/0x20)
[ 21.503884] ---[ end trace 79c4bf42c038c9a1 ]---
The cause is that we set the aio ring file pages as *DIRTY* via SetPageDirty
(bypasses the VFS dirty pages increment) when init, and aio fs uses
*default_backing_dev_info* as the backing dev, which does not disable
the dirty pages accounting capability.
So truncating aio ring file will contribute to accounting dirty pages (VFS
dirty pages decrement), then error occurs.
The original goal is keeping these pages in memory (can not be reclaimed
or swapped) in life-time via marking it dirty. But thinking more, we have
already pinned pages via elevating the page's refcount, which can already
achieve the goal, so the SetPageDirty seems unnecessary.
In order to fix the issue, using the __set_page_dirty_no_writeback instead
of the nop .set_page_dirty, and dropped the SetPageDirty (don't manually
set the dirty flags, don't disable set_page_dirty(), rely on default behaviour).
With the above change, the dirty pages accounting can work well. But as we
known, aio fs is an anonymous one, which should never cause any real write-back,
we can ignore the dirty pages (write back) accounting by disabling the dirty
pages (write back) accounting capability. So we introduce an aio private
backing dev info (disabled the ACCT_DIRTY/WRITEBACK/ACCT_WB capabilities) to
replace the default one.
Reported-by: Markus Königshaus <m.koenigshaus@wut.de>
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
2014-11-06 12:46:21 +03:00
. set_page_dirty = __set_page_dirty_no_writeback ,
2013-07-17 17:34:24 +04:00
# if IS_ENABLED(CONFIG_MIGRATION)
2013-07-16 13:56:16 +04:00
. migratepage = aio_migratepage ,
2013-07-17 17:34:24 +04:00
# endif
2013-07-16 13:56:16 +04:00
} ;
2005-04-17 02:20:36 +04:00
static int aio_setup_ring ( struct kioctx * ctx )
{
struct aio_ring * ring ;
unsigned nr_events = ctx - > max_reqs ;
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 ;
page = find_or_create_page ( file - > f_inode - > i_mapping ,
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
2013-05-08 03:18:25 +04:00
down_write ( & mm - > mmap_sem ) ;
2013-07-16 13:56:16 +04:00
ctx - > mmap_base = do_mmap_pgoff ( ctx - > aio_ring_file , 0 , ctx - > mmap_size ,
PROT_READ | PROT_WRITE ,
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
MAP_SHARED , 0 , & unused ) ;
up_write ( & mm - > mmap_sem ) ;
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
{
2015-02-02 16:49:06 +03:00
struct aio_kiocb * req = container_of ( iocb , struct aio_kiocb , common ) ;
2013-05-08 03:18:49 +04:00
struct kioctx * ctx = req - > ki_ctx ;
unsigned long flags ;
spin_lock_irqsave ( & ctx - > ctx_lock , flags ) ;
if ( ! req - > ki_list . next )
list_add ( & req - > ki_list , & ctx - > active_reqs ) ;
req - > ki_cancel = cancel ;
spin_unlock_irqrestore ( & ctx - > ctx_lock , flags ) ;
}
EXPORT_SYMBOL ( kiocb_set_cancel_fn ) ;
2015-02-02 16:49:06 +03:00
static int kiocb_cancel ( struct aio_kiocb * kiocb )
2013-05-08 03:18:31 +04:00
{
2013-05-08 03:18:49 +04:00
kiocb_cancel_fn * old , * cancel ;
2013-05-08 03:18:31 +04:00
2013-05-08 03:18:49 +04:00
/*
* Don ' t want to set kiocb - > ki_cancel = KIOCB_CANCELLED unless it
* actually has a cancel function , hence the cmpxchg ( )
*/
cancel = ACCESS_ONCE ( kiocb - > ki_cancel ) ;
do {
if ( ! cancel | | cancel = = KIOCB_CANCELLED )
2013-05-14 00:42:52 +04:00
return - EINVAL ;
2013-05-08 03:18:31 +04:00
2013-05-08 03:18:49 +04:00
old = cancel ;
cancel = cmpxchg ( & kiocb - > ki_cancel , old , KIOCB_CANCELLED ) ;
} while ( cancel ! = old ) ;
2013-05-08 03:18:31 +04:00
2015-02-02 16:49:06 +03:00
return cancel ( & kiocb - > common ) ;
2013-05-08 03:18:31 +04: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
{
2013-10-11 06:31:47 +04:00
struct kioctx * ctx = container_of ( work , struct kioctx , free_work ) ;
2013-04-26 04:58:39 +04:00
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
2013-10-11 06:31:47 +04:00
INIT_WORK ( & ctx - > free_work , free_ioctx ) ;
schedule_work ( & ctx - > free_work ) ;
}
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 ) ;
2013-05-08 03:18:41 +04:00
list_del_init ( & req - > ki_list ) ;
2014-04-22 09:26:58 +04:00
kiocb_cancel ( req ) ;
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 + + )
if ( ! table - > table [ i ] ) {
ctx - > id = i ;
table - > table [ i ] = ctx ;
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 ) ;
table = kzalloc ( sizeof ( * table ) + sizeof ( struct kioctx * ) *
new_nr , GFP_KERNEL ) ;
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
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 ) ;
}
2013-07-30 20:06:37 +04:00
if ( ! nr_events | | ( unsigned long ) nr_events > ( aio_max_nr * 2UL ) )
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 ) ;
ctx - > max_reqs = nr_events ;
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
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
err = aio_setup_ring ( ctx ) ;
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 ) ;
2013-07-30 20:06:37 +04:00
if ( aio_nr + nr_events > ( aio_max_nr * 2UL ) | |
2012-03-11 08:10:35 +04:00
aio_nr + nr_events < 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 ) ;
2014-04-29 20:55:48 +04:00
WARN_ON ( ctx ! = table - > table [ ctx - > id ] ) ;
table - > table [ ctx - > id ] = NULL ;
spin_unlock ( & mm - > ioctx_lock ) ;
2013-06-13 01:04:59 +04:00
2014-04-29 20:55:48 +04:00
/* percpu_ref_kill() will do the necessary call_rcu() */
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 ) {
struct kioctx * ctx = table - > table [ i ] ;
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
}
static bool get_reqs_available ( struct kioctx * ctx )
{
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 ) {
int old , avail = atomic_read ( & ctx - > reqs_available ) ;
do {
if ( avail < ctx - > req_batch )
goto out ;
old = avail ;
avail = atomic_cmpxchg ( & ctx - > reqs_available ,
avail , avail - ctx - > req_batch ) ;
} while ( avail ! = old ) ;
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 ) ;
}
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 .
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
2014-08-24 21:14:05 +04:00
if ( ! get_reqs_available ( ctx ) ) {
user_refill_reqs_available ( ctx ) ;
if ( ! get_reqs_available ( ctx ) )
return NULL ;
}
2013-05-08 03:18:53 +04:00
2013-05-08 03:18:49 +04:00
req = kmem_cache_alloc ( kiocb_cachep , GFP_KERNEL | __GFP_ZERO ) ;
2005-04-17 02:20:36 +04:00
if ( unlikely ( ! req ) )
2013-05-08 03:18:53 +04:00
goto out_put ;
2005-04-17 02:20:36 +04:00
2013-10-11 06:31:47 +04:00
percpu_ref_get ( & ctx - > reqs ) ;
2005-04-17 02:20:36 +04:00
req - > ki_ctx = ctx ;
2011-11-03 00:40:10 +04:00
return req ;
2013-05-08 03:18:53 +04:00
out_put :
2013-04-26 04:58:39 +04:00
put_reqs_available ( ctx , 1 ) ;
2013-05-08 03:18:53 +04:00
return NULL ;
2005-04-17 02:20:36 +04:00
}
2015-02-02 16:49:06 +03:00
static void kiocb_free ( struct aio_kiocb * req )
2005-04-17 02:20:36 +04:00
{
2015-02-02 16:49:06 +03:00
if ( req - > common . ki_filp )
fput ( req - > common . ki_filp ) ;
2009-06-30 22:41:11 +04:00
if ( req - > ki_eventfd ! = NULL )
eventfd_ctx_put ( req - > ki_eventfd ) ;
2005-04-17 02:20:36 +04:00
kmem_cache_free ( kiocb_cachep , req ) ;
}
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
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 = table - > table [ id ] ;
2013-08-08 02:23:48 +04:00
if ( ctx & & ctx - > user_id = = ctx_id ) {
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
percpu_ref_get ( & ctx - > users ) ;
ret = ctx ;
}
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
}
/* aio_complete
* Called when the io request on the given iocb is complete .
*/
2015-02-02 16:49:06 +03:00
static void aio_complete ( struct kiocb * kiocb , long res , long res2 )
2005-04-17 02:20:36 +04:00
{
2015-02-02 16:49:06 +03:00
struct aio_kiocb * iocb = container_of ( kiocb , struct aio_kiocb , common ) ;
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 ;
2005-11-14 03:07:33 +03:00
/*
* Special case handling for sync iocbs :
* - events go directly into the iocb for fast handling
* - the sync task with the iocb in its stack holds the single iocb
* ref , no other paths have a way to get another ref
* - the sync task helpfully left a reference to itself in the iocb
2005-04-17 02:20:36 +04:00
*/
2015-02-02 16:49:06 +03:00
BUG_ON ( is_sync_kiocb ( kiocb ) ) ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:49 +04:00
if ( iocb - > ki_list . next ) {
unsigned long flags ;
spin_lock_irqsave ( & ctx - > ctx_lock , flags ) ;
list_del ( & iocb - > ki_list ) ;
spin_unlock_irqrestore ( & ctx - > ctx_lock , flags ) ;
}
2013-05-08 03:18:39 +04:00
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 ;
2015-02-02 16:49:06 +03:00
event - > obj = ( u64 ) ( unsigned long ) iocb - > ki_user_iocb ;
2005-04-17 02:20:36 +04:00
event - > data = iocb - > ki_user_data ;
event - > res = res ;
event - > res2 = res2 ;
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
pr_debug ( " %p[%u]: %p: %p %Lx %lx %lx \n " ,
2015-02-02 16:49:06 +03:00
ctx , tail , iocb , iocb - > ki_user_iocb , iocb - > ki_user_data ,
2013-05-08 03:18:35 +04:00
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 .
*/
2009-03-19 03:04:19 +03:00
if ( iocb - > ki_eventfd ! = NULL )
2008-04-11 08:29:19 +04:00
eventfd_signal ( iocb - > ki_eventfd , 1 ) ;
2005-04-17 02:20:36 +04:00
/* everything turned out well, dispose of the aiocb. */
2013-05-14 00:42:52 +04:00
kiocb_free ( iocb ) ;
2005-04-17 02:20:36 +04:00
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 ) ;
2013-10-11 06:31:47 +04:00
percpu_ref_put ( & ctx - > reqs ) ;
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 ;
avail = min ( avail , nr - ret ) ;
avail = min_t ( long , avail , AIO_EVENTS_PER_PAGE -
( ( head + AIO_EVENTS_OFFSET ) % AIO_EVENTS_PER_PAGE ) ) ;
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 ;
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 ,
struct timespec __user * timeout )
{
2013-05-08 03:18:45 +04:00
ktime_t until = { . tv64 = KTIME_MAX } ;
long ret = 0 ;
2005-04-17 02:20:36 +04:00
if ( timeout ) {
struct timespec ts ;
2013-05-08 03:18:45 +04:00
2005-04-17 02:20:36 +04:00
if ( unlikely ( copy_from_user ( & ts , timeout , sizeof ( ts ) ) ) )
2013-05-08 03:18:45 +04:00
return - EFAULT ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
until = timespec_to_ktime ( ts ) ;
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 .
*/
2014-11-06 15:44:36 +03:00
if ( until . tv64 = = 0 )
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 ) ;
2005-04-17 02:20:36 +04:00
2013-05-08 03:18:45 +04:00
if ( ! ret & & signal_pending ( current ) )
ret = - EINTR ;
2005-04-17 02:20:36 +04:00
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 ;
}
/* 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 ;
}
2014-02-12 03:37:41 +04:00
typedef ssize_t ( rw_iter_op ) ( struct kiocb * , struct iov_iter * ) ;
2013-05-08 03:19:11 +04:00
2015-03-21 03:40:18 +03:00
static int aio_setup_vectored_rw ( int rw , char __user * buf , size_t len ,
struct iovec * * iovec ,
bool compat ,
struct iov_iter * iter )
2006-10-01 10:28:49 +04:00
{
2010-05-27 01:44:26 +04:00
# ifdef CONFIG_COMPAT
if ( compat )
2015-03-22 02:34:53 +03:00
return compat_import_iovec ( rw ,
2013-02-26 04:36:27 +04:00
( struct compat_iovec __user * ) buf ,
2015-03-22 02:34:53 +03:00
len , UIO_FASTIOV , iovec , iter ) ;
2010-05-27 01:44:26 +04:00
# endif
2015-03-22 02:34:53 +03:00
return import_iovec ( rw , ( struct iovec __user * ) buf ,
len , UIO_FASTIOV , iovec , iter ) ;
2006-10-01 10:28:49 +04:00
}
2005-04-17 02:20:36 +04:00
/*
2014-07-23 14:03:53 +04:00
* aio_run_iocb :
* Performs the initial checks and io submission .
2005-04-17 02:20:36 +04:00
*/
2013-02-26 04:36:27 +04:00
static ssize_t aio_run_iocb ( struct kiocb * req , unsigned opcode ,
2015-02-11 21:56:46 +03:00
char __user * buf , size_t len , bool compat )
2005-04-17 02:20:36 +04:00
{
2013-05-08 03:19:11 +04:00
struct file * file = req - > ki_filp ;
ssize_t ret ;
int rw ;
fmode_t mode ;
2014-02-12 03:37:41 +04:00
rw_iter_op * iter_op ;
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 ;
2005-04-17 02:20:36 +04:00
2013-02-26 04:36:27 +04:00
switch ( opcode ) {
2005-04-17 02:20:36 +04:00
case IOCB_CMD_PREAD :
2006-10-01 10:28:49 +04:00
case IOCB_CMD_PREADV :
2013-05-08 03:19:11 +04:00
mode = FMODE_READ ;
rw = READ ;
2014-02-12 03:37:41 +04:00
iter_op = file - > f_op - > read_iter ;
2013-05-08 03:19:11 +04:00
goto rw_common ;
case IOCB_CMD_PWRITE :
2006-10-01 10:28:49 +04:00
case IOCB_CMD_PWRITEV :
2013-05-08 03:19:11 +04:00
mode = FMODE_WRITE ;
rw = WRITE ;
2014-02-12 03:37:41 +04:00
iter_op = file - > f_op - > write_iter ;
2013-05-08 03:19:11 +04:00
goto rw_common ;
rw_common :
if ( unlikely ( ! ( file - > f_mode & mode ) ) )
return - EBADF ;
2015-04-04 08:14:53 +03:00
if ( ! iter_op )
2013-05-08 03:19:11 +04:00
return - EINVAL ;
2015-02-11 21:56:46 +03:00
if ( opcode = = IOCB_CMD_PREADV | | opcode = = IOCB_CMD_PWRITEV )
2015-03-21 03:40:18 +03:00
ret = aio_setup_vectored_rw ( rw , buf , len ,
& iovec , compat , & iter ) ;
2015-03-22 02:34:53 +03:00
else {
2015-03-22 02:11:55 +03:00
ret = import_single_range ( rw , buf , len , iovec , & iter ) ;
2015-03-22 02:34:53 +03:00
iovec = NULL ;
}
2014-05-01 07:31:28 +04:00
if ( ! ret )
2015-03-21 03:40:18 +03:00
ret = rw_verify_area ( rw , file , & req - > ki_pos ,
iov_iter_count ( & iter ) ) ;
2013-02-26 04:36:27 +04:00
if ( ret < 0 ) {
2015-03-22 02:34:53 +03:00
kfree ( iovec ) ;
2013-05-08 03:19:11 +04:00
return ret ;
2013-02-26 04:36:27 +04:00
}
2013-05-08 03:19:11 +04:00
2015-02-11 21:56:46 +03:00
len = ret ;
2013-05-08 03:19:11 +04:00
2013-05-10 02:03:42 +04:00
if ( rw = = WRITE )
file_start_write ( file ) ;
2015-04-04 08:14:53 +03:00
ret = iter_op ( req , & iter ) ;
2013-05-10 02:03:42 +04:00
if ( rw = = WRITE )
file_end_write ( file ) ;
2015-03-22 02:34:53 +03:00
kfree ( iovec ) ;
2005-04-17 02:20:36 +04:00
break ;
2013-05-08 03:19:11 +04:00
2005-04-17 02:20:36 +04:00
case IOCB_CMD_FDSYNC :
2013-05-08 03:19:11 +04:00
if ( ! file - > f_op - > aio_fsync )
return - EINVAL ;
ret = file - > f_op - > aio_fsync ( req , 1 ) ;
2005-04-17 02:20:36 +04:00
break ;
2013-05-08 03:19:11 +04:00
2005-04-17 02:20:36 +04:00
case IOCB_CMD_FSYNC :
2013-05-08 03:19:11 +04:00
if ( ! file - > f_op - > aio_fsync )
return - EINVAL ;
ret = file - > f_op - > aio_fsync ( req , 0 ) ;
2005-04-17 02:20:36 +04:00
break ;
2013-05-08 03:19:11 +04:00
2005-04-17 02:20:36 +04:00
default :
2013-05-08 03:18:35 +04:00
pr_debug ( " EINVAL: no operation provided \n " ) ;
2013-05-08 03:19:11 +04:00
return - EINVAL ;
2005-04-17 02:20:36 +04:00
}
2013-05-08 03:19:11 +04:00
if ( ret ! = - EIOCBQUEUED ) {
/*
* There ' s no easy way to restart the syscall since other AIO ' s
* may be already running . Just fail this IO with EINTR .
*/
if ( unlikely ( ret = = - ERESTARTSYS | | ret = = - ERESTARTNOINTR | |
ret = = - ERESTARTNOHAND | |
ret = = - ERESTART_RESTARTBLOCK ) )
ret = - EINTR ;
aio_complete ( req , ret , 0 ) ;
}
2005-04-17 02:20:36 +04:00
return 0 ;
}
2008-04-29 11:58:57 +04:00
static int io_submit_one ( struct kioctx * ctx , struct iocb __user * user_iocb ,
2013-05-08 03:18:53 +04:00
struct iocb * iocb , bool compat )
2005-04-17 02:20:36 +04:00
{
2015-02-02 16:49:06 +03:00
struct aio_kiocb * req ;
2005-04-17 02:20:36 +04:00
ssize_t ret ;
/* enforce forwards compatibility on users */
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 ( unlikely ( iocb - > aio_reserved1 | | iocb - > aio_reserved2 ) ) {
2013-05-08 03:18:35 +04:00
pr_debug ( " EINVAL: reserve field set \n " ) ;
2005-04-17 02:20:36 +04:00
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 )
) ) {
2015-02-04 16:15:59 +03:00
pr_debug ( " EINVAL: overflow check \n " ) ;
2005-04-17 02:20:36 +04:00
return - EINVAL ;
}
2013-05-08 03:19:11 +04:00
req = aio_get_req ( ctx ) ;
2013-05-08 03:18:37 +04:00
if ( unlikely ( ! req ) )
2005-04-17 02:20:36 +04:00
return - EAGAIN ;
2013-05-08 03:18:37 +04:00
2015-02-02 16:49:06 +03:00
req - > common . ki_filp = fget ( iocb - > aio_fildes ) ;
if ( unlikely ( ! req - > common . ki_filp ) ) {
2013-05-08 03:18:37 +04:00
ret = - EBADF ;
goto out_put_req ;
2005-04-17 02:20:36 +04:00
}
2015-02-02 16:49:06 +03:00
req - > common . ki_pos = iocb - > aio_offset ;
req - > common . ki_complete = aio_complete ;
2015-04-09 20:52:01 +03:00
req - > common . ki_flags = iocb_flags ( req - > common . ki_filp ) ;
2013-05-08 03:18:37 +04:00
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 ( iocb - > aio_flags & IOCB_FLAG_RESFD ) {
/*
* 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 .
*/
2009-06-30 22:41:11 +04:00
req - > ki_eventfd = eventfd_ctx_fdget ( ( int ) iocb - > aio_resfd ) ;
2008-04-29 12:03:09 +04:00
if ( IS_ERR ( req - > ki_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
ret = PTR_ERR ( req - > ki_eventfd ) ;
2009-03-19 03:04:19 +03:00
req - > ki_eventfd = NULL ;
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
goto out_put_req ;
}
2015-02-02 16:49:06 +03:00
req - > common . ki_flags | = IOCB_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
}
2005-04-17 02:20:36 +04:00
2013-05-08 03:19:10 +04:00
ret = put_user ( KIOCB_KEY , & user_iocb - > aio_key ) ;
2005-04-17 02:20:36 +04:00
if ( unlikely ( ret ) ) {
2013-05-08 03:18:35 +04:00
pr_debug ( " EFAULT: aio_key \n " ) ;
2005-04-17 02:20:36 +04:00
goto out_put_req ;
}
2015-02-02 16:49:06 +03:00
req - > ki_user_iocb = user_iocb ;
2005-04-17 02:20:36 +04:00
req - > ki_user_data = iocb - > aio_data ;
2015-02-02 16:49:06 +03:00
ret = aio_run_iocb ( & req - > common , iocb - > aio_lio_opcode ,
2013-02-26 04:36:27 +04:00
( char __user * ) ( unsigned long ) iocb - > aio_buf ,
2015-02-11 21:56:46 +03:00
iocb - > aio_nbytes ,
2013-02-26 04:36:27 +04:00
compat ) ;
2013-05-08 03:18:25 +04:00
if ( ret )
2011-02-26 01:44:27 +03:00
goto out_put_req ;
2013-05-08 03:18:25 +04:00
2005-04-17 02:20:36 +04:00
return 0 ;
out_put_req :
2013-04-26 04:58:39 +04:00
put_reqs_available ( ctx , 1 ) ;
2013-10-11 06:31:47 +04:00
percpu_ref_put ( & ctx - > reqs ) ;
2013-05-14 00:42:52 +04:00
kiocb_free ( req ) ;
2005-04-17 02:20:36 +04:00
return ret ;
}
2010-05-27 01:44:26 +04:00
long do_io_submit ( aio_context_t ctx_id , long nr ,
struct iocb __user * __user * iocbpp , bool compat )
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 ;
2010-09-11 01:16:00 +04:00
if ( unlikely ( nr > LONG_MAX / sizeof ( * iocbpp ) ) )
nr = LONG_MAX / sizeof ( * iocbpp ) ;
2005-04-17 02:20:36 +04:00
if ( unlikely ( ! access_ok ( VERIFY_READ , iocbpp , ( nr * sizeof ( * iocbpp ) ) ) ) )
return - EFAULT ;
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 ;
}
2010-07-01 09:55:01 +04:00
blk_start_plug ( & plug ) ;
2005-04-17 02:20:36 +04:00
/*
* AKPM : should this return a partial result if some of the IOs were
* successfully submitted ?
*/
for ( i = 0 ; i < nr ; i + + ) {
struct iocb __user * user_iocb ;
struct iocb tmp ;
if ( unlikely ( __get_user ( user_iocb , iocbpp + i ) ) ) {
ret = - EFAULT ;
break ;
}
if ( unlikely ( copy_from_user ( & tmp , user_iocb , sizeof ( tmp ) ) ) ) {
ret = - EFAULT ;
break ;
}
2013-05-08 03:18:53 +04:00
ret = io_submit_one ( ctx , user_iocb , & tmp , compat ) ;
2005-04-17 02:20:36 +04:00
if ( ret )
break ;
}
2010-07-01 09:55:01 +04:00
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 ;
}
2010-05-27 01:44:26 +04: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 )
{
return do_io_submit ( ctx_id , nr , iocbpp , 0 ) ;
}
2005-04-17 02:20:36 +04:00
/* lookup_kiocb
* Finds a given iocb for cancellation .
*/
2015-02-02 16:49:06 +03:00
static struct aio_kiocb *
lookup_kiocb ( struct kioctx * ctx , struct iocb __user * iocb , u32 key )
2005-04-17 02:20:36 +04:00
{
2015-02-02 16:49:06 +03:00
struct aio_kiocb * kiocb ;
2005-11-14 03:07:34 +03:00
assert_spin_locked ( & ctx - > ctx_lock ) ;
2013-05-08 03:19:10 +04:00
if ( key ! = KIOCB_KEY )
return NULL ;
2005-04-17 02:20:36 +04:00
/* TODO: use a hash or array, this sucks. */
2015-02-02 16:49:06 +03:00
list_for_each_entry ( kiocb , & ctx - > active_reqs , ki_list ) {
if ( kiocb - > ki_user_iocb = = iocb )
2005-04-17 02:20:36 +04:00
return kiocb ;
}
return NULL ;
}
/* 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 ;
2005-04-17 02:20:36 +04:00
u32 key ;
int ret ;
ret = get_user ( key , & iocb - > aio_key ) ;
if ( unlikely ( ret ) )
return - EFAULT ;
ctx = lookup_ioctx ( ctx_id ) ;
if ( unlikely ( ! ctx ) )
return - EINVAL ;
spin_lock_irq ( & ctx - > ctx_lock ) ;
2013-05-08 03:18:31 +04:00
2005-04-17 02:20:36 +04:00
kiocb = lookup_kiocb ( ctx , iocb , key ) ;
2013-05-08 03:18:31 +04:00
if ( kiocb )
2014-04-22 09:26:58 +04:00
ret = kiocb_cancel ( kiocb ) ;
2013-05-08 03:18:31 +04:00
else
ret = - EINVAL ;
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 ;
}
/* 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
*/
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 ,
struct timespec __user * , timeout )
2005-04-17 02:20:36 +04:00
{
struct kioctx * ioctx = lookup_ioctx ( ctx_id ) ;
long ret = - EINVAL ;
if ( likely ( ioctx ) ) {
2011-01-13 04:01:08 +03:00
if ( likely ( min_nr < = nr & & min_nr > = 0 ) )
2005-04-17 02:20:36 +04:00
ret = read_events ( ioctx , min_nr , nr , events , timeout ) ;
2013-05-29 02:14:48 +04:00
percpu_ref_put ( & ioctx - > users ) ;
2005-04-17 02:20:36 +04:00
}
return ret ;
}