UBIFS-AUTH panic after reboot

[Richard Weinberger]

On Tue, Sep 15, 2020 at 4:51 PM Kristof Havasi <havasiefr at gmail.com> wrote:
> What I have tried:
> =================
> Based on the panic log [1], I can see that the panic happens here:
>     ubifs_lpt_calc_hash
>         `->ubifs_get_pnode
> inside the iteration over the LPT pnodes with hashing

Hmm.

> Questions:
> =========
> Q1: Are the chk_* knobs authentication aware? Or do they report so loudly
>     because I enabled the authentication and they cannot handle it yet?

They should. If not they need fixing. :-)

> Q2: Could I use `integr_chk` with authentication and so that the UBI volume is
>     my root filesystem?

What is "integr_chk"? Do you mean the integ test from mtd-utils?

> Q3: Could anyone help which tools I could use to narrow down the on the trigger?
>     E.g. Maybe with some formats combined with dynamic debugging [3]?

Let's try first with logs.

> Q4: If I stumbled upon a mainline bug, what could I do to help analysis and fix?

We will ask for what we need. No worries.
In most cases logs are fine. Sometimes a dump of a filesystem is helpful too.
Depends on the bug.

> Q5: Is there any UBIFS-Auth specific instrumentation for mkfs.ubifs apart from
>     passing in the secrets and hash-algo? IDK something like, the journal size
>     needs to be increased or other smaller detail?

Not really. It should as-is work. Otherwise mkfs.ubkfs needs fixing.

> UBIFS (ubi0:4): Mounting in authenticated mode
> UBIFS (ubi0:4): background thread "ubifs_bgt0_4" started, PID 632
> UBIFS error (ubi0:4 pid 1): ubifs_get_pnode.part.6: error -22 reading

So, it returns -EINVAL. Is this with chk_* enabled?

> pnode at 7:37186
> (pid 1) dumping pnode:
>         address c7138c80 parent c7138e80 cnext 0
>         flags 0 iip 3 level 0 num 0
>         0: free 0 dirty 255408 flags 1 lnum 0
>         1: free 0 dirty 190192 flags 1 lnum 0
>         2: free 0 dirty 255360 flags 1 lnum 0
>         3: free 0 dirty 248896 flags 1 lnum 0

Sascha, does this ring a bell?

-- 
Thanks,
//richard