Re: [PATCH v3 2/3] module: add Error arguments to module_load_one and module_load_qom_one

[Kevin Wolf]

Am 21.09.2022 um 14:08 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Am 21.09.2022 um 06:45 hat Markus Armbruster geschrieben:
> >> Can we detect presence of compressed blocks on open?
> >
> > We seem to read in the full metadata of the image in dmg_open(). So I
> > think it would be possible to detect it there.
> >
> > dmg_read_mish_block() is what fills in s->types. However, it never fills
> > in types that it doesn't know (and it pretends it doesn't know the types
> > of compressed blocks whose module is not loaded). So instead of checking
> > it in dmg_open() after dmg_read_mish_block() has completed, you would
> > have to catch the situation already in dmg_read_mish_block() while
> > parsing the image file, which should be entirely doable if you want.
> 
> In most cases, "open fails because some blocks are known to be
> unreadable" is much better UX than "everything goes swimmingly until you
> try to read one of the known-unreadable blocks".
> 
> Even when your software manages not to eat your data, surprise bad
> blocks are still likely to result in a bad day.

That's fair. On the other hand, not allowing the user to read the part
of data that is perfectly readable would be bad, too.

Maybe the right solution would be to have a driver option like
"unknown-block-types=io-error|fail-open" (probably with better names),
and then having "fail-open" as the new default would be reasonable
enough.

Kevin