Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp5909432pxb; Sun, 7 Nov 2021 23:28:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJzqZCM/WfYGTliyM+NjQu+eKb0tkRcFeC4MWPWEys0Ck3tqr1g1QoCQtA8b92uNoyV/Eg6H X-Received: by 2002:aa7:d648:: with SMTP id v8mr74148585edr.358.1636356480538; Sun, 07 Nov 2021 23:28:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636356480; cv=none; d=google.com; s=arc-20160816; b=z5FAErwOZZupUZ6Fo9Xg6nyRaOqhM6PkiU0WATOE8f9KC3YBR/w0QjqM68bdsVBDI8 3TyCLTshuBnR4vG5pgRbPKxOUo3kHeBij7XpKE1cbzSPqzyWIbViNI6VKyi+wSpZAr52 DjiXykszSu19dAmL1GDNl8R0jRc/fWpZkUmPf8d04zzEuh3NR8F0j5zxBGfTpde08tok ttIFsGr2Cj9JK9x13Mj7D6gTj+zoj0Hn2g1h2XfB4bWQQ1gPRCFSRqBwhKI5g6Vy9RSN eF+g9FESxgSDfELn+LiqhZoAnPzUCJQtFEl3k2etEm3BxzwaGGNy+b3AX2/obJbanlcD u4/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=9VH8nKTtL6CVX4dVNgRD7+DIl7GjXmqp4sSAPW/kXLM=; b=0lc8cXv4l58C90PhNI+PAcGn0PqGihrlEI5ck0INL12pWShn6DqU1PSLLxFZf86H53 713kdlHVeQ0+RaU6jVw7+sOcEfbSyv7X/7ZzyFEC4uUHRFAfa/V92ZSd3aLXMKT3SRqF /dG0LDBaWQ+3fVYjj7iwsoxLdV8dbHwdf/AYxmAvtyd1hYgpjtuYCmiaP0z7bqjCTvmd qrJDSy0FVcoDfU1lVeePgGb7K53NmQf6PT1UVaCLRnlLBKrW+WVuVOGoDH3MYwhW8iiV HZfh3L+5PqHA795+sI7gSg7g3tGFNt6Xlctyh7gwxP7frpXED8DwbmJP7sTIxfyCa1bf P/bA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gt40si23868862ejc.310.2021.11.07.23.27.30; Sun, 07 Nov 2021 23:28:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236174AbhKHCNx (ORCPT + 99 others); Sun, 7 Nov 2021 21:13:53 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:27184 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232513AbhKHCNx (ORCPT ); Sun, 7 Nov 2021 21:13:53 -0500 Received: from dggeme754-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HnZLN02B9z8v0p; Mon, 8 Nov 2021 10:09:32 +0800 (CST) Received: from [10.174.178.185] (10.174.178.185) by dggeme754-chm.china.huawei.com (10.3.19.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Mon, 8 Nov 2021 10:11:05 +0800 Subject: Re: [PATCH -next v5 0/3] Fix some issues about mmp To: , , References: <20211020031802.2312022-1-yebin10@huawei.com> CC: , From: yebin Message-ID: <61888739.2040801@huawei.com> Date: Mon, 8 Nov 2021 10:11:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20211020031802.2312022-1-yebin10@huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.185] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggeme754-chm.china.huawei.com (10.3.19.100) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 2021/10/20 11:17, Ye Bin wrote: > I test mmp function as follow steps: > 1. Inject delay 5s in ext4_multi_mount_protect function after > "skip:" label. > 2. Share HostA block device(sda) with HostB(nbd0) by NBD. > 3. Enable mmp feature when mkfs.ext4 sda. > 4. Mount sda and nbd0 at the same time. > > I found kmmpd never trigger detect multi-mount. Reason is as follow: > 1. Kmmpd init seq with 0, if two host have same nodename, will lead to > detect confliction very slow, even never detect confliction. > 2. When detect confliction in kmmpd, we get 'check_bh' is same with 'bh'. > so we compare data with itself. > 3. We only trigger detect when ”diff > mmp_check_interval * HZ“, > 'mmp_check_interval' is double of 'mmp_update_interval', 'diff' is > about 'mmp_update_interval'. So 'diff' is little than 'mmp_check_interval * HZ' > normaly. As Jan Kara explain as follows: > "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. " > > v1->v2: > Fix 'last_check_time' not initialized before checking. > > v2->v3: > 1. drop commit "ext4: introduce last_check_time record previous check time" > As Ted explain as follows: > "I'd like Andreas to comment here. My understanding is that MMP > originally intended as a safety mechanism which would be used as part > of a primary/backup high availability system, but not as the *primary* > system where you might try to have two servers simultaneously try to > mount the file system and use MMP as the "election" mechanism to > decide which server is going to be the primary system, and which would > be the backup system. > > The cost of being able to handle this particular race is it would slow > down the mounts of cleanly unmounted systems. > > There *are* better systems to implement leader elections[1] than using > MMP. Most of these more efficient leader elections assume that you > have a working IP network, and so if you have a separate storage > network (including a shared SCSI bus) from your standard IP network, > then MMP is a useful failsafe in the face of a network partition of > your IP network. The question is whether MMP should be useful for > more than that. And if it isn't, then we should probably document > what MMP is and isn't good for, and give advice in the form of an > application note for how MMP should be used in the context of a larger > system." > 2. drop commit "ext4: fix possible store wrong check interval value in disk when umount" > 3. simplify read_mmp_block fucntion to avoid UAF > > v3->v4: > 1. drop commit "ext4: init 'seq' with the value which set in 'ext4_multi_mount_protect'" > 2. merge "ext4: get buffer head before read_mmp_block" to > "ext4: simplify read_mmp_block fucntion" > 3. rename "ext4: avoid to re-read mmp check data get from page cache" to > "ext4: remove useless bh_check variable" > 4. reorder "ext4: remove useless bh_check variable" and > "ext4: simplify read_mmp_block fucntion" > > v4->v5: > 1. Fix follow warning: >>> fs/ext4/mmp.c:124:15: warning: variable 'mmp_block' set but not used [-Wunused-but-set-variable] > ext4_fsblk_t mmp_block; > 2. Fix incorrect judgement in 'ext4_multi_mount_protect'. > > Ye Bin (3): > ext4: compare to local seq and nodename when check conflict > ext4: remove useless bh_check variable > ext4: simplify read_mmp_block fucntion > > fs/ext4/ext4.h | 5 +++- > fs/ext4/mmp.c | 66 +++++++++++++++++++++----------------------------- > 2 files changed, 31 insertions(+), 40 deletions(-) > ping...