qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Or Ozeri <oro@il.ibm.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org, dannyh@il.ibm.com
Subject: Re: [PATCH v4 1/3] block/rbd: encryption nit fixes
Date: Thu, 12 Jan 2023 14:46:45 +0000	[thread overview]
Message-ID: <Y8AdVTH+sYI0pNnF@redhat.com> (raw)
In-Reply-To: <CAOi1vP8viVkV=asKs0RVq6bxc-9-sxCxF0aNjxFecEnLxuw=yg@mail.gmail.com>

On Thu, Jan 12, 2023 at 03:26:56PM +0100, Ilya Dryomov wrote:
> On Thu, Jan 12, 2023 at 1:35 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Sun, Nov 20, 2022 at 04:28:34AM -0600, Or Ozeri wrote:
> > > Add const modifier to passphrases,
> > > and remove redundant stack variable passphrase_len.
> > >
> > > Signed-off-by: Or Ozeri <oro@il.ibm.com>
> > > ---
> > >  block/rbd.c | 24 ++++++++++--------------
> > >  1 file changed, 10 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/block/rbd.c b/block/rbd.c
> > > index f826410f40..e575105e6d 100644
> > > --- a/block/rbd.c
> > > +++ b/block/rbd.c
> > > @@ -330,7 +330,7 @@ static int qemu_rbd_set_keypairs(rados_t cluster, const char *keypairs_json,
> > >  #ifdef LIBRBD_SUPPORTS_ENCRYPTION
> > >  static int qemu_rbd_convert_luks_options(
> > >          RbdEncryptionOptionsLUKSBase *luks_opts,
> > > -        char **passphrase,
> > > +        const char **passphrase,
> > >          size_t *passphrase_len,
> > >          Error **errp)
> > >  {
> > > @@ -341,7 +341,7 @@ static int qemu_rbd_convert_luks_options(
> > >  static int qemu_rbd_convert_luks_create_options(
> > >          RbdEncryptionCreateOptionsLUKSBase *luks_opts,
> > >          rbd_encryption_algorithm_t *alg,
> > > -        char **passphrase,
> > > +        const char **passphrase,
> > >          size_t *passphrase_len,
> > >          Error **errp)
> > >  {
> > > @@ -384,8 +384,7 @@ static int qemu_rbd_encryption_format(rbd_image_t image,
> > >                                        Error **errp)
> > >  {
> > >      int r = 0;
> > > -    g_autofree char *passphrase = NULL;
> > > -    size_t passphrase_len;
> > > +    g_autofree const char *passphrase = NULL;
> >
> > This looks wierd.  If it is as const string, why are
> > we free'ing it ?  Either want g_autofree, or const,
> > but not both.
> 
> Just curious, is it a requirement imposed by g_autofree?  Otherwise
> pointer constness and pointee lifetime are completely orthogonal and
> freeing (or, in this case, wanting to auto-free) an object referred to
> by a const pointer seems perfectly fine to me.

Free'ing a const point is not OK

$ cat c.c
#include <stdlib.h>
void bar(const char *foo) {
    free(foo);
}

$ gcc -Wall -c c.c
c.c: In function ‘bar’:
c.c:5:10: warning: passing argument 1 of ‘free’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
    5 |     free(foo);
      |          ^~~
In file included from c.c:2:
/usr/include/stdlib.h:568:25: note: expected ‘void *’ but argument is of type ‘const char *’
  568 | extern void free (void *__ptr) __THROW;
      |                   ~~~~~~^~~~~


The g_autofree happens to end up hiding this warning, because the const
annotation isn't propagated to the registere callback, but that doesn't
mean we should do that.

When a programmer sees a variable annotated const, they expect that
either someone else is responsible for free'ing it, or that the data
is statically initialized or stack allocated and thus doesn't need
free'ing.  So g_autofree + const is just wrong.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2023-01-12 15:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-20 10:28 [PATCH v4 0/3] block/rbd: Add support for layered encryption Or Ozeri
2022-11-20 10:28 ` [PATCH v4 1/3] block/rbd: encryption nit fixes Or Ozeri
2023-01-12 12:35   ` Daniel P. Berrangé
2023-01-12 14:26     ` Ilya Dryomov
2023-01-12 14:46       ` Daniel P. Berrangé [this message]
2023-01-12 17:07         ` Ilya Dryomov
2023-01-12 17:12           ` Daniel P. Berrangé
2022-11-20 10:28 ` [PATCH v4 2/3] block/rbd: Add luks-any encryption opening option Or Ozeri
2023-01-12 12:41   ` Daniel P. Berrangé
2022-11-20 10:28 ` [PATCH v4 3/3] block/rbd: Add support for layered encryption Or Ozeri
2023-01-12 12:29   ` Ilya Dryomov
2023-01-12 12:50   ` Daniel P. Berrangé
2023-01-12 13:06     ` Or Ozeri
2023-01-12 13:15       ` Daniel P. Berrangé

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=Y8AdVTH+sYI0pNnF@redhat.com \
    --to=berrange@redhat.com \
    --cc=dannyh@il.ibm.com \
    --cc=idryomov@gmail.com \
    --cc=oro@il.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).