All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, peterx@redhat.com, farosas@suse.de,
	peter.maydell@linaro.org
Subject: Re: g_autoptr(Error) (was: [PATCH] migration: Fix double-free on error path)
Date: Tue, 25 Nov 2025 11:25:32 +0000	[thread overview]
Message-ID: <aSWSLMi6ZhTCS_p2@redhat.com> (raw)
In-Reply-To: <871plmk1bc.fsf@pond.sub.org>

On Tue, Nov 25, 2025 at 08:40:07AM +0100, Markus Armbruster wrote:
> g_autoptr(T) is quite useful when the object's extent matches the
> function's.
> 
> This isn't the case for an Error object the function propagates to its
> caller.  It is the case for an Error object the function reports or
> handles itself.  However, the functions to report Error also free it.
> 
> Thus, g_autoptr(Error) is rarely applicable.  We have just three
> instances out of >1100 local Error variables, all in migration code.
> 
> Two want to move the error to the MigrationState for later handling /
> reporting.  Since migrate_set_error() doesn't move, but stores a copy,
> the original needs to be freed, and g_autoptr() is correct there.  We
> have 17 more that instead manually free with error_free() or
> error_report_err() right after migrate_set_error().
> 
> We recently discussed storing a copy vs. move the original:
> 
>     From: Peter Xu <peterx@redhat.com>
>     Subject: Re: [PATCH 0/3] migration: Error fixes and improvements
>     Date: Mon, 17 Nov 2025 11:03:37 -0500
>     Message-ID: <aRtHWbWcTh3OF2wY@x1.local>
> 
> The two g_autoptr() gave me pause when I investigated this topic, simply
> because they deviate from the common pattern migrate_set_error(s, err)
> followed by error_free() or error_report_err().
> 
> The third one became wrong when I cleaned up the reporting (missed in
> the cleanup patch, fixed in the patch I'm replying to).  I suspect my
> mistake escaped review for the same reason I made it: g_autoptr(Error)
> is unusual and not visible in the patch hunk.
> 
> Would you like me to replace the two correct uses of g_autoptr(Error) by
> more common usage?

I had previously proposed g_autoptr(Error) a year or two back and you
rejected it then, so I'm surprised to see that it got into the code,
because it requires explicit opt-in via a G_DEFINE_AUTOPTR_CLEANUP_FUNC.

Unfortunately it appears exactly that was added earlier this year in

  commit 18eb55546a54e443d94a4c49286348176ad4b00a
  Author: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
  Date:   Tue Mar 4 23:03:35 2025 +0100

    error: define g_autoptr() cleanup function for the Error type
    
    Automatic memory management helps avoid memory safety issues.
    
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Link: https://lore.kernel.org/qemu-devel/a5843c5fa64d7e5239a4316092ec0ef0d10c2320.1741124640.git.maciej.szmigiero@oracle.com
    Signed-off-by: Cédric Le Goater <clg@redhat.com>


When removing this usage, ensure that commit is reverted too, which
will prevent anyone unwittingly re-introducing g_autoptr(Error)
usage

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:[~2025-11-25 11:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-25  7:05 [PATCH] migration: Fix double-free on error path Markus Armbruster
2025-11-25  7:11 ` Markus Armbruster
2025-11-25 15:41   ` Peter Xu
2025-11-25  7:12 ` Marc-André Lureau
2025-11-25 12:59   ` Markus Armbruster
2025-11-25 15:47     ` Peter Xu
2025-11-25 18:48       ` Markus Armbruster
2025-11-25 19:32         ` Peter Xu
2025-11-26  6:12           ` Should functions that free memory clear the pointer? (was: [PATCH] migration: Fix double-free on error path) Markus Armbruster
2025-11-26  8:21             ` Should functions that free memory clear the pointer? Cédric Le Goater
2025-11-25  7:16 ` [PATCH] migration: Fix double-free on error path Philippe Mathieu-Daudé
2025-11-25  7:40 ` g_autoptr(Error) (was: [PATCH] migration: Fix double-free on error path) Markus Armbruster
2025-11-25 11:25   ` Daniel P. Berrangé [this message]
2025-11-25 11:46     ` g_autoptr(Error) Markus Armbruster
2025-11-25 16:15       ` g_autoptr(Error) Peter Xu
2025-11-25 19:02         ` g_autoptr(Error) Markus Armbruster
2025-11-25 20:49           ` g_autoptr(Error) Peter Xu
2025-11-26  8:19         ` g_autoptr(Error) Cédric Le Goater
2025-11-26 10:26           ` g_autoptr(Error) Cédric Le Goater
2025-11-26 11:46             ` g_autoptr(Error) Markus Armbruster
2025-11-26 12:00               ` g_autoptr(Error) Daniel P. Berrangé
2025-11-26 12:41                 ` g_autoptr(Error) Markus Armbruster
2025-11-26 13:27                 ` g_autoptr(Error) Peter Maydell
2025-11-26 14:01                   ` g_autoptr(Error) Markus Armbruster
2025-12-02  8:34 ` [PATCH] migration: Fix double-free on error path Markus Armbruster

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=aSWSLMi6ZhTCS_p2@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=farosas@suse.de \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --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.