All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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: link
Be 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.