From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH v2] xfs: clear _XBF_PAGES from buffers when readahead page allocation fails
Date: Sun, 29 Jan 2017 09:55:17 +1100 [thread overview]
Message-ID: <20170128225517.GE316@dastard> (raw)
In-Reply-To: <20170126035330.GU9134@birch.djwong.org>
On Wed, Jan 25, 2017 at 07:53:30PM -0800, Darrick J. Wong wrote:
> 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>
Can you rename the patch "prevent double free of buffer pages on
readahead failure"? That way people looking for commits to backport
are going to see it clearly and easily....
And I think it also needs a stable cc....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-01-29 0:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 3:53 [PATCH v2] xfs: clear _XBF_PAGES from buffers when readahead page allocation fails Darrick J. Wong
2017-01-26 4:14 ` Eric Sandeen
2017-01-28 22:55 ` Dave Chinner [this message]
2017-01-30 23:35 ` Darrick J. Wong
2017-01-30 23:44 ` Darrick J. Wong
2017-01-31 7:31 ` Christoph Hellwig
2017-01-31 7:41 ` Darrick J. Wong
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=20170128225517.GE316@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox