Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757834Ab0AOA0L (ORCPT ); Thu, 14 Jan 2010 19:26:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757137Ab0AOA0K (ORCPT ); Thu, 14 Jan 2010 19:26:10 -0500 Received: from mail.parknet.co.jp ([210.171.160.6]:37871 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756915Ab0AOA0J (ORCPT ); Thu, 14 Jan 2010 19:26:09 -0500 From: OGAWA Hirofumi To: Andrew Morton Cc: Linus Torvalds , Nick Piggin , Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, stable@kernel.org Subject: Re: [PATCH] vfs: Fix vmtruncate() regression References: <876378jxhx.fsf@devron.myhome.or.jp> <20100113060734.GC3901@nick> <87r5pucin4.fsf@devron.myhome.or.jp> <877hrmcicu.fsf@devron.myhome.or.jp> <20100114143044.cc65be51.akpm@linux-foundation.org> Date: Fri, 15 Jan 2010 09:26:02 +0900 In-Reply-To: <20100114143044.cc65be51.akpm@linux-foundation.org> (Andrew Morton's message of "Thu, 14 Jan 2010 14:30:44 -0800") Message-ID: <87ska86wo5.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3133 Lines: 74 Andrew Morton writes: > On Wed, 13 Jan 2010 21:14:09 +0900 > OGAWA Hirofumi wrote: > >> >> If __block_prepare_write() was failed in block_write_begin(), the >> allocated blocks can be outside of ->i_size. >> >> But new truncate_pagecache() in vmtuncate() does nothing if new < old. >> It means the above usage is not working anymore. >> >> So, this patch fixes it by removing "new < old" check. It would need >> more cleanup/change. But, now -rc and truncate working is in progress, >> so, this tried to fix it minimum change. >> >> Acked-by: Nick Piggin >> Signed-off-by: OGAWA Hirofumi >> --- >> >> mm/truncate.c | 28 +++++++++++++--------------- >> 1 file changed, 13 insertions(+), 15 deletions(-) >> >> diff -puN mm/truncate.c~truncate_pagecache-fix mm/truncate.c >> --- linux-2.6/mm/truncate.c~truncate_pagecache-fix 2010-01-12 05:43:06.000000000 +0900 >> +++ linux-2.6-hirofumi/mm/truncate.c 2010-01-12 05:43:06.000000000 +0900 >> @@ -522,22 +522,20 @@ EXPORT_SYMBOL_GPL(invalidate_inode_pages >> */ >> void truncate_pagecache(struct inode *inode, loff_t old, loff_t new) >> { >> - if (new < old) { >> - struct address_space *mapping = inode->i_mapping; >> + struct address_space *mapping = inode->i_mapping; >> >> - /* >> - * unmap_mapping_range is called twice, first simply for >> - * efficiency so that truncate_inode_pages does fewer >> - * single-page unmaps. However after this first call, and >> - * before truncate_inode_pages finishes, it is possible for >> - * private pages to be COWed, which remain after >> - * truncate_inode_pages finishes, hence the second >> - * unmap_mapping_range call must be made for correctness. >> - */ >> - unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1); >> - truncate_inode_pages(mapping, new); >> - unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1); >> - } >> + /* >> + * unmap_mapping_range is called twice, first simply for >> + * efficiency so that truncate_inode_pages does fewer >> + * single-page unmaps. However after this first call, and >> + * before truncate_inode_pages finishes, it is possible for >> + * private pages to be COWed, which remain after >> + * truncate_inode_pages finishes, hence the second >> + * unmap_mapping_range call must be made for correctness. >> + */ >> + unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1); >> + truncate_inode_pages(mapping, new); >> + unmap_mapping_range(mapping, new + PAGE_SIZE - 1, 0, 1); >> } >> EXPORT_SYMBOL(truncate_pagecache); > > The fix was applied to 2.6.33-rcX > (cedabed49b39b4319bccc059a63344b6232b619c), appears to be needed in > 2.6.32.x but no cc:stable's are present? Ah, yes. I forgot to add "Cc: stable". Please apply this to 2.6.32.x. -- OGAWA Hirofumi -- 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/