From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, QEMU <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] char: do not use atexit cleanup handler
Date: Mon, 4 Jul 2016 18:12:48 +0100 [thread overview]
Message-ID: <20160704171248.GP3763@redhat.com> (raw)
In-Reply-To: <CAJ+F1CKdu_MonDfd_xZzch8f_iPnb9h=C5URSorWk26GPGj6aw@mail.gmail.com>
On Mon, Jul 04, 2016 at 06:43:42PM +0200, Marc-André Lureau wrote:
> Hi
>
> On Mon, Jul 4, 2016 at 6:31 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
> > On Mon, Jul 04, 2016 at 05:38:23PM +0200, marcandre.lureau@redhat.com wrote:
> >> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >>
> >> It turns out qemu is calling exit() in various places from various
> >> threads without taking much care of resources state. The atexit()
> >> cleanup handlers cannot easily destroy resources that are in use (by
> >> the same thread or other).
> >
> > [snip]
> >
> >> Instead of using a atexit() handler, only run the chardev cleanup as
> >> initially proposed at the end of main(), where there are less chances
> >> (hic) of conflicts or other races.
> >
> > This doesn't really seem all that much safer. There's still plenty of
> > chance that threads are running in the background at the end of the
> > main() method, so plenty of scope for the qemu_chr_cleanup() call to
> > cause threads to segv by destroying the chardevs they're using behind
> > their back.
>
> Yep yep
>
> Note, just before the end of main() all CPU threads should be frozen.
>
> Is there any reason why there is no support for joining an cleaning up
> all the running threads at this point?
>
> > IIUC, the original intent here was that we call unlink() on the UNIX
> > socket paths when QEMU exits.
> >
> > Surely we can come up with a way to that, and only that, upon exit,
> > without actually having to free the chardev memory with all the risks
> > that entails.
>
> Doesn't sound that simple if you can't take the lock. And when you do
> you can't destroy it. It sounds hard to avoid races, so I might be
> missing something.
The other option is to not try to do this at the chardev level at all.
Instead we could have the QIOChannelSocket impl maintain a list of UNIX
socket paths that need unlinking, and have it register an atexit() handler
itself, whose sole purpose is to unlink the paths. We could simply have a
global GList of char* UNIX socket paths, so the atexit handler would not
touch the QIOChannelSocket objects at all. This avoiding all races or
issues with concurrent access.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2016-07-04 17:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-04 15:38 [Qemu-devel] [PATCH] char: do not use atexit cleanup handler marcandre.lureau
2016-07-04 15:49 ` Paolo Bonzini
2016-07-04 16:31 ` Daniel P. Berrange
2016-07-04 16:43 ` Marc-André Lureau
2016-07-04 17:12 ` Daniel P. Berrange [this message]
2016-07-04 16:46 ` Paolo Bonzini
2016-07-04 17:07 ` Daniel P. Berrange
2016-07-04 17:08 ` Paolo Bonzini
2016-07-04 17:19 ` Marc-André Lureau
2016-07-04 19:53 ` Gerd Hoffmann
2016-07-05 8:24 ` Paolo Bonzini
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=20160704171248.GP3763@redhat.com \
--to=berrange@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=pbonzini@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.