Received: by 10.223.185.116 with SMTP id b49csp802069wrg; Sat, 10 Feb 2018 20:35:39 -0800 (PST) X-Google-Smtp-Source: AH8x2262L0eUot55atn1d8lWbNCZZX4jvVq8z3Tb8D+DwhCw4Q9G2lxjsU3tkT986v2XQ7507X9d X-Received: by 10.99.165.71 with SMTP id r7mr1900521pgu.60.1518323739029; Sat, 10 Feb 2018 20:35:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518323738; cv=none; d=google.com; s=arc-20160816; b=SY+YPw8iZ9X7RmJo2eIKs4+SfIR+bjU33qo53mJsviKaarGwVrG99UGtUxsmJAHXfC 6Py2U10X8OgbJhK2ilZjJ3SKd+1rtUPjE4PsTxlCjfM8ccy3BC9NIdTjlZi8+ACLv6Ny G95EEYGrO1bovq6hqFvdlmK/gAfJWD/OXR27DIUlMpOM+9DJWo5WssBnjp7rysLICdYG 3b/kZ14IZou0OUUx1a4E0thzhwQrq91s3PtUilAsCjfq0Q8UlISueyokz7oECkJHSRQf ABj4aNmimREhOp73zro101m9+jc94GGmaX2oFa2Y+OnRL5GMeJ24LiOJZpAYDArdA8if I5RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=o453g9QiRqobssoLmCJoBI+PYRITJCWBsUSbhBM+Yuw=; b=zPgNrIi375F3FsZT34sxuAc/nvlkMEVgUal/himZW68WtUummrWJb5b7MR2IPsOfkZ ZqeagITska9vo7O2RfXrtaNomHas6A64wPyrYblOkLlsCfmNidPIHRM90CItvMWqwVzf 7U3N7FOzJma/T6NTkpfCrl2AD1DgaJslNFogZCVRYQO/qPkS33W0miyKO+2IoCaQMnGN x5IyyuQ6GuVZ2ZmuN+9prwtaUV8zUAoEJMI7nGlSOLAcDb+3G+VtFsbbj728OdgIexO3 UNo6KADx5Ssu+fVOok8Gu9STmPNXfDUn8rp/IMP/GuYTUn9BFrjdzdOwI8l8Pex8jyqt MUzw== 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 p88si4314150pfd.243.2018.02.10.20.35.25; Sat, 10 Feb 2018 20:35:38 -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 S1752912AbeBKEeD (ORCPT + 99 others); Sat, 10 Feb 2018 23:34:03 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41555 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752708AbeBKEdo (ORCPT ); Sat, 10 Feb 2018 23:33:44 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ekjKe-0002hA-RV; Sun, 11 Feb 2018 04:33:40 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKY-0004UU-0i; Sun, 11 Feb 2018 04:33:34 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Joel Becker" , "Sunil Mushran" , "Jie Liu" , "Younger Liu" , "Jensen" , "Linus Torvalds" , "Mark Fasheh" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 38/79] ocfs2: fix issue that ocfs2_setattr() does not deal with new_i_size==i_size In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Younger Liu commit d62e74be1270c89fbaf7aada8218bfdf62d00a58 upstream. The issue scenario is as following: - Create a small file and fallocate a large disk space for a file with FALLOC_FL_KEEP_SIZE option. - ftruncate the file back to the original size again. but the disk free space is not changed back. This is a real bug that be fixed in this patch. In order to solve the issue above, we modified ocfs2_setattr(), if attr->ia_size != i_size_read(inode), It calls ocfs2_truncate_file(), and truncate disk space to attr->ia_size. Signed-off-by: Younger Liu Reviewed-by: Jie Liu Tested-by: Jie Liu Cc: Joel Becker Reviewed-by: Mark Fasheh Cc: Sunil Mushran Reviewed-by: Jensen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings --- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/file.c | 9 ++------- 2 files changed, 3 insertions(+), 8 deletions(-) --- a/fs/ocfs2/alloc.c +++ b/fs/ocfs2/alloc.c @@ -7127,7 +7127,7 @@ int ocfs2_truncate_inline(struct inode * if (end > i_size_read(inode)) end = i_size_read(inode); - BUG_ON(start >= end); + BUG_ON(start > end); if (!(OCFS2_I(inode)->ip_dyn_features & OCFS2_INLINE_DATA_FL) || !(le16_to_cpu(di->i_dyn_features) & OCFS2_INLINE_DATA_FL) || --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -474,11 +474,6 @@ static int ocfs2_truncate_file(struct in goto bail; } - /* lets handle the simple truncate cases before doing any more - * cluster locking. */ - if (new_i_size == le64_to_cpu(fe->i_size)) - goto bail; - down_write(&OCFS2_I(inode)->ip_alloc_sem); ocfs2_resv_discard(&osb->osb_la_resmap, @@ -1149,14 +1144,14 @@ int ocfs2_setattr(struct dentry *dentry, goto bail_unlock_rw; } - if (size_change && attr->ia_size != i_size_read(inode)) { + if (size_change) { status = inode_newsize_ok(inode, attr->ia_size); if (status) goto bail_unlock; inode_dio_wait(inode); - if (i_size_read(inode) > attr->ia_size) { + if (i_size_read(inode) >= attr->ia_size) { if (ocfs2_should_order_data(inode)) { status = ocfs2_begin_ordered_truncate(inode, attr->ia_size);