Re: UBIFS-AUTH panic after reboot

[Kristof Havasi <havasiefr@gmail.com>]

> I think I've found the problem. Can you please test the following change?

I tested quickly with a subset of the previous tests, and until now I
have not seen any panics!
I will keep on running some other tests, including our business logic,
and will report back to
you whether we see any unexpected hic-ups.

Thank you a lot and best regards,
Kristof

On Sun, 27 Sep 2020 at 21:27, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>
> On Mon, Sep 21, 2020 at 12:46 PM Kristof Havasi <havasiefr@gmail.com> wrote:
> >
> > On Mon, 21 Sep 2020 at 11:51, Richard Weinberger <richard@nod.at> wrote:
> > >
> > > ----- Ursprüngliche Mail -----
> > > >> > Does the problem also trigger with encryption disabled? So just with
> > > >> > authentication?
> > > > I couldn't trigger the same error with encryption disabled and authentication
> > > > enabled. Even if I enabled all the chk_* knobs under kernel/debug/ubifs/, no
> > > > failed assertion or error/warning log could be observed.
> > >
> > > So, with either encryption or authentication enabled everything is fine
> > > but when both are enabled you hit the problem?
> > > Interesting.
> >
> > That is exactly what I can observe.
> >
> > >
> > > >> Does it print big LPT or small LPT model?
> > > >
> > > > small LPT model.
> > >
> > > I'll try to reproduce now on a similar sized NAND. :-)
> >
> > I mentioned that I use the buildroot's mkfs.ubifs with customization,
> > but here are the parameters:
> > (Configured via Kconfig)
> >
> > --max-leb-cnt=3968
> > --min-io-size=0x1000
> > --leb-size=0x3E000
> > --key /path/to/key
> > --key-descriptor dead12345678beef
> > --cipher AES-256-XTS
> > --hash-algo sha256
> > --auth-key="pkcs11:token=..."
> >
> > The flash is a Micron MT29F8G08ABACAWP-IT:C which has 224 bytes OOB,
> > which is not
> > included in the --min-io-size. That is ok, isn't?
>
> Yes. Both UBI and UBIFS don't use OOB.
>
> I think I've found the problem. Can you please test the following change?
>
> diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
> index 4a5b06f8d812..869ef6efa48f 100644
> --- a/fs/ubifs/journal.c
> +++ b/fs/ubifs/journal.c
> @@ -936,8 +936,6 @@ int ubifs_jnl_write_inode(struct ubifs_info *c,
> const struct inode *inode)
>                                           inode->i_ino);
>         release_head(c, BASEHD);
>
> -       ubifs_add_auth_dirt(c, lnum);
> -
>         if (last_reference) {
>                 err = ubifs_tnc_remove_ino(c, inode->i_ino);
>                 if (err)
> @@ -947,6 +945,8 @@ int ubifs_jnl_write_inode(struct ubifs_info *c,
> const struct inode *inode)
>         } else {
>                 union ubifs_key key;
>
> +               ubifs_add_auth_dirt(c, lnum);
> +
>                 ino_key_init(c, &key, inode->i_ino);
>                 err = ubifs_tnc_add(c, &key, lnum, offs, ilen, hash);
>         }
>
> A few lines before in the we last_reference call ubifs_add_dirt(c,
> lnum, write_len) and write_len contains
> already the auth node size. So the auth node size is accounted twice.
> Please let me know whether it helps, I think ubifs_jnl_write_inode()
> needs more cleanup.
>
> --
> Thanks,
> //richard

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