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@xxxxxxxxxx> > > 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. --D > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
