All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "Claudio Fontana" <cfontana@suse.de>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, dinechin@redhat.com,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH v3 2/3] module: add Error arguments to module_load_one and module_load_qom_one
Date: Wed, 21 Sep 2022 14:08:38 +0200	[thread overview]
Message-ID: <874jx1dj5l.fsf@pond.sub.org> (raw)
In-Reply-To: <Yyr47JwudwU7JYQq@redhat.com> (Kevin Wolf's message of "Wed, 21 Sep 2022 13:43:40 +0200")

Kevin Wolf <kwolf@redhat.com> writes:

> Am 21.09.2022 um 06:45 hat Markus Armbruster geschrieben:
>> Kevin Wolf <kwolf@redhat.com> writes:
>> 
>> > Am 08.09.2022 um 19:36 hat Claudio Fontana geschrieben:
>> >> On 9/8/22 19:10, Claudio Fontana wrote:
>> >> > On 9/8/22 18:03, Richard Henderson wrote:
>> >> >> On 9/8/22 15:53, Claudio Fontana wrote:
>> >> >>> @@ -446,8 +447,13 @@ static int dmg_open(BlockDriverState *bs, QDict *options, int flags,
>> >> >>>           return -EINVAL;
>> >> >>>       }
>> >> >>>   
>> >> >>> -    block_module_load_one("dmg-bz2");
>> >> >>> -    block_module_load_one("dmg-lzfse");
>> >> >>> +    if (!block_module_load_one("dmg-bz2", &local_err) && local_err) {
>> >> >>> +        error_report_err(local_err);
>> >> >>> +    }
>> >> >>> +    local_err = NULL;
>> >> >>> +    if (!block_module_load_one("dmg-lzfse", &local_err) && local_err) {
>> >> >>> +        error_report_err(local_err);
>> >> >>> +    }
>> >> >>>   
>> >> >>>       s->n_chunks = 0;
>> >> >>>       s->offsets = s->lengths = s->sectors = s->sectorcounts = NULL;
>> >> >>
>> >> >> I wonder if these shouldn't fail hard if the modules don't exist?
>> >> >> Or at least pass back the error.
>> >> >>
>> >> >> Kevin?
>> >> 
>> >> is "dmg-bz" _required_ for dmg open to work? I suspect if the dmg
>> >> image is not compressed, "dmg" can function even if the extra dmg-bz
>> >> module is not loaded right?
>> >
>> > Indeed. The code seems to consider that the modules may not be present.
>> > The behaviour in these cases is questionable (it seems to silently leave
>> > the buffers as they are and return success), but the modules are clearly
>> > optional.
>> >
>> >> I'd suspect we should then do:
>> >> 
>> >> if (!block_module_load_one("dmg-bz2", &local_err)) {
>> >>   if (local_err) {
>> >>      error_report_err(local_err);
>> >>      return -EINVAL;
>> >>   }
>> >>   warn_report("dmg-bz2 is not present, dmg will skip bz2-compressed chunks */
>> >> }
>> >> 
>> >> and same for dmg-lzfse...?
>> >
>> > Actually, I think during initialisation, we should just pass NULL as
>> > errp and ignore any errors.
>> >
>> > When a request would access a block that can't be uncompressed because
>> > of the missing module, that's where we can have a warn_report_once() and
>> > arguably should fail the I/O request.
>> 
>> Seems like asking for data corruption.  To avoid it, the complete stack
>> needs to handle I/O errors correctly.
>
> If you have any component that doesn't handle I/O errors correctly, keep
> it far away from your data because it _will_ cause corruption eventually.
> The earlier it fails, the better for you.

True for immortals.  Since we're not, it actually depends on
probabilities.

> I don't think we should put great effort into making fundamentally
> broken software a little bit less broken in the corner case that you're
> least likely to hit.

Fair point.

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

> This is a change in dmg's behaviour, though, which is not the goal of
> the proposed patch. So if we want to do that, it should be a separate
> patch.

Makes sense.



  reply	other threads:[~2022-09-21 12:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 14:53 [PATCH v3 0/3] improve error handling for module load Claudio Fontana
2022-09-08 14:53 ` [PATCH v3 1/3] module: removed unused function argument "mayfail" Claudio Fontana
2022-09-08 14:53 ` [PATCH v3 2/3] module: add Error arguments to module_load_one and module_load_qom_one Claudio Fontana
2022-09-08 16:03   ` Richard Henderson
2022-09-08 17:10     ` Claudio Fontana
2022-09-08 17:36       ` Claudio Fontana
2022-09-20 16:50         ` Kevin Wolf
2022-09-21  4:45           ` Markus Armbruster
2022-09-21 11:43             ` Kevin Wolf
2022-09-21 12:08               ` Markus Armbruster [this message]
2022-09-22 14:33                 ` Kevin Wolf
2022-09-22 15:09                   ` Markus Armbruster
2022-09-21  7:50           ` Claudio Fontana
2022-09-21 11:56             ` Kevin Wolf
2022-09-23 14:10               ` Claudio Fontana
2022-09-23 14:42                 ` Kevin Wolf
2022-09-23 14:46                   ` Claudio Fontana
2022-09-23 16:29                     ` Kevin Wolf
2022-09-23 22:23                       ` Claudio Fontana
2022-09-08 14:53 ` [PATCH v3 3/3] accel: abort if we fail to load the accelerator plugin Claudio Fontana
2022-09-08 16:03   ` Richard Henderson
  -- strict thread matches above, loose matches on Subject: below --
2022-09-08 15:00 [PATCH RESEND v3 0/3] improve error handling for module load Claudio Fontana
2022-09-08 15:00 ` [PATCH v3 2/3] module: add Error arguments to module_load_one and module_load_qom_one Claudio Fontana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jx1dj5l.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=cfontana@suse.de \
    --cc=dinechin@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.