From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757716AbbFQAjh (ORCPT ); Tue, 16 Jun 2015 20:39:37 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:38030 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757369AbbFQAjL (ORCPT ); Tue, 16 Jun 2015 20:39:11 -0400 Date: Wed, 17 Jun 2015 01:39:06 +0100 From: Al Viro To: Oleg Nesterov Cc: Andrew Morton , Benjamin LaHaise , Jeff Moyer , linux-aio@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] aio: ctx->dead cleanups Message-ID: <20150617003906.GC17109@ZenIV.linux.org.uk> References: <20150616230414.GA15776@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150616230414.GA15776@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 17, 2015 at 01:04:14AM +0200, Oleg Nesterov wrote: > Al, please help. We are trying to backport some aio fixes and I am > absolutely confused by your b2edffdd912b "fix mremap() vs. ioctx_kill() > race". > > > Firstly, I simply can't understand what exactly it tries to fix. OK, > aio_free_ring() can race with kill and we can remap the soon-to-be-killed > ctx. So what? kill_ioctx() will the the correct (already re-mapped) > ctx->mmap_base after it drops mm->ioctx_lock. Huh? kill_ioctx() picks ctx->mmap_base and passes it to vm_munmap(). Which tries to grab mmap_sem, blocks for mremap() from another thread and waits for it to drop mmap_sem. By that time ctx->mmap_base has nothing whatsoever to the argument we'd passed to vm_munmap(). Sure, it had been recalculated by aio_ring_remap(), but it's too late for us - we'd already fetched the old value.