linux-kernel - Re: [PATCH -next v2 2/6] ext4: introduce last_check

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, 8 Oct 2021 09:56:43 +0800
From:   yebin <yebin10@...wei.com>
To:     Jan Kara <jack@...e.cz>
CC:     <tytso@....edu>, <adilger.kernel@...ger.ca>,
        <linux-ext4@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next v2 2/6] ext4: introduce last_check_time record
 previous check time



On 2021/10/7 20:31, Jan Kara wrote:
> On Sat 11-09-21 17:00:55, Ye Bin wrote:
>> kmmpd:
>> ...
>>      diff = jiffies - last_update_time;
>>      if (diff > mmp_check_interval * HZ) {
>> ...
>> As "mmp_check_interval = 2 * mmp_update_interval", 'diff' always little
>> than 'mmp_update_interval', so there will never trigger detection.
>> Introduce last_check_time record previous check time.
>>
>> Signed-off-by: Ye Bin <yebin10@...wei.com>
> I think the check is there only for the case where write_mmp_block() +
> sleep took longer than mmp_check_interval. I agree that should rarely
> happen but on a really busy system it is possible and in that case we would
> miss updating mmp block for too long and so another node could have started
> using the filesystem. I actually don't see a reason why kmmpd should be
> checking the block each mmp_check_interval as you do - mmp_check_interval
> is just for ext4_multi_mount_protect() to know how long it should wait
> before considering mmp block stale... Am I missing something?
>
> 								Honza
I'm sorry, I didn't understand the detection mechanism here before. Now 
I understand
the detection mechanism here.
As you said, it's just an abnormal protection. There's really no problem.

>> ---
>>   fs/ext4/mmp.c | 14 +++++++++-----
>>   1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c
>> index 12af6dc8457b..c781b09a78c9 100644
>> --- a/fs/ext4/mmp.c
>> +++ b/fs/ext4/mmp.c
>> @@ -152,6 +152,7 @@ static int kmmpd(void *data)
>>   	int mmp_update_interval = le16_to_cpu(es->s_mmp_update_interval);
>>   	unsigned mmp_check_interval;
>>   	unsigned long last_update_time;
>> +	unsigned long last_check_time;
>>   	unsigned long diff;
>>   	int retval = 0;
>>   
>> @@ -170,6 +171,7 @@ static int kmmpd(void *data)
>>   
>>   	memcpy(mmp->mmp_nodename, init_utsname()->nodename,
>>   	       sizeof(mmp->mmp_nodename));
>> +	last_check_time = jiffies;
>>   
>>   	while (!kthread_should_stop() && !sb_rdonly(sb)) {
>>   		if (!ext4_has_feature_mmp(sb)) {
>> @@ -198,17 +200,18 @@ static int kmmpd(void *data)
>>   		}
>>   
>>   		diff = jiffies - last_update_time;
>> -		if (diff < mmp_update_interval * HZ)
>> +		if (diff < mmp_update_interval * HZ) {
>>   			schedule_timeout_interruptible(mmp_update_interval *
>>   						       HZ - diff);
>> +			diff = jiffies - last_update_time;
>> +		}
>>   
>>   		/*
>>   		 * We need to make sure that more than mmp_check_interval
>> -		 * seconds have not passed since writing. If that has happened
>> -		 * we need to check if the MMP block is as we left it.
>> +		 * seconds have not passed since check. If that has happened
>> +		 * we need to check if the MMP block is as we write it.
>>   		 */
>> -		diff = jiffies - last_update_time;
>> -		if (diff > mmp_check_interval * HZ) {
>> +		if (jiffies - last_check_time > mmp_check_interval * HZ) {
>>   			struct buffer_head *bh_check = NULL;
>>   			struct mmp_struct *mmp_check;
>>   
>> @@ -234,6 +237,7 @@ static int kmmpd(void *data)
>>   				goto wait_to_exit;
>>   			}
>>   			put_bh(bh_check);
>> +			last_check_time = jiffies;
>>   		}
>>   
>>   		 /*
>> -- 
>> 2.31.1
>>