public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dave Chinner <david@fromorbit.com>,
	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: Mon, 30 Jan 2017 15:44:15 -0800	[thread overview]
Message-ID: <20170130234415.GC9134@birch.djwong.org> (raw)
In-Reply-To: <20170130233557.GA6442@birch.djwong.org>

[add hch to the thread]

On Mon, Jan 30, 2017 at 03:35:57PM -0800, Darrick J. Wong wrote:
> On Sun, Jan 29, 2017 at 09:55:17AM +1100, Dave Chinner wrote:
> > 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....
> 
> Uh... this patch was already in Linus' tree by the time I received this reply,
> so I don't think I can change it.
> 
> > And I think it also needs a stable cc....
> 
> Will send it to the stable list.

Actually -- Christoph, are you planning to send another batch of XFS
fixes for 4.9?

--D

> 
> --D
> 
> > 
> > Cheers,
> > 
> > Dave.
> > -- 
> > Dave Chinner
> > david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-01-30 23:45 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
2017-01-30 23:35   ` Darrick J. Wong
2017-01-30 23:44     ` Darrick J. Wong [this message]
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=20170130234415.GC9134@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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