From patchwork Thu Feb 2 18:38:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 9552997 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 00A9860424 for ; Thu, 2 Feb 2017 18:42:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E68CA2815E for ; Thu, 2 Feb 2017 18:42:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DAE8F28425; Thu, 2 Feb 2017 18:42:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 80F6E2815E for ; Thu, 2 Feb 2017 18:42:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752255AbdBBSmW (ORCPT ); Thu, 2 Feb 2017 13:42:22 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:49480 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751825AbdBBSkX (ORCPT ); Thu, 2 Feb 2017 13:40:23 -0500 Received: from localhost (unknown [78.192.101.3]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 49F93B8B; Thu, 2 Feb 2017 18:40:17 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , linux-xfs@vger.kernel.org, "Darrick J. Wong" , Eric Sandeen Subject: [PATCH 4.9 50/51] xfs: clear _XBF_PAGES from buffers when readahead page Date: Thu, 2 Feb 2017 19:38:09 +0100 Message-Id: <20170202183347.783000235@linuxfoundation.org> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170202183345.067336143@linuxfoundation.org> References: <20170202183345.067336143@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: "Darrick J. Wong" commit 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b upstream. 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 Reviewed-by: Eric Sandeen Signed-off-by: Greg Kroah-Hartman --- fs/xfs/xfs_buf.c | 1 + 1 file changed, 1 insertion(+) -- 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 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -423,6 +423,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; }