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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Nov 2014 14:19:07 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	xfs@....sgi.com, linux-btrfs@...r.kernel.org
Subject: Re: [PATCH 3/4] vfs: don't let the dirty time inodes get more than a day stale

On Nov 21, 2014, at 1:59 PM, Theodore Ts'o <tytso@....edu> wrote:
> Guarantee that the on-disk timestamps will be no more than 24 hours
> stale.
> 
> Signed-off-by: Theodore Ts'o <tytso@....edu>
> ---
> fs/fs-writeback.c  | 1 +
> fs/inode.c         | 7 ++++++-
> include/linux/fs.h | 1 +
> 3 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index ce7de22..eb04277 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -1141,6 +1141,7 @@ void __mark_inode_dirty(struct inode *inode, int flags)
> 	if (flags & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
> 		trace_writeback_dirty_inode_start(inode, flags);
> 
> +		inode->i_ts_dirty_day = 0;
> 		if (sb->s_op->dirty_inode)
> 			sb->s_op->dirty_inode(inode, flags);
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 6e91aca..f0d6232 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1511,6 +1511,7 @@ static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
>  */
> static int update_time(struct inode *inode, struct timespec *time, int flags)
> {
> +	int days_since_boot = jiffies / (HZ * 86400);
> 	int ret;
> 
> 	if (inode->i_op->update_time) {
> @@ -1527,12 +1528,16 @@ static int update_time(struct inode *inode, struct timespec *time, int flags)
> 		if (flags & S_MTIME)
> 			inode->i_mtime = *time;
> 	}
> -	if (inode->i_sb->s_flags & MS_LAZYTIME) {
> +	if ((inode->i_sb->s_flags & MS_LAZYTIME) &&
> +	    (!inode->i_ts_dirty_day ||
> +	     inode->i_ts_dirty_day == days_since_boot)) {
> 		spin_lock(&inode->i_lock);
> 		inode->i_state |= I_DIRTY_TIME;
> 		spin_unlock(&inode->i_lock);
> +		inode->i_ts_dirty_day = days_since_boot;

It isn't clear if this is correct.  It looks like the condition will
only be entered if i_ts_dirty_day == days_since_boot, but that is only
set inside the condition?  Shouldn't this be:

	inode->i_ts_dirty_day = ~0U;

	if ((inode->i_sb->s_flags & MS_LAZYTIME) &&
	    inode->i_ts_dirty_day != days_since_boot)) {
		spin_lock(&inode->i_lock);
		inode->i_state |= I_DIRTY_TIME;
		spin_unlock(&inode->i_lock);
		inode->i_ts_dirty_day = days_since_boot;
	}

and "days_since_boot" should be declared unsigned short so it wraps
in the same way as i_ts_dirty_day, maybe using typeof(i_ts_dirty_day)
so that there isn't any need to update this in the future if the type
changes.  Conceivably this could be an unsigned char, if that packed
into struct inode better, at the risk of losing a timestamp update on
an inode in cache for 256+ days and only modifying it 256 days later.

Cheers, Andreas

> 		return 0;
> 	}
> +	inode->i_ts_dirty_day = 0;
> 	if (inode->i_op->write_time)
> 		return inode->i_op->write_time(inode);
> 	mark_inode_dirty_sync(inode);
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 489b2f2..e3574cd 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -575,6 +575,7 @@ struct inode {
> 	struct timespec		i_ctime;
> 	spinlock_t		i_lock;	/* i_blocks, i_bytes, maybe i_size */
> 	unsigned short          i_bytes;
> +	unsigned short		i_ts_dirty_day;
> 	unsigned int		i_blkbits;
> 	blkcnt_t		i_blocks;
> 
> -- 
> 2.1.0
> 
> --
> 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