Received: by 10.223.176.5 with SMTP id f5csp1135036wra; Fri, 2 Feb 2018 11:49:08 -0800 (PST) X-Google-Smtp-Source: AH8x227iA8KSsFwXZ5NTA4Dx5wwBBKQQ5JKh8Sy+uk60kd5iLHkoIvIO3IAGWZfgI493muqyUK74 X-Received: by 10.101.64.193 with SMTP id u1mr32125627pgp.44.1517600948617; Fri, 02 Feb 2018 11:49:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517600948; cv=none; d=google.com; s=arc-20160816; b=PT++7fnfq3AWxW50C1sQ/bbBekAIN4yViUwhNeQkiiYG6WkXyihJGOORGm1SZq2Ngr qoFtYkfcdvRX9UGxVXktPyjJdJUhf6dMlJIkI5EecAjmbifL9sVIBgDl77ZfY7/AqBXY tGdg7QwERymS0PIHQRW2NpfrKnefuD/LxPW0yP/MhFtsuZ3gntnwMtThxNM7g1ckJiGm FvRvFP4AUGFkSvl/rZdpZ6kT9G+nxlFU9cYMQIbMXUyh2VRP0fZw/Qq8ebYl25zZWYo7 9xSwNMLcE48TSqw0sGMZN1wsGXX9nZ0ggfikapTGmRPl3RMrFIaWAbflKYGhfUP11USK f1CA== 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=cQHXWN9cb+DTpkmMvWEJZ9ANrZmKniW68+ZcENKXJXU=; b=ZD0s9KJhXOA8cym/CP3vq79tDsptILPgnkDZA0v1MBqLendIEOG8liTcQeDxdpyuD3 siaA4yA3f6UE0Pxxl4ySAk6UppIIEPHclbhTMVlpNrDmYiALPtUGlG303fMnZmMpoyUa kakgp8tpD5KdbJpVhFuaMi3wWHuSOj2D+TJxXSwI5RfVBkqq22uIOyx133FsGuhZXG94 QbCGBiE6Sky1HPv+IgTPeglPdHxRiS2N8rBpoh29Unx13B20wbKoaQ08P0WxSXEX7cnH RjbaWKg/JO59QCgOcEy2bWpaKpMqhHAvSotY5ZxBSBEFWgCVWQYEiz9f+kvaSv5GIlxb kvvw== 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 a59-v6si393385pla.366.2018.02.02.11.48.54; Fri, 02 Feb 2018 11:49:08 -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 S1754406AbeBBSSq (ORCPT + 99 others); Fri, 2 Feb 2018 13:18:46 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:36178 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752316AbeBBREV (ORCPT ); Fri, 2 Feb 2018 12:04:21 -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 2867EBCF; Fri, 2 Feb 2018 17:04:20 +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.9 38/86] xfs: always free inline data before resetting inode fork during ifree Date: Fri, 2 Feb 2018 17:57:58 +0100 Message-Id: <20180202140825.972875915@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180202140822.679101338@linuxfoundation.org> References: <20180202140822.679101338@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.9-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 @@ -2430,6 +2430,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 @@ -2466,6 +2484,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;