All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Kozik <ivan@ludios.org>
To: stable@vger.kernel.org
Cc: linux-xfs@vger.kernel.org, darrick.wong@oracle.com,
	bfoster@redhat.com, david@fromorbit.com
Subject: Request 2aa6ba7b5ad3 ("clear _XBF_PAGES from buffers when readahead page") for 4.4 stable inclusion
Date: Sat, 25 Mar 2017 07:49:00 +0000	[thread overview]
Message-ID: <20170325074856.GA20773@localhost> (raw)

Hi,

I would like to request that this patch be included in the 4.4 stable tree.  It 
fixes the Bad page state issue discovered at 
http://oss.sgi.com/archives/xfs/2016-08/msg00617.html ('"Bad page state" errors 
when calling BULKSTAT under memory pressure?')

I tested the patch (no changes needed) by applying it to 4.4.52, running a 
program to use almost all of my free memory, then running xfs_fsr on a 
filesystem with > 1.5M files.  Before patch: kernel screams with Bad page state 
/ "count:-1" within a minute.  After patch: no complaints from the kernel. 
I repeated the test several times and on another machine that was affected. 
I have not seen any problems five days later.

Thanks,

Ivan

>From 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <darrick.wong@oracle.com>
Date: Wed, 25 Jan 2017 20:24:57 -0800
Subject: [PATCH] xfs: clear _XBF_PAGES from buffers when readahead page

If we try to allocate memory pages to back an xfs_buf that we're trying
to read, it's possible that we'll be so short on memory that the page
allocation fails.  For a blocking read we'll just wait, but for
readahead we simply dump all the pages we've collected so far.

Unfortunately, after dumping the pages we neglect to clear the
_XBF_PAGES state, which means that the subsequent call to xfs_buf_free
thinks that b_pages still points to pages we own.  It then double-frees
the b_pages pages.

This results in screaming about negative page refcounts from the memory
manager, which xfs oughtn't be triggering.  To reproduce this case,
mount a filesystem where the size of the inodes far outweighs the
availalble memory (a ~500M inode filesystem on a VM with 300MB memory
did the trick here) and run bulkstat in parallel with other memory
eating processes to put a huge load on the system.  The "check summary"
phase of xfs_scrub also works for this purpose.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
---
 fs/xfs/xfs_buf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 7f0a01f7b592..ac3b4db519df 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -422,6 +422,7 @@ retry:
 out_free_pages:
 	for (i = 0; i < bp->b_page_count; i++)
 		__free_page(bp->b_pages[i]);
+	bp->b_flags &= ~_XBF_PAGES;
 	return error;
 }
 
-- 
2.11.0


WARNING: multiple messages have this Message-ID (diff)
From: Ivan Kozik <ivan@ludios.org>
To: stable@vger.kernel.org
Cc: linux-xfs@vger.kernel.org, darrick.wong@oracle.com,
	bfoster@redhat.com, david@fromorbit.com
Subject: Request 2aa6ba7b5ad3 ("clear _XBF_PAGES from buffers when readahead page") for 4.4 stable inclusion
Date: Sat, 25 Mar 2017 07:49:00 +0000	[thread overview]
Message-ID: <20170325074856.GA20773@localhost> (raw)

Hi,

I would like to request that this patch be included in the 4.4 stable tree.  It 
fixes the Bad page state issue discovered at 
http://oss.sgi.com/archives/xfs/2016-08/msg00617.html ('"Bad page state" errors 
when calling BULKSTAT under memory pressure?')

I tested the patch (no changes needed) by applying it to 4.4.52, running a 
program to use almost all of my free memory, then running xfs_fsr on a 
filesystem with > 1.5M files.  Before patch: kernel screams with Bad page state 
/ "count:-1" within a minute.  After patch: no complaints from the kernel. 
I repeated the test several times and on another machine that was affected. 
I have not seen any problems five days later.

Thanks,

Ivan

>>From 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b Mon Sep 17 00:00:00 2001
From: "Darrick J. Wong" <darrick.wong@oracle.com>
Date: Wed, 25 Jan 2017 20:24:57 -0800
Subject: [PATCH] xfs: clear _XBF_PAGES from buffers when readahead page

If we try to allocate memory pages to back an xfs_buf that we're trying
to read, it's possible that we'll be so short on memory that the page
allocation fails.  For a blocking read we'll just wait, but for
readahead we simply dump all the pages we've collected so far.

Unfortunately, after dumping the pages we neglect to clear the
_XBF_PAGES state, which means that the subsequent call to xfs_buf_free
thinks that b_pages still points to pages we own.  It then double-frees
the b_pages pages.

This results in screaming about negative page refcounts from the memory
manager, which xfs oughtn't be triggering.  To reproduce this case,
mount a filesystem where the size of the inodes far outweighs the
availalble memory (a ~500M inode filesystem on a VM with 300MB memory
did the trick here) and run bulkstat in parallel with other memory
eating processes to put a huge load on the system.  The "check summary"
phase of xfs_scrub also works for this purpose.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
---
 fs/xfs/xfs_buf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 7f0a01f7b592..ac3b4db519df 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -422,6 +422,7 @@ retry:
 out_free_pages:
 	for (i = 0; i < bp->b_page_count; i++)
 		__free_page(bp->b_pages[i]);
+	bp->b_flags &= ~_XBF_PAGES;
 	return error;
 }
 
-- 
2.11.0

             reply	other threads:[~2017-03-25  7:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-25  7:49 Ivan Kozik [this message]
2017-03-25  7:49 ` Request 2aa6ba7b5ad3 ("clear _XBF_PAGES from buffers when readahead page") for 4.4 stable inclusion Ivan Kozik
2017-03-27 17:22 ` Darrick J. Wong
2017-03-28 11:43 ` Greg KH

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=20170325074856.GA20773@localhost \
    --to=ivan@ludios.org \
    --cc=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.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.