Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946092AbXBIEfa (ORCPT ); Thu, 8 Feb 2007 23:35:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946097AbXBIEfa (ORCPT ); Thu, 8 Feb 2007 23:35:30 -0500 Received: from smtp.osdl.org ([65.172.181.24]:54701 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946092AbXBIEf2 (ORCPT ); Thu, 8 Feb 2007 23:35:28 -0500 Date: Thu, 8 Feb 2007 20:35:07 -0800 From: Andrew Morton To: "Ananiev, Leonid I" Cc: , "linux-aio" , "Zach Brown" , , "Chris Mason" , "Badari Pulavarty" Subject: Re: [PATCH] aio: fix kernel bug when page is temporally busy Message-Id: <20070208203507.347cff98.akpm@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3899 Lines: 90 On Fri, 9 Feb 2007 07:29:31 +0300 "Ananiev, Leonid I" wrote: > >From Leonid Ananiev > > Fix "Kernel BUG at fs/aio.c:509". Return EIOCBRETRY but not EIO if page > is busy. > > Signed-off-by: Leonid Ananiev > > "Kernel BUG at fs/aio.c:509" > http://marc.theaimsgroup.com/?l=linux-kernel&m=117031052517746&w=2 > is present in 2.6.20 as well as 2.6.19. > The investigation shows that the bug's panic occurs when aio_complete() > is called with argument ret=EIO which is returned from > invalidate_inode_pages2_range() because the page is temporally busy. > Call Trace: > [] invalidate_inode_pages2_range+0x236/0x26b > [] ext3_direct_IO+0x16c/0x19e > [] ext3_get_block+0x0/0xe2 > [] generic_file_direct_IO+0xb9/0xcf > [] generic_file_direct_write+0x67/0x10e > [] __generic_file_aio_write_nolock+0x2d6/0x3fe > [] __switch_to+0x26f/0x27e > [] thread_return+0x0/0xd8 > [] generic_file_aio_write+0x67/0xc7 > [] ext3_file_write+0x0/0x8f > [] ext3_file_write+0x16/0x8f > [] ext3_file_write+0x0/0x8f > [] aio_rw_vect_retry+0x72/0x14f > [] aio_run_iocb+0xe6/0x187 > [] io_submit_one+0x296/0x2e3 > [] sys_io_submit+0x9b/0x108 > [] default_wake_function+0x0/0xe > [] system_call+0x7e/0x83 > > As a result aio_complete() is called while it should not be. > When IO is finished aio_complete() is called once more > and iocb->ki_users becomes negative. > > Taking into account aio.c lines in aio_run_iocb() > if (ret != -EIOCBRETRY && ret != -EIOCBQUEUED) { > aio_complete(iocb, ret, 0); > > proposed patch makes function invalidate_inode_pages2_range() > to return EIOCBRETRY but not EIO if page is busy. > The patch is tested on 2.6.20. > > --- linux-2.6.20/mm/truncate.c 2007-02-04 10:44:54.000000000 -0800 > +++ linux-2.6.20p/mm/truncate.c 2007-02-08 11:38:11.000000000 -0800 > @@ -366,7 +366,7 @@ static int do_launder_page(struct addres > * Any pages which are found to be mapped into pagetables are unmapped > prior to > * invalidation. > * > - * Returns -EIO if any pages could not be invalidated. > + * Returns -EIOCBRETRY if any pages could not be invalidated. > */ > int invalidate_inode_pages2_range(struct address_space *mapping, > pgoff_t start, pgoff_t end) > @@ -423,7 +423,7 @@ int invalidate_inode_pages2_range(struct > } > ret = do_launder_page(mapping, page); > if (ret == 0 && > !invalidate_complete_page2(mapping, page)) > - ret = -EIO; > + ret = -EIOCBRETRY; > unlock_page(page); > } > pagevec_release(&pvec); > @@ -440,7 +440,7 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages > * Any pages which are found to be mapped into pagetables are unmapped > prior to > * invalidation. > * > - * Returns -EIO if any pages could not be invalidated. > + * Returns -EIOCBRETRY if any pages could not be invalidated. > */ > int invalidate_inode_pages2(struct address_space *mapping) > { The patch is wildly wordwrapped and has had it tabs replaced with spaces. invalidate_inode_pages2() has other callers. I suspect with this change we'll end up leaking EIOCBRETRY back to userspace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/