Hi Ben, On 03/21/2014 12:30 AM, Benjamin LaHaise wrote: > On Thu, Mar 20, 2014 at 10:32:07AM -0400, Dave Jones wrote: >> On Thu, Mar 20, 2014 at 01:46:25PM +0800, Gu Zheng wrote: >> >> > diff --git a/fs/aio.c b/fs/aio.c >> > index 88ad40c..e353085 100644 >> > --- a/fs/aio.c >> > +++ b/fs/aio.c >> > @@ -319,6 +319,9 @@ static int aio_migratepage(struct address_space >> *mapping, struct page *new, >> > ctx->ring_pages[old->index] = new; >> > spin_unlock_irqrestore(&ctx->completion_lock, flags); >> > >> > + /* Ensure read event is completed before putting old page */ >> > + mutex_lock(&ctx->ring_lock); >> > + mutex_unlock(&ctx->ring_lock); >> > put_page(old); >> > >> > return rc; >> >> This looks a bit weird. Would using a completion work here ? > > Nope. This is actually the most elegant fix I've seen for this approach, > as everything else has relied on adding additional spin locks (which only > end up being needed in the migration case) around access to the ring_pages > on the reader side. That said, this patch is not a complete solution to > the problem, as the update of the ring's head pointer could still get lost > with this patch. I think the right thing is just taking the ring_lock > mutex over the entire page migration operation. That should be safe, as > nowhere else is the ring_lock mutex nested with any other locks.
This one is based on linux-next which has merged the following patch: commit 692c9b8c5ee8d263bb8348171f0bebd3d84eb2c1 Author: Tang Chen <[email protected]> Date: Mon Mar 10 16:15:33 2014 +0800 aio, memory-hotplug: Fix confliction when migrating and accessing ring pages. With this patch, the update of the ring's head pointer is safe because it is protected by completion_lock, so we do not need to enlarge the ring_lock protection region. And on the other side, if we take the ring_lock over the entire page migration operation, reading events will be affected if the page migration is going. Thanks, Gu > > -ben > >> Dave > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
