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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 Oct 2021 10:47:27 +0200 From: Jan Kara <jack@...e.cz> To: yebin <yebin10@...wei.com> Cc: Jan Kara <jack@...e.cz>, 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 Fri 08-10-21 10:38:31, yebin wrote: > On 2021/10/8 9:56, yebin wrote: > > 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. > > > Yeah, i did test as following steps > hostA hostB > mount > ext4_multi_mount_protect -> seq == EXT4_MMP_SEQ_CLEAN > delay 5s after label "skip" so hostB will see seq is > EXT4_MMP_SEQ_CLEAN > mount > ext4_multi_mount_protect -> seq == EXT4_MMP_SEQ_CLEAN > run kmmpd > run kmmpd > > Actually,in this situation kmmpd will not detect confliction. > In ext4_multi_mount_protect function we write mmp data first and wait > 'wait_time * HZ' seconds, > read mmp data do check. Most of the time, If 'wait_time' is zero, it can pass > check. But how can be wait_time zero? As far as I'm reading the code, wait_time must be at least EXT4_MMP_MIN_CHECK_INTERVAL... Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists