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-next>] [day] [month] [year] [list]
Message-Id: <8E57B1B6-E650-4A1A-AF78-0A9C9593A3E3@dilger.ca>
Date:	Mon, 2 Dec 2013 15:05:07 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>, xfs@....sgi.com,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] fs: fix iversion handling

On Dec 2, 2013, at 10:36 AM, Christoph Hellwig <hch@...radead.org> wrote:
> ping?

Added linux-ext4 to the CC list.

I'm happy to see this cleanup.  You can add my

  Reviewed-by: Andreas Dilger <adilger@...ger.ca>

for the ext4 part, one question inline for the btrfs change (someone with more
btrfs knowledge needs to comment if that is important or not.

Cheers, Andreas

> On Tue, Nov 19, 2013 at 07:17:07AM -0800, Christoph Hellwig wrote:
>> 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>
>> 
>> Index: xfs/fs/attr.c
>> ===================================================================
>> --- xfs.orig/fs/attr.c	2013-11-19 16:08:42.275415189 +0100
>> +++ xfs/fs/attr.c	2013-11-19 16:08:51.803414994 +0100
>> @@ -182,11 +182,6 @@ int notify_change(struct dentry * dentry
>> 			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 */
>> Index: xfs/fs/btrfs/inode.c
>> ===================================================================
>> --- xfs.orig/fs/btrfs/inode.c	2013-11-19 16:08:42.275415189 +0100
>> +++ xfs/fs/btrfs/inode.c	2013-11-19 16:08:51.803414994 +0100
>> @@ -4345,8 +4345,12 @@ static int btrfs_setsize(struct inode *i
>> 	 * 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);

Should this be conditional on IS_I_VERSION(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, newsize);
>> Index: xfs/fs/ext4/inode.c
>> ===================================================================
>> --- xfs.orig/fs/ext4/inode.c	2013-11-19 16:08:42.275415189 +0100
>> +++ xfs/fs/ext4/inode.c	2013-11-19 16:08:51.803414994 +0100
>> @@ -4594,6 +4594,10 @@ int ext4_setattr(struct dentry *dentry,
>> 			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)) {
>> 
>> _______________________________________________
>> xfs mailing list
>> xfs@....sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
> ---end quoted text---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ