Received: by 10.223.176.5 with SMTP id f5csp1030123wra; Fri, 2 Feb 2018 10:00:21 -0800 (PST) X-Google-Smtp-Source: AH8x227Z8nJrpIZbBSCH1pyjwzVgLJH3mLi/bsna3+ytsn2BAeOqN+TAJE76v8CccMocHfdcJ1H1 X-Received: by 2002:a17:902:7486:: with SMTP id h6-v6mr5595348pll.236.1517594421162; Fri, 02 Feb 2018 10:00:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517594421; cv=none; d=google.com; s=arc-20160816; b=yOEt3BOX/uwl3QYsaVCr9YlvSxY9YIoSa5MB2E2/mgkZClgdONDPi+/G1ox1HYMrs3 Ui8/RlpTdRHEHtudeVra+uK0ZsQlBOnKsK+siQkqmxHXwnF2mOzrB+MLC0gBKP7lS6x7 T8xoRTFMYX9TzVw9M8aEDr1vhPYeb3RFaUmwJFmZwBJSNeJkckZOWPSzPNIG7iLWy3Gu TOeGk2KblOpXs85RSlzkwiDznKFUtPNepDlMQzHXN6ZCD/YE0qlVjo6s7reuBHP0pN+A 5xd/FzY/oARoNLArkne88gHJjZkNoDRAJGn7JGIxenpaUKC9stHSCt3ShN08wD+TWce/ h2Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=DLkjqxx7zFksDN+5PAndDuwGrfuMNQOgdnvRC/vHOBQ=; b=nndilUEo0V3vY8eDP8WCbXejwzEw2nDWYFHRmIUdH+K6bAc+htj/xQsNTgg/RxlFS4 tDjIIMaAeDEXlgR2GO3ARLJiSxmJbhh3uQkhbaC3FQjihFqg+f7AGtQo9J9TJz7ioF11 5+INRW8x6Ij+DBQavCdV5xQc1N96eRO4nqsx3SdplCc/JOyrGYCxXHUI8mXW9SSGRhz5 aHDnPJEIVL+GJHaELgrHRU8+WcDTlon8Ru4G0n8KBM8xgnBadvJphPotrk2L3wkXDCBq MSrnh9m3vDWLZLdqvOcp6EFLcgTVGh45SfoO8ki6vCJcvNkmj/Kz/6nGCJ7MVWUmT6Q9 g4Yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 67-v6si2160915ple.609.2018.02.02.10.00.06; Fri, 02 Feb 2018 10:00:21 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752808AbeBBR6k (ORCPT + 99 others); Fri, 2 Feb 2018 12:58:40 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:38362 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753054AbeBBRKh (ORCPT ); Fri, 2 Feb 2018 12:10:37 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 4C132F00; Fri, 2 Feb 2018 17:10:35 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Christoph Hellwig , Sasha Levin Subject: [PATCH 4.14 080/156] xfs: always free inline data before resetting inode fork during ifree Date: Fri, 2 Feb 2018 17:57:41 +0100 Message-Id: <20180202140843.894623238@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180202140840.242829545@linuxfoundation.org> References: <20180202140840.242829545@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: "Darrick J. Wong" [ Upstream commit 98c4f78dcdd8cec112d1cbc5e9a792ee6e5ab7a6 ] In xfs_ifree, we reset the data/attr forks to extents format without bothering to free any inline data buffer that might still be around after all the blocks have been truncated off the file. Prior to commit 43518812d2 ("xfs: remove support for inlining data/extents into the inode fork") nobody noticed because the leftover inline data after truncation was small enough to fit inside the inline buffer inside the fork itself. However, now that we've removed the inline buffer, we /always/ have to free the inline data buffer or else we leak them like crazy. This test was found by turning on kmemleak for generic/001 or generic/388. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/xfs/xfs_inode.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2422,6 +2422,24 @@ retry: } /* + * Free any local-format buffers sitting around before we reset to + * extents format. + */ +static inline void +xfs_ifree_local_data( + struct xfs_inode *ip, + int whichfork) +{ + struct xfs_ifork *ifp; + + if (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_LOCAL) + return; + + ifp = XFS_IFORK_PTR(ip, whichfork); + xfs_idata_realloc(ip, -ifp->if_bytes, whichfork); +} + +/* * This is called to return an inode to the inode free list. * The inode should already be truncated to 0 length and have * no pages associated with it. This routine also assumes that @@ -2458,6 +2476,9 @@ xfs_ifree( if (error) return error; + xfs_ifree_local_data(ip, XFS_DATA_FORK); + xfs_ifree_local_data(ip, XFS_ATTR_FORK); + VFS_I(ip)->i_mode = 0; /* mark incore inode as free */ ip->i_d.di_flags = 0; ip->i_d.di_dmevmask = 0;