Hi Ben, On 03/22/2014 02:35 AM, Benjamin LaHaise wrote: > Hi all, > > Based on the issues reported by Tang and Gu, I've come up with the an > alternative fix that avoids adding additional locking in the event read > code path. The fix is to take the ring_lock mutex during page migration, > which is already used to syncronize event readers and thus does not add > any new locking requirements in aio_read_events_ring(). I've dropped > the patches from Tang and Gu as a result. This patch is now in my > git://git.kvack.org/~bcrl/aio-next.git tree and will be sent to Linus > once a few other people chime in with their reviews of this change. > Please review Tang, Gu. Thanks! As I mentioned before: https://lkml.org/lkml/2014/3/20/34 We can put put_aio_ring_file() at the first of the context teardown flow (aio_free_ring). Then, page migration and ctx freeing will have mutual execution guarded by lock_page() v.s. truncate(). So that, the additional spinlock(address_space's private_lock) used to protect use and updates of the mapping's private_data, and the sane check of context is needless, so does the additional percpu_ref_get/put(&ctx->users). But the enlarge ring_lock protection region to remove the additional spin_lock is an elegant method if we ignore the effect to reading events while migrating page is going. Thanks, Gu > > -ben -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
