Bug 9738

Reply-To: wfg@mail.ustc.edu.cn

On Sat, Jan 12, 2008 at 12:20:20PM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9738

Joerg and me has comfirmed that this patch can fix the bug:


clear PAGECACHE_TAG_DIRTY for truncated page in block_write_full_page()

The `truncated' page in block_write_full_page() may stick for a long time.
E.g. ext2_rmdir() will set i_size to 0, and then the dir inode may hang around
because of being referenced by someone.

So clear PAGECACHE_TAG_DIRTY to prevent pdflush from retrying and iowaiting on
it.

Tested-by: Joerg Platte <jplatte@naasa.net>
Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
---
fs/buffer.c |    2 ++
 1 files changed, 2 insertions(+)

Index: linux/fs/buffer.c
===================================================================
--- linux.orig/fs/buffer.c
+++ linux/fs/buffer.c
@@ -2820,7 +2820,9 @@ int block_write_full_page(struct page *p
 		 * freeable here, so the page does not leak.
 		 */
 		do_invalidatepage(page, 0);
+		set_page_writeback(page);
 		unlock_page(page);
+		end_page_writeback(page);
 		return 0; /* don't care */
 	}
 

Reply-To: akpm@linux-foundation.org

On Mon, 14 Jan 2008 21:00:06 +0800
Fengguang Wu <wfg@mail.ustc.edu.cn> wrote:

> On Sat, Jan 12, 2008 at 12:20:20PM -0800, bugme-daemon@bugzilla.kernel.org
> wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=9738
> 
> Joerg and me has comfirmed that this patch can fix the bug:
> 
> 
> clear PAGECACHE_TAG_DIRTY for truncated page in block_write_full_page()
> 
> The `truncated' page in block_write_full_page() may stick for a long time.
> E.g. ext2_rmdir() will set i_size to 0, and then the dir inode may hang
> around
> because of being referenced by someone.
> 
> So clear PAGECACHE_TAG_DIRTY to prevent pdflush from retrying and iowaiting
> on
> it.
> 
> Tested-by: Joerg Platte <jplatte@naasa.net>
> Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
> ---
> fs/buffer.c |    2 ++
>  1 files changed, 2 insertions(+)
> 
> Index: linux/fs/buffer.c
> ===================================================================
> --- linux.orig/fs/buffer.c
> +++ linux/fs/buffer.c
> @@ -2820,7 +2820,9 @@ int block_write_full_page(struct page *p
>                * freeable here, so the page does not leak.
>                */
>               do_invalidatepage(page, 0);
> +             set_page_writeback(page);
>               unlock_page(page);
> +             end_page_writeback(page);
>               return 0; /* don't care */
>       }
>  

But seven minutes earlier you recommended that we revert 
2e6883bdf49abd0e7f0d9b6297fc3be7ebb2250b.  Please clarify?

Reply-To: wfg@mail.ustc.edu.cn

On Mon, Jan 14, 2008 at 05:06:47PM -0800, Andrew Morton wrote:
> On Mon, 14 Jan 2008 21:00:06 +0800
> Fengguang Wu <wfg@mail.ustc.edu.cn> wrote:
> 
> > On Sat, Jan 12, 2008 at 12:20:20PM -0800, bugme-daemon@bugzilla.kernel.org
> wrote:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9738
> > 
> > Joerg and me has comfirmed that this patch can fix the bug:
> > 
> > 
> > clear PAGECACHE_TAG_DIRTY for truncated page in block_write_full_page()
> > 
> > The `truncated' page in block_write_full_page() may stick for a long time.
> > E.g. ext2_rmdir() will set i_size to 0, and then the dir inode may hang
> around
> > because of being referenced by someone.
> > 
> > So clear PAGECACHE_TAG_DIRTY to prevent pdflush from retrying and iowaiting
> on
> > it.
> > 
> > Tested-by: Joerg Platte <jplatte@naasa.net>
> > Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
> > ---
> > fs/buffer.c |    2 ++
> >  1 files changed, 2 insertions(+)
> > 
> > Index: linux/fs/buffer.c
> > ===================================================================
> > --- linux.orig/fs/buffer.c
> > +++ linux/fs/buffer.c
> > @@ -2820,7 +2820,9 @@ int block_write_full_page(struct page *p
> >              * freeable here, so the page does not leak.
> >              */
> >             do_invalidatepage(page, 0);
> > +           set_page_writeback(page);
> >             unlock_page(page);
> > +           end_page_writeback(page);
> >             return 0; /* don't care */
> >     }
> >  
> 
> But seven minutes earlier you recommended that we revert 
> 2e6883bdf49abd0e7f0d9b6297fc3be7ebb2250b.  Please clarify?

OK. Please revert 2e6883bdf49abd0e7f0d9b6297fc3be7ebb2250b and ignore
this patch. I'll resend them both for -mm later on, in a more complete
patchset.

Fengguang

Problem-causing commit was reverted in commit c23f72cae9523d29ff94eec8f30ccbdaf234b20e.