linux-kernel - Re: [PATCH] Update atime from future.

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: <4D21FCEB.80502@gmail.com>
Date:	Tue, 04 Jan 2011 00:44:27 +0800
From:	YangSheng <sickamd@...il.com>
To:	Steven Whitehouse <swhiteho@...hat.com>
CC:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] Update atime from future.

On 01/03/2011 06:27 PM, Steven Whitehouse wrote:
> Hi,
>
> On Wed, 2010-12-29 at 21:58 +0800, yangsheng wrote:
>    
>> Signed-off-by: sickamd@...il.com
>> ---
>>   fs/inode.c |    8 +++++++-
>>   1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/inode.c b/fs/inode.c
>> index da85e56..6c8effd 100644
>> --- a/fs/inode.c
>> +++ b/fs/inode.c
>> @@ -1469,7 +1469,13 @@ static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
>>   		return 1;
>>
>>   	/*
>> -	 * Is the previous atime value older than a day? If yes,
>> +	 * Is the previous atime value in future? If yes,
>> +	 * update atime:
>> +	 */
>> +	if ((long)(now.tv_sec - inode->i_atime.tv_sec)<  0)
>> +		return 1;
>> +	/*
>> +	 * Is the previous atime value old than a day? If yes,
>>   	 * update atime:
>>   	 */
>>   	if ((long)(now.tv_sec - inode->i_atime.tv_sec)>= 24*60*60)
>>      
> I don't think this is a good plan for cluster filesystems, since if the
> times on the nodes are not exactly synchronised (we do highly recommend
> people run ntp or similar) then this might lead to excessive atime
> updating. The current behaviour is to ignore atimes which are in the
> future for exactly this reason,
>    
I agreed in theory.  Anyway, a two-way update may cause shake in some 
case. Like a cluster environment with time gap between cluster members. 
But future atime also is a trouble things i think. Of course, I hope a 
clever patch to fix them all.

Thanks
yangsheng
--
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/