All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH 4/9] util/oslib-win32: Return NULL on qemu_try_memalign() with zero size
Date: Thu, 3 Mar 2022 16:55:56 +0000	[thread overview]
Message-ID: <CAFEAcA9mO0rEuhj4rxerDF7qiePjWo0tUs5PBUF-zqgxqsdm3A@mail.gmail.com> (raw)
In-Reply-To: <91cc02c4-8ea5-23e7-7384-6c6b2c8e12b5@linaro.org>

On Sun, 27 Feb 2022 at 18:36, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 2/27/22 02:54, Peter Maydell wrote:
> >>> +    if (size) {
> >>> +        ptr = _aligned_malloc(size, alignment);
> >>> +    } else {
> >>> +        ptr = NULL;
> >>> +    }
> >>
> >> Oh, should we set errno to something here?
> >> Otherwise a random value will be used by qemu_memalign.
> >
> > Yeah, I guess so, though the errno to use isn't obvious. Maybe EINVAL?
> >
> > The alternative would be to try to audit all the callsites to
> > confirm they don't ever try to allocate 0 bytes and then have
> > the assert for both Windows and POSIX versions...
>
> Alternately, force size == 1, so that we always get a non-NULL value that can be freed.
> That's a change on the POSIX side as well, of course.

Yes, I had a look at what actual malloc() implementations tend
to do, and the answer seems to be that forcing size to 1 gives
less weird behaviour for the application. So here that would be

   if (size == 0) {
       size++;
   }
   ptr = _aligned_malloc(size, alignment);

We don't need to do anything on the POSIX side (unless we want to
enforce consistency of handling the size==0 case).

I'd quite like to get this series in before softfreeze (though mostly
just for my personal convenience so it's not hanging around as a
loose end I have to come back to after we reopen for 7.1). Does anybody
object if I squash in that change and put this in a pullrequest,
or would you prefer to see a v2 series first?

thanks
-- PMM


  reply	other threads:[~2022-03-03 16:58 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
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 [this message]
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=CAFEAcA9mO0rEuhj4rxerDF7qiePjWo0tUs5PBUF-zqgxqsdm3A@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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.