[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150618175207.GA10055@redhat.com>
Date: Thu, 18 Jun 2015 19:52:07 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Al Viro <viro@...IV.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Benjamin LaHaise <bcrl@...ck.org>,
Jeff Moyer <jmoyer@...hat.com>
Cc: linux-aio@...ck.org, linux-kernel@...r.kernel.org
Subject: [PATCH v3 1/3] aio_ring_remap: kill the bogus ctx->dead check
kill_ioctx() sets ctx->dead and removes ctx from ->ioctx_table
"atomically" under mm->ioctx_lock, so aio_ring_remap() can never
see a dead ctx.
And even -EINVAL doesn't look necessary. Yes, if mremap() races
with kill_ioctx() vm_munmap(ctx->mmap_base, ctx->mmap_size) can
unmap the wrong region. In this case the buggy application should
blame itself. And there are other reasons why that vm_munmap() can
be wrong. Say, an application can mremap() the part of aio region
and then do io_destroy(). We could change aio_ring_remap() to
verify vma->that vma_end - vma->vma_start == ctx->mmap_size but
this won't help if the application does munmap() instead.
Signed-off-by: Oleg Nesterov <oleg@...hat.com>
---
fs/aio.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 480440f..893d300 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -325,14 +325,11 @@ static int aio_ring_remap(struct file *file, struct vm_area_struct *vma)
rcu_read_lock();
table = rcu_dereference(mm->ioctx_table);
for (i = 0; i < table->nr; i++) {
- struct kioctx *ctx;
+ struct kioctx *ctx = table->table[i];
- ctx = table->table[i];
if (ctx && ctx->aio_ring_file == file) {
- if (!atomic_read(&ctx->dead)) {
- ctx->user_id = ctx->mmap_base = vma->vm_start;
- res = 0;
- }
+ ctx->user_id = ctx->mmap_base = vma->vm_start;
+ res = 0;
break;
}
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists