Re: ubifs: read bad node type in ubifs_tnc_read_wbuf

From: Richard Weinberger <richard@nod.at>
To: 李傲傲 <Carson.Li1@unisoc.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: ubifs: read bad node type in ubifs_tnc_read_wbuf
Date: Wed, 15 Jan 2020 00:16:18 +0100 (CET)	[thread overview]
Message-ID: <1741454272.21050.1579043778589.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <51cabef7ce104de097c2556a4a24d8a7@shmbx04.spreadtrum.com>

----- Ursprüngliche Mail -----
> I am not sure if i have made it clear, maybe following logic can make it
> clearer:
> 
> A  |          B
> --------------------------------------------------------------------------------------------
> ubifs_tnc_locate
>   zbr->lnum = 54 (find in TNC)
>     ubifs_get_wbuf(zbr->lnum = 54) is ture
>          ubifs_tnc_read_node
>                         ->GC(change zt->lnum to 224(GCHD) in _TNC_)
>                         ->zbr->lnum = 54 becomes DATAHD
> ubifs_get_wbuf(zbr->lnum = 54 as the DATAHD) is ture again
>     ubifs_read_node_wbuf
> -------------------------------------------------------------------------------------------
> Data lays in LEB54 have been moved to LEB224, so error happens. if a journal
> head is
> garbage collected, if that means there is a commit has finished? I guess this
> situation
> happens when making reservation, runs commit first and then does garbage
> collect.

Well, a journal head should never get garbage collected at first place.
If I understand your analysis correctly it looks like this rule was broken.
So we need to understand how this could happen.
LPROPS_TAKEN should avoid this.

If possible, can you please check the lprobs of the affected LEBs?

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/