Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1582493pxb; Sat, 15 Jan 2022 17:03:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJzVkGGt00jbMFu2YQt7QIz1i4/ZSI7gpHbDxt8gqeWSJSmC35YhsyuM3AZLWAvkFYiQEbZ4 X-Received: by 2002:aa7:cdca:: with SMTP id h10mr14756661edw.279.1642295023132; Sat, 15 Jan 2022 17:03:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642295023; cv=none; d=google.com; s=arc-20160816; b=A/U+PowU55Jdlw2G+Gl1d2NA9rN+/o+vZrhcpl85O9z1BSQZQ4rfIYp7ff1cay3oA4 KvaFz2QqWWIC/MRlT/E4Btk3tb8jUpPXORdNR4pmiS6HhynprfhOj4Oa5r8tclrtrKBy f8xY08BWg+7+kGX/uEn0WelZghsD2a8NLqKOJGFmhSCOAOmvsuSioN54O0EYJWN843UP Et2cS7087A2byAilWuvkOF4Z67yi6H8iwcez3Go/THYza9xhRaMgcW/gtYH1aGt24s/x BbnWB8RfwiSgyiKWS+V0vhovjt7PAwBUgyHaAausyU2lfeFEC1+4bgNJDUGu0fqL1pq5 fROQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date; bh=qw3t9Cd5cDd/wwcg4jaYOpuf/emq5IE/SrshSM189BU=; b=ZWgcE/Wr3fZvDxwACbYWOniYkq2BVq5huXjZagDy0QxIq3pjjDLmwbg4oDKCJNJ6U3 JPsKYm8dozu8s9+0F5COBXU/gdv2FBCdxoXedZ1C0lQjahtAxEx62Bt6I+sxccSF9IP1 1Vi+XOrtqiOb1LjhZi3Aqc/uWV3TBzSAPgtV45QFyVtSGOb0eRiMUB+mAqJGRbFWWrWB gX7e/felzhVJiZiNhIgxc8vDD79/GX8wHYXub2LdLVftghxurz9qzxxY62Rf5s/vI8Qe q02c+510rwypokNEHcrtOCJmVDi2AtCWO9HxqjXvy1JsHkI5EUly8CqKJX6kx2gbpz8v +CoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v13si5438204edl.503.2022.01.15.17.02.55; Sat, 15 Jan 2022 17:03:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231547AbiAOKB4 convert rfc822-to-8bit (ORCPT + 99 others); Sat, 15 Jan 2022 05:01:56 -0500 Received: from lithops.sigma-star.at ([195.201.40.130]:34734 "EHLO lithops.sigma-star.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230099AbiAOKBz (ORCPT ); Sat, 15 Jan 2022 05:01:55 -0500 Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id B9B6D614E2CD; Sat, 15 Jan 2022 11:01:53 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id P38YeyIdWJ2O; Sat, 15 Jan 2022 11:01:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id 8C229614E2D5; Sat, 15 Jan 2022 11:01:52 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JOwiyE1gdgNZ; Sat, 15 Jan 2022 11:01:52 +0100 (CET) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id 62EB3614E2CD; Sat, 15 Jan 2022 11:01:52 +0100 (CET) Date: Sat, 15 Jan 2022 11:01:52 +0100 (CET) From: Richard Weinberger To: chengzhihao1 Cc: Miquel Raynal , Vignesh Raghavendra , mcoquelin stm32 , kirill shutemov , Sascha Hauer , linux-mtd , linux-kernel Message-ID: <626252388.262848.1642240912242.JavaMail.zimbra@nod.at> In-Reply-To: References: <20211227032246.2886878-1-chengzhihao1@huawei.com> <11976804.249069.1641902225370.JavaMail.zimbra@nod.at> <0a7a5cce-1ee1-70b6-d368-615dfa0a617a@huawei.com> <1492514284.249466.1641909382867.JavaMail.zimbra@nod.at> <6815e4af-9b5b-313f-5828-644722dd4d1f@huawei.com> <23886736.260777.1642185939371.JavaMail.zimbra@nod.at> <88df000c-97a6-ff3f-a1e2-10fa4da8c604@huawei.com> Subject: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [195.201.40.130] X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF96 (Linux)/8.8.12_GA_3809) Thread-Topic: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 Thread-Index: UBVQ5o9CerPStr2kIoVVEmrYehXG8Q== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Ursprüngliche Mail ----- > Von: "chengzhihao1" > An: "richard" > CC: "Miquel Raynal" , "Vignesh Raghavendra" , "mcoquelin stm32" > , "kirill shutemov" , "Sascha Hauer" > , "linux-mtd" , "linux-kernel" > Gesendet: Samstag, 15. Januar 2022 09:46:07 > Betreff: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 >>> Yes. But if you look into ubi_wl_init() you see that fastmap anchor PEBs >>> get erases synchronously(!). The comment before the erasure explains why. >> About erasing fastmap anchor PEB synchronously, I admit curreunt UBI >> implementation cannot satisfy it, even with my fix applied. Wait, it >> seems that UBI has never made it sure. Old fastmap PEBs could be erased >> asynchronously, they could be counted into 'fmh->erase_peb_count' even >> in early UBI implementation code, so old fastmap anchor PEB will be >> added into 'ai->erase' and be erased asynchronously in next attaching. > In next attaching old fastmap PEBs will be processed as following: > ubi_attach_fastmap -> add_aeb(ai, &ai->erase...) > ubi_wl_init > list_for_each_entry_safe(aeb, tmp, &ai->erase) > erase_aeb // erase asynchronously > ubi->lookuptbl[e->pnum] = e > list_for_each_entry(aeb, &ai->fastmap, u.list) > e = ubi_find_fm_block(ubi, aeb->pnum) > if (e) { > ... > } else { > if (ubi->lookuptbl[aeb->pnum]) // old fastmap PEBs are > assigned to 'ubi->lookuptbl' > continue; > } >> But, I feel it is not a problem, find_fm_anchor() can help us find out > > the right fastmap anchor PEB according seqnum. FYI, I think I understand now our disagreement. You assume that old Fastmap PEBs are *guaranteed* to be part of Fastmap's erase list. That's okay and this is what Linux as of today does. My point is that we need to be paranoid and check carefully for old Fastmap PEBs which might be *not* on the erase list. I saw such issues in the wild. These were causes by old and/or buggy Fastmap implementations. Keep in mind that Linux is not the only system that implements UBI (and fastmap). So let me give the whole situation another thought on how to improve it. I totally agree with you that currently there is a problem with fm->used_blocks > 1. I'm just careful (maybe too careful) about changing Fastmap code. Thanks, //richard