From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [patch 3/3] fs: fix cont vs deadlock patches Date: Sat, 02 Dec 2006 11:36:32 +1100 Message-ID: <4570CA90.8050203@yahoo.com.au> References: <20061130072058.GA18004@wotan.suse.de> <20061130072202.GB18004@wotan.suse.de> <20061130072247.GC18004@wotan.suse.de> <20061130113241.GC12579@wotan.suse.de> <87r6vkzinv.fsf@duaron.myhome.or.jp> <20061201020910.GC455@wotan.suse.de> <87mz68xoyi.fsf@duaron.myhome.or.jp> <20061201050852.GA31347@wotan.suse.de> <20061130232102.0cc7fc0b.akpm@osdl.org> <20061201075341.GB31347@wotan.suse.de> <87slfzu0ty.fsf@duaron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Nick Piggin , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel@vger.kernel.org Return-path: Received: from smtp105.mail.mud.yahoo.com ([209.191.85.215]:51546 "HELO smtp105.mail.mud.yahoo.com") by vger.kernel.org with SMTP id S1162388AbWLBAh1 (ORCPT ); Fri, 1 Dec 2006 19:37:27 -0500 To: OGAWA Hirofumi In-Reply-To: <87slfzu0ty.fsf@duaron.myhome.or.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org OGAWA Hirofumi wrote: > Nick Piggin writes: > > >>>> status = __block_prepare_write(inode, new_page, zerofrom, >>>> PAGE_CACHE_SIZE, get_block); >>>> if (status) >>>>@@ -2110,7 +2111,7 @@ >>>> memset(kaddr+zerofrom, 0, PAGE_CACHE_SIZE-zerofrom); >>>> flush_dcache_page(new_page); >>>> kunmap_atomic(kaddr, KM_USER0); >>>>- generic_commit_write(NULL, new_page, zerofrom, PAGE_CACHE_SIZE); >>>>+ __block_commit_write(inode, new_page, zerofrom, PAGE_CACHE_SIZE); >>> >>>Whatever function this is doesn't need to update i_size? >> >>Yes, it is the code in cont_prepare_write that is expanding a hole >>at the end of file. >> >>We can do this now because fat_commit_write is now changed to call >>generic_commit_write in the case of a non-zero length. >> >>I think it is an improvement because now the file will not get >>arbitrarily extended in the case of a write failure somewhere down >>the track. > > > Ah, unfortunately we can't this. If we don't update ->i_size before > page_cache_release, pdflush will think these pages is outside ->i_size > and just clean the page without writing it. I see. I guess you need to synchronise your writepage versus this extention in order to handle it properly then. I won't bother with that though: it won't be worse than it was before. Thanks for review, do you agree with the other hunks? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com