All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: akpm@linux-foundation.org
Cc: mm-commits@vger.kernel.org, chris.mason@oracle.com,
	jeffm@suse.com, maximlevitsky@gmail.com, peterz@infradead.org,
	stable@kernel.org, lkml <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: + reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file .patch added to -mm tree
Date: Thu, 25 Oct 2007 10:37:08 +0800	[thread overview]
Message-ID: <393279833.15570@ustc.edu.cn> (raw)
Message-ID: <E1Iksaq-0006pr-Hv@localhost> (raw)
In-Reply-To: <200710242307.l9ON7btk017173@imap1.linux-foundation.org>

On Wed, Oct 24, 2007 at 04:07:37PM -0700, akpm@linux-foundation.org wrote:
> 
> The patch titled
>      reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file
> has been added to the -mm tree.  Its filename is
>      reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file.patch
> 
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> 
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
> 
> ------------------------------------------------------
> Subject: reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file
> From: Fengguang Wu <wfg@mail.ustc.edu.cn>
> 
> This is not a new problem in 2.6.23-git17.  2.6.22/2.6.23 is buggy in the
> same way.
> 
> Reiserfs could accumulate dirty sub-page-size files until umount time. 
> They cannot be synced to disk by pdflush routines or explicit `sync'
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sorry it's not that horrible. The *data* will still be written to disk.
Only the inodes will be stuck in I_DIRTY_PAGES state, and the pages
stuck in PAGECACHE_TAG_DIRTY state.

> commands.  Only `umount' can do the trick.
> 
> The direct cause is: the dirty page's PG_dirty is wrongly _cleared_.
> Call trace:
> 	 [<ffffffff8027e920>] cancel_dirty_page+0xd0/0xf0
> 	 [<ffffffff8816d470>] :reiserfs:reiserfs_cut_from_item+0x660/0x710
> 	 [<ffffffff8816d791>] :reiserfs:reiserfs_do_truncate+0x271/0x530
> 	 [<ffffffff8815872d>] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0
> 	 [<ffffffff8815d3d0>] :reiserfs:reiserfs_file_release+0x1e0/0x340
> 	 [<ffffffff802a187c>] __fput+0xcc/0x1b0
> 	 [<ffffffff802a1ba6>] fput+0x16/0x20
> 	 [<ffffffff8029e676>] filp_close+0x56/0x90
> 	 [<ffffffff8029fe0d>] sys_close+0xad/0x110
> 	 [<ffffffff8020c41e>] system_call+0x7e/0x83
> 
> Fix the bug by removing the cancel_dirty_page() call. Tests show that
> it causes no bad behaviors on various write sizes.


  reply	other threads:[~2007-10-25  2:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-24 23:07 + reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file.patch added to -mm tree akpm
2007-10-25  2:37 ` Fengguang Wu [this message]
2007-10-25  2:37   ` + reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file .patch " Fengguang Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=393279833.15570@ustc.edu.cn \
    --to=wfg@mail.ustc.edu.cn \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=jeffm@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.