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

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> 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.

Makes sense.