linux-kernel - [PATCH 3.11 092/131] fs: fix iversion handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1394029455-23128-93-git-send-email-luis.henriques@canonical.com>
Date:	Wed,  5 Mar 2014 14:23:36 +0000
From:	Luis Henriques <luis.henriques@...onical.com>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com
Cc:	Christoph Hellwig <hch@....de>, Chris Mason <clm@...com>,
	Ben Myers <bpm@....com>,
	Luis Henriques <luis.henriques@...onical.com>
Subject: [PATCH 3.11 092/131] fs: fix iversion handling

3.11.10.6 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Christoph Hellwig <hch@...radead.org>

commit dff6efc326a4d5f305797d4a6bba14f374fdd633 upstream.

Currently notify_change directly updates i_version for size updates,
which not only is counter to how all other fields are updated through
struct iattr, but also breaks XFS, which need inode updates to happen
under its own lock, and synchronized to the structure that gets written
to the log.

Remove the update in the common code, and it to btrfs and ext4,
XFS already does a proper updaste internally and currently gets a
double update with the existing code.

IMHO this is 3.13 and -stable material and should go in through the XFS
tree.

Signed-off-by: Christoph Hellwig <hch@....de>
Reviewed-by: Andreas Dilger <adilger@...ger.ca>
Acked-by: Jan Kara <jack@...e.cz>
Reviewed-by: Dave Chinner <dchinner@...hat.com>
Signed-off-by: Chris Mason <clm@...com>
Signed-off-by: Ben Myers <bpm@....com>
Signed-off-by: Luis Henriques <luis.henriques@...onical.com>
---
 fs/attr.c        | 5 -----
 fs/btrfs/inode.c | 8 ++++++--
 fs/ext4/inode.c  | 4 ++++
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/fs/attr.c b/fs/attr.c
index 1449adb..8dd5825 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -182,11 +182,6 @@ int notify_change(struct dentry * dentry, struct iattr * attr)
 			return -EPERM;
 	}
 
-	if ((ia_valid & ATTR_SIZE) && IS_I_VERSION(inode)) {
-		if (attr->ia_size != inode->i_size)
-			inode_inc_iversion(inode);
-	}
-
 	if ((ia_valid & ATTR_MODE)) {
 		umode_t amode = attr->ia_mode;
 		/* Flag setting protected by i_mutex */
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index f992daf..bfe5f39 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4413,8 +4413,12 @@ static int btrfs_setsize(struct inode *inode, struct iattr *attr)
 	 * these flags set.  For all other operations the VFS set these flags
 	 * explicitly if it wants a timestamp update.
 	 */
-	if (newsize != oldsize && (!(mask & (ATTR_CTIME | ATTR_MTIME))))
-		inode->i_ctime = inode->i_mtime = current_fs_time(inode->i_sb);
+	if (newsize != oldsize) {
+		inode_inc_iversion(inode);
+		if (!(mask & (ATTR_CTIME | ATTR_MTIME)))
+			inode->i_ctime = inode->i_mtime =
+				current_fs_time(inode->i_sb);
+	}
 
 	if (newsize > oldsize) {
 		truncate_pagecache(inode, oldsize, newsize);
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index d343bb7..0ea5961 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4598,6 +4598,10 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr)
 			if (attr->ia_size > sbi->s_bitmap_maxbytes)
 				return -EFBIG;
 		}
+
+		if (IS_I_VERSION(inode) && attr->ia_size != inode->i_size)
+			inode_inc_iversion(inode);
+
 		if (S_ISREG(inode->i_mode) &&
 		    (attr->ia_size < inode->i_size)) {
 			if (ext4_should_order_data(inode)) {
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/