From: Oleg Nesterov <oleg@redhat.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Benjamin LaHaise <bcrl@kvack.org>,
linux-aio@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/3] aio_ring_remap: kill the bogus ctx->dead check
Date: Fri, 19 Jun 2015 19:55:06 +0200 [thread overview]
Message-ID: <20150619175506.GA19348@redhat.com> (raw)
In-Reply-To: <x49h9q4aiqx.fsf@segfault.boston.devel.redhat.com>
On 06/18, Jeff Moyer wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > 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.
>
> I don't think this paragraph really fits with the patch. It's
> interesting commentary,
Well, this time I disagree. It would be better to add a comment, but the
changelog can help too to understand the code and potential problems if
it races with kill_ioctx().
> but if you feel strongly enough about it, send a
> patch that undoes b2edffdd912b. ;-)
No, I think that commit makes sense. Just it was wrong and we need to
fix it. And, in particular, its changelog was wrong (at least confusing),
it looks as if there are strong reasons to prevent this race. So the
changelog above can unconfuse the git-log reader.
But. I never argue with maintainers about non-technical issues ;)
> So, drop that paragraph from the commit message, and you can add my
> reviewed by. The patch itself looks good to me.
OK, I am sending v5 with your reviewed-by.
Thanks!
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-06-19 17:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 18:39 [PATCH v4 0/3] aio: ctx->dead cleanups Oleg Nesterov
2015-06-18 18:40 ` [PATCH v4 1/3] aio_ring_remap: kill the bogus ctx->dead check Oleg Nesterov
2015-06-18 20:01 ` Jeff Moyer
2015-06-19 17:55 ` Oleg Nesterov [this message]
2015-06-19 18:46 ` Jeff Moyer
2015-06-18 18:40 ` [PATCH v4 2/3] aio: make aio_ring->dead boolean Oleg Nesterov
2015-06-18 18:40 ` [PATCH v4 3/3] aio_free_ring: don't do page_count(NULL) Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150619175506.GA19348@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bcrl@kvack.org \
--cc=jmoyer@redhat.com \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox