From: Richard Weinberger <richard@nod.at> To: chengzhihao1 <chengzhihao1@huawei.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com>, Vignesh Raghavendra <vigneshr@ti.com>, mcoquelin stm32 <mcoquelin.stm32@gmail.com>, kirill shutemov <kirill.shutemov@linux.intel.com>, Sascha Hauer <s.hauer@pengutronix.de>, linux-mtd <linux-mtd@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 Date: Fri, 14 Jan 2022 19:45:39 +0100 (CET) [thread overview] Message-ID: <23886736.260777.1642185939371.JavaMail.zimbra@nod.at> (raw) In-Reply-To: <6815e4af-9b5b-313f-5828-644722dd4d1f@huawei.com> ----- Ursprüngliche Mail ----- > Von: "chengzhihao1" <chengzhihao1@huawei.com> > An: "richard" <richard@nod.at> > CC: "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "mcoquelin stm32" > <mcoquelin.stm32@gmail.com>, "kirill shutemov" <kirill.shutemov@linux.intel.com>, "Sascha Hauer" > <s.hauer@pengutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org> > Gesendet: Mittwoch, 12. Januar 2022 04:46:28 > Betreff: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 >>>> ubi_wl_init() is called in both cases, with and without fastmap. >>> I agree. >>> >>>> And ai->fastmap contains all anchor PEBs that scan_fast() found. >>>> This can be the most recent but also outdated anchor PEBs. >>> Is it exists a case that outdated fastmap PEBs are neither counted into >>> 'fmhdr->erase_peb_count' nor scanned into 'ai->fastmap' after attaching >>> by fastmap. >>> >> >> [...] >> >>> I think UBI attaches failed by fastmap if kernel goes here. >>> 1870 err = erase_aeb(ubi, aeb, sync); >> >> Hmm, I think the paranoia check in fastmap.c is too strict these days. >> if (WARN_ON(count_fastmap_pebs(ai) != ubi->peb_count - >> ai->bad_peb_count - fm->used_blocks)) >> goto fail_bad; >> >> It does not account ai->fastmap. So if ai->fastmap contains old anchor PEBs >> this check will trigger and force falling back to scanning mode. >> With this check fixed, ubi_wl_init() will erase all old PEBs from ai->fastmap. > Forgive my stubbornness, I think this strict check is good, could you > show me a process to trigger this WARN_ON, it would be nice to provide a > reproducer. You can trigger this by interrupting UBI. e.g. When UBI writes a new fastmap to the NAND, it schedules the old fastmap PEBs for erasure. PEB erasure is asynchronous in UBI. So this can be delayed for a very long time. While developing UBI fastmap and performing powercut tests I saw this often on targets. > I still insist the point(after my fix patch applied): All outdated > fastmap PEBs are added into 'ai->fastmap'(full scanning case) or counted > into 'fmhdr->erase_peb_count'(fast attached case). 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. To complicate things, this code is currently unreachable because the WARN_ON() is not right. I misses to count ai->fastmap. So, when there are old fastmap PEBs found, the counter does not match and UBI falls back to full scanning while it could to an attach by fastmap. Fastmap is full with corner cases that have been found by massive amount of testing, sadly. Thanks, //richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at> To: chengzhihao1 <chengzhihao1@huawei.com> Cc: Miquel Raynal <miquel.raynal@bootlin.com>, Vignesh Raghavendra <vigneshr@ti.com>, mcoquelin stm32 <mcoquelin.stm32@gmail.com>, kirill shutemov <kirill.shutemov@linux.intel.com>, Sascha Hauer <s.hauer@pengutronix.de>, linux-mtd <linux-mtd@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 Date: Fri, 14 Jan 2022 19:45:39 +0100 (CET) [thread overview] Message-ID: <23886736.260777.1642185939371.JavaMail.zimbra@nod.at> (raw) In-Reply-To: <6815e4af-9b5b-313f-5828-644722dd4d1f@huawei.com> ----- Ursprüngliche Mail ----- > Von: "chengzhihao1" <chengzhihao1@huawei.com> > An: "richard" <richard@nod.at> > CC: "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "mcoquelin stm32" > <mcoquelin.stm32@gmail.com>, "kirill shutemov" <kirill.shutemov@linux.intel.com>, "Sascha Hauer" > <s.hauer@pengutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org> > Gesendet: Mittwoch, 12. Januar 2022 04:46:28 > Betreff: Re: [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 >>>> ubi_wl_init() is called in both cases, with and without fastmap. >>> I agree. >>> >>>> And ai->fastmap contains all anchor PEBs that scan_fast() found. >>>> This can be the most recent but also outdated anchor PEBs. >>> Is it exists a case that outdated fastmap PEBs are neither counted into >>> 'fmhdr->erase_peb_count' nor scanned into 'ai->fastmap' after attaching >>> by fastmap. >>> >> >> [...] >> >>> I think UBI attaches failed by fastmap if kernel goes here. >>> 1870 err = erase_aeb(ubi, aeb, sync); >> >> Hmm, I think the paranoia check in fastmap.c is too strict these days. >> if (WARN_ON(count_fastmap_pebs(ai) != ubi->peb_count - >> ai->bad_peb_count - fm->used_blocks)) >> goto fail_bad; >> >> It does not account ai->fastmap. So if ai->fastmap contains old anchor PEBs >> this check will trigger and force falling back to scanning mode. >> With this check fixed, ubi_wl_init() will erase all old PEBs from ai->fastmap. > Forgive my stubbornness, I think this strict check is good, could you > show me a process to trigger this WARN_ON, it would be nice to provide a > reproducer. You can trigger this by interrupting UBI. e.g. When UBI writes a new fastmap to the NAND, it schedules the old fastmap PEBs for erasure. PEB erasure is asynchronous in UBI. So this can be delayed for a very long time. While developing UBI fastmap and performing powercut tests I saw this often on targets. > I still insist the point(after my fix patch applied): All outdated > fastmap PEBs are added into 'ai->fastmap'(full scanning case) or counted > into 'fmhdr->erase_peb_count'(fast attached case). 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. To complicate things, this code is currently unreachable because the WARN_ON() is not right. I misses to count ai->fastmap. So, when there are old fastmap PEBs found, the counter does not match and UBI falls back to full scanning while it could to an attach by fastmap. Fastmap is full with corner cases that have been found by massive amount of testing, sadly. Thanks, //richard ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-01-14 18:45 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-27 3:22 [PATCH v6 00/15] Some bugfixs for ubi/ubifs Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 01/15] ubifs: rename_whiteout: Fix double free for whiteout_ui->data Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 02/15] ubifs: Fix deadlock in concurrent rename whiteout and inode writeback Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 03/15] ubifs: Fix wrong number of inodes locked by ui_mutex in ubifs_inode comment Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 04/15] ubifs: Add missing iput if do_tmpfile() failed in rename whiteout Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 05/15] ubifs: Rename whiteout atomically Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2022-01-09 21:14 ` Richard Weinberger 2022-01-09 21:14 ` Richard Weinberger 2022-01-10 9:35 ` Zhihao Cheng 2022-01-10 9:35 ` Zhihao Cheng 2022-01-10 10:14 ` Richard Weinberger 2022-01-10 10:14 ` Richard Weinberger 2022-01-10 20:58 ` Richard Weinberger 2022-01-10 20:58 ` Richard Weinberger 2021-12-27 3:22 ` [PATCH v6 06/15] ubifs: Fix 'ui->dirty' race between do_tmpfile() and writeback work Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 07/15] ubifs: Rectify space amount budget for mkdir/tmpfile operations Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 08/15] ubifs: setflags: Make dirtied_ino_d 8 bytes aligned Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 09/15] ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock() Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 10/15] ubifs: Fix to add refcount once page is set private Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 11/15] ubi: fastmap: Return error code if memory allocation fails in add_aeb() Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 12/15] ubi: fastmap: Add all fastmap pebs into 'ai->fastmap' when fm->used_blocks>=2 Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2022-01-10 23:23 ` Richard Weinberger 2022-01-10 23:23 ` Richard Weinberger 2022-01-11 2:48 ` Zhihao Cheng 2022-01-11 2:48 ` Zhihao Cheng 2022-01-11 7:27 ` Richard Weinberger 2022-01-11 7:27 ` Richard Weinberger 2022-01-11 11:44 ` Zhihao Cheng 2022-01-11 11:44 ` Zhihao Cheng 2022-01-11 11:57 ` Richard Weinberger 2022-01-11 11:57 ` Richard Weinberger 2022-01-11 13:23 ` Zhihao Cheng 2022-01-11 13:23 ` Zhihao Cheng 2022-01-11 13:56 ` Richard Weinberger 2022-01-11 13:56 ` Richard Weinberger 2022-01-12 3:46 ` Zhihao Cheng 2022-01-12 3:46 ` Zhihao Cheng 2022-01-14 18:45 ` Richard Weinberger [this message] 2022-01-14 18:45 ` Richard Weinberger 2022-01-15 8:22 ` Zhihao Cheng 2022-01-15 8:22 ` Zhihao Cheng 2022-01-15 8:46 ` Zhihao Cheng 2022-01-15 8:46 ` Zhihao Cheng 2022-01-15 10:01 ` Richard Weinberger 2022-01-15 10:01 ` Richard Weinberger 2022-01-17 1:31 ` Zhihao Cheng 2022-01-17 1:31 ` Zhihao Cheng 2022-01-17 2:52 ` Zhihao Cheng 2022-01-17 2:52 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 13/15] ubifs: ubifs_writepage: Mark page dirty after writing inode failed Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 14/15] ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2021-12-27 3:22 ` [PATCH v6 15/15] ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty Zhihao Cheng 2021-12-27 3:22 ` Zhihao Cheng 2022-01-17 1:40 ` Zhihao Cheng 2022-01-17 1:40 ` Zhihao Cheng 2021-12-27 10:13 ` [PATCH v6 00/15] Some bugfixs for ubi/ubifs Richard Weinberger 2021-12-27 10:13 ` Richard Weinberger 2021-12-27 12:19 ` Zhihao Cheng 2021-12-27 12:19 ` Zhihao Cheng 2021-12-27 13:00 ` Richard Weinberger 2021-12-27 13:00 ` Richard Weinberger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=23886736.260777.1642185939371.JavaMail.zimbra@nod.at \ --to=richard@nod.at \ --cc=chengzhihao1@huawei.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=mcoquelin.stm32@gmail.com \ --cc=miquel.raynal@bootlin.com \ --cc=s.hauer@pengutronix.de \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.