All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-block@nongnu.org
Subject: Re: [PATCH 1/9] hw/usb/redirect.c: Stop using qemu_oom_check()
Date: Sat, 26 Feb 2022 14:26:49 -1000	[thread overview]
Message-ID: <c35cdae9-b0ce-c417-a85d-5fe632bca89f@linaro.org> (raw)
In-Reply-To: <20220226180723.1706285-2-peter.maydell@linaro.org>

On 2/26/22 08:07, Peter Maydell wrote:
> qemu_oom_check() is a function which essentially says "if you pass me
> a NULL pointer then print a message then abort()".  On POSIX systems
> the message includes strerror(errno); on Windows it includes the
> GetLastError() error value printed as an integer.
> 
> Other than in the implementation of qemu_memalign(), we use this
> function only in hw/usb/redirect.c, for three checks:
> 
>   * on a call to usbredirparser_create()
>   * on a call to usberedirparser_serialize()
>   * on a call to malloc()
> 
> The usbredir library API functions make no guarantees that they will
> set errno on errors, let alone that they might set the
> Windows-specific GetLastError string.  malloc() is documented as
> setting errno, not GetLastError -- and in any case the only thing it
> might set errno to is ENOMEM.  So qemu_oom_check() isn't the right
> thing for any of these.  Replace them with straightforward
> error-checking code.  This will allow us to get rid of
> qemu_oom_check().
> 
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> ---
> I have left all of these errors as fatal, since that's what they
> were previously. Possibly somebody with a better understanding
> of the usbredir code might be able to make them theoretically
> non-fatal, but we make malloc failures generally fatal anyway.
> ---
>   hw/usb/redirect.c | 17 ++++++++++++++---
>   1 file changed, 14 insertions(+), 3 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~


  parent reply	other threads:[~2022-02-27  0:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-26 18:07 [PATCH 0/9] Cleanup of qemu_oom_check() and qemu_memalign() Peter Maydell
2022-02-26 18:07 ` [PATCH 1/9] hw/usb/redirect.c: Stop using qemu_oom_check() Peter Maydell
2022-02-26 18:41   ` Peter Maydell
2022-02-27  0:26   ` Richard Henderson [this message]
2022-03-01  0:00   ` Philippe Mathieu-Daudé
2022-03-02 16:30   ` Eric Blake
2022-03-02 17:03     ` Peter Maydell
2022-02-26 18:07 ` [PATCH 2/9] util: Make qemu_oom_check() a static function Peter Maydell
2022-02-27  0:27   ` Richard Henderson
2022-03-01  0:00   ` Philippe Mathieu-Daudé
2022-02-26 18:07 ` [PATCH 3/9] util: Unify implementations of qemu_memalign() Peter Maydell
2022-02-27  0:29   ` Richard Henderson
2022-02-26 18:07 ` [PATCH 4/9] util/oslib-win32: Return NULL on qemu_try_memalign() with zero size Peter Maydell
2022-02-27  0:46   ` Richard Henderson
2022-02-27  0:56   ` Richard Henderson
2022-02-27 12:54     ` Peter Maydell
2022-02-27 18:36       ` Richard Henderson
2022-03-03 16:55         ` Peter Maydell
2022-03-03 23:02           ` Richard Henderson
2022-03-04 10:20             ` Peter Maydell
2022-02-26 18:07 ` [PATCH 5/9] meson.build: Don't misdetect posix_memalign() on Windows Peter Maydell
2022-02-27  0:52   ` Richard Henderson
2022-02-26 18:07 ` [PATCH 6/9] util: Share qemu_try_memalign() implementation between POSIX and Windows Peter Maydell
2022-02-27  0:56   ` Richard Henderson
2022-02-26 18:07 ` [PATCH 7/9] util: Use meson checks for valloc() and memalign() presence Peter Maydell
2022-02-27  0:58   ` Richard Henderson
2022-02-28 23:56   ` Philippe Mathieu-Daudé
2022-02-26 18:07 ` [PATCH 8/9] util: Put qemu_vfree() in memalign.c Peter Maydell
2022-02-27  1:05   ` Richard Henderson
2022-02-26 18:07 ` [PATCH 9/9] osdep: Move memalign-related functions to their own header Peter Maydell
2022-02-27  1:13   ` Richard Henderson
2022-02-28 23:58   ` Philippe Mathieu-Daudé

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=c35cdae9-b0ce-c417-a85d-5fe632bca89f@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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.