From: Alexander Nyberg <alexn@dsv.su.se>
To: Tobias Hennerich <Tobias@Hennerich.de>
Cc: Timo Hennerich <Timo@Hennerich.de>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
Vladimir Saveliev <vs@namesys.com>
Subject: Re: Strange memory leak in 2.6.x
Date: Thu, 24 Mar 2005 16:18:55 +0100 [thread overview]
Message-ID: <1111677535.2369.4.camel@localhost.localdomain> (raw)
In-Reply-To: <20050323175745.A25998@bart.hennerich.de>
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
> > Just to follow up, did the problems go away when switching to ext3?
>
> The switch has been delayed. Up to now we just reboot the machine every
> 48h - the administrator responsible for the machine is on holiday...
>
> Meanwhile, I noticed, that the latest release candidate has several
> changes which could be quite interesting for us:
>
> <andrea@suse.de>
> [PATCH] orphaned pagecache memleak fix
>
> Chris found that with data journaling a reiserfs pagecache may
> be truncate while still pinned. The truncation removes the
> page->mapping, but the page is still listed in the VM queues
> because it still has buffers. Then during the journaling process,
> a buffer is marked dirty and that sets the PG_dirty bitflag as well
> (in mark_buffer_dirty). After that the page is leaked because it's
> both dirty and without a mapping.
>
> <mason@suse.com>
> [PATCH] reiserfs: make sure data=journal buffers are cleaned on free
>
> In data=journal mode, when blocks are freed and their buffers
> are dirty, reiserfs can remove them from the transaction without
> cleaning them. These buffers never get cleaned, resulting in an
> unfreeable page.
>
> On the other side we don't want to install a rc1-kernel on a important
> system. Up to now we still plan to do the switch to ext3...
>
> If someone would recommend to install a special reiserfs-patch (*not*
> the 12mb of patch-2.6.12-rc1) we would consider that, too! So some
> feedback from "the big sharks" is still very welcome.
>
I've attached the two (small) patches that you mentioned above if you
decide to take another try with reiserfs.
Alex
[-- Attachment #2: reiserfs_page_leak.patch --]
[-- Type: text/x-patch, Size: 1461 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/13 16:16:16-08:00 mason@suse.com
# [PATCH] reiserfs: make sure data=journal buffers are cleaned on free
#
# In data=journal mode, when blocks are freed and their buffers are dirty,
# reiserfs can remove them from the transaction without cleaning them. These
# buffers never get cleaned, resulting in an unfreeable page.
#
# Signed-off-by: Chris Mason <mason@suse.com>
# Signed-off-by: Andrew Morton <akpm@osdl.org>
# Signed-off-by: Linus Torvalds <torvalds@osdl.org>
#
# fs/reiserfs/journal.c
# 2005/03/13 15:29:39-08:00 mason@suse.com +4 -0
# reiserfs: make sure data=journal buffers are cleaned on free
#
diff -Nru a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
--- a/fs/reiserfs/journal.c 2005-03-24 16:05:24 +01:00
+++ b/fs/reiserfs/journal.c 2005-03-24 16:05:24 +01:00
@@ -3011,6 +3011,8 @@
if (!already_cleaned) {
clear_buffer_journal_dirty (bh);
+ clear_buffer_dirty(bh);
+ clear_buffer_journal_test (bh);
put_bh(bh) ;
if (atomic_read(&(bh->b_count)) < 0) {
reiserfs_warning (p_s_sb, "journal-1752: remove from trans, b_count < 0");
@@ -3317,6 +3319,8 @@
** in the current trans
*/
clear_buffer_journal_dirty (cn->bh);
+ clear_buffer_dirty(cn->bh);
+ clear_buffer_journal_test(cn->bh);
cleaned = 1 ;
put_bh(cn->bh) ;
if (atomic_read(&(cn->bh->b_count)) < 0) {
[-- Attachment #3: vm_orphaned_pages.patch --]
[-- Type: text/x-patch, Size: 1768 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/13 16:15:58-08:00 andrea@suse.de
# [PATCH] orphaned pagecache memleak fix
#
# Chris found that with data journaling a reiserfs pagecache may be truncate
# while still pinned. The truncation removes the page->mapping, but the page
# is still listed in the VM queues because it still has buffers. Then during
# the journaling process, a buffer is marked dirty and that sets the PG_dirty
# bitflag as well (in mark_buffer_dirty). After that the page is leaked
# because it's both dirty and without a mapping.
#
# So we must allow pages without mapping and dirty to reach the PagePrivate
# check. The page->mapping will be checked again right after the PagePrivate
# check.
#
# Signed-off-by: Andrea Arcangeli <andrea@suse.de>
# Signed-off-by: Andrew Morton <akpm@osdl.org>
# Signed-off-by: Linus Torvalds <torvalds@osdl.org>
#
# mm/vmscan.c
# 2005/03/13 15:29:39-08:00 andrea@suse.de +13 -1
# orphaned pagecache memleak fix
#
diff -Nru a/mm/vmscan.c b/mm/vmscan.c
--- a/mm/vmscan.c 2005-03-24 16:12:42 +01:00
+++ b/mm/vmscan.c 2005-03-24 16:12:42 +01:00
@@ -313,8 +313,20 @@
*/
if (!is_page_cache_freeable(page))
return PAGE_KEEP;
- if (!mapping)
+ if (!mapping) {
+ /*
+ * Some data journaling orphaned pages can have
+ * page->mapping == NULL while being dirty with clean buffers.
+ */
+ if (PageDirty(page) && PagePrivate(page)) {
+ if (try_to_free_buffers(page)) {
+ ClearPageDirty(page);
+ printk("%s: orphaned page\n", __FUNCTION__);
+ return PAGE_CLEAN;
+ }
+ }
return PAGE_KEEP;
+ }
if (mapping->a_ops->writepage == NULL)
return PAGE_ACTIVATE;
if (!may_write_to_queue(mapping->backing_dev_info))
prev parent reply other threads:[~2005-03-24 15:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-08 12:37 Strange memory leak in 2.6.x Tobias Hennerich
[not found] ` <1110291647.2294.12.camel@boxen>
[not found] ` <20050308154042.A388@bart.hennerich.de>
2005-03-08 16:03 ` Alexander Nyberg
2005-03-09 1:38 ` Andrew Morton
2005-03-09 9:27 ` Tobias Hennerich
2005-03-11 17:32 ` Tobias Hennerich
2005-03-11 18:23 ` Alexander Nyberg
2005-03-12 12:32 ` Tobias Hennerich
2005-03-12 15:08 ` Alexander Nyberg
2005-03-12 18:08 ` Alexander Nyberg
2005-03-12 20:42 ` Tobias Hennerich
[not found] ` <1110661479.3360.11.camel@boxen>
2005-03-14 12:27 ` Timo Hennerich
2005-03-14 14:58 ` Alexander Nyberg
2005-03-17 12:30 ` Tobias Hennerich
2005-03-23 13:41 ` Alexander Nyberg
2005-03-23 16:57 ` Tobias Hennerich
2005-03-24 15:18 ` Alexander Nyberg [this message]
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=1111677535.2369.4.camel@localhost.localdomain \
--to=alexn@dsv.su.se \
--cc=Timo@Hennerich.de \
--cc=Tobias@Hennerich.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vs@namesys.com \
/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.