From: Pankaj Gupta <pagupta@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
QEMU <qemu-devel@nongnu.org>,
xiaohli@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] chardev: Avoid adding duplicate chardev
Date: Thu, 7 Feb 2019 05:13:06 -0500 (EST) [thread overview]
Message-ID: <1487450667.70375757.1549534386311.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20190207093400.GB19438@redhat.com>
> > > Thanks for your reply. Please find my reply inline.
> > >
> > > > > > Hotplugging existing char chardev with qmp, dereferences(removes)
> > > > > > existing chardev. This patch avoids adding a chardev if a chardev
> > > > > > with same id exists.
> > > > >
> > > > > As you pointed out, if you attempt to add a chardev with an existing
> > > > > ID, you get an error:
> > > > >
> > > > > {"execute":"chardev-add","arguments":{"id":"charchannel1","backend":{"type":"socket","data":{"addr":{"type":"unix",
> > > > > "data": {"path": "/tmp/helloworld1"}}}}}}
> > > > > {"return": {}}
> > > > > {"execute":"chardev-add","arguments":{"id":"charchannel1","backend":{"type":"socket","data":{"addr":{"type":"unix",
> > > > > "data": {"path": "/tmp/helloworld1"}}}}}}
> > > > > {"error": {"class": "GenericError", "desc": "attempt to add duplicate
> > > > > property 'charchannel1' to object (type 'container')"}}
> > > > >
> > > > >
> > > > > But the existing chardev is left untouched.
> > > > >
> > > > > However, since unix socket chardev will delete existing file and
> > > > > rebind (this is not always a good idea, but people seem to prefer
> > > > > that)
> > > > > the rebound socket is removed on error cleanup.
> > > > >
> > > > >
> > > > > I am not sure this is a bug tbh.
> > > > >
> > > > > Your solution to check for duplicate ID upfront is ok. But any other
> > > > > later error path could have the same "bug" effect of removing
> > > > > existing
> > > > > chardev because of the overwrite socket creation.
> > > >
> > > > Checking the ID is not a useful fix IMHO. Someone could just as easily
> > > > send 2 commands with different IDs and the same socket path.
> > > >
> > > > A more accurate fix would be to iterate over existing chardevs and
> > > > check
> > > > whether any of them clash, but even that is useless if you have two
> > > > separate QEMU instances and both try to use the same UNIX socket path.
> > > > To deal with that you need to start taking out fcntl locks to ensure
> > > > real mutual exclusion.
> > >
> > > The reason we are already throwing error "attempt to add duplicate
> > > property"
> > > implies we are considering "id" as primary key? Even if we throw the
> > > error
> > > existing chardev should work as before. But this is not the case right
> > > now,
> > > it just deletes the existing chardev after error.
> >
> > It deletes the socket "file" (since it overwrites it on chardev
> > creation). The existing chardev is not deleted:
>
> I think this is yet another example of why it is a bad idea for the
> qemu_chardev_new API to also open the backend. We should have a
> qemu_chardev_new that only does the arg parsing, object creation
> and registration. Then have a separate API for actually opening
> it.
Agree. This looks bigger fix. Till we fix that. Can we accept this patch
to avoid deleting/corrupting existing socket "file" if user tries to add
chardev with existing same "id"?
Thanks,
Pankaj
next prev parent reply other threads:[~2019-02-07 10:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 6:28 [Qemu-devel] [PATCH v2] chardev: Avoid adding duplicate chardev Pankaj Gupta
2019-01-29 8:34 ` Stefano Garzarella
2019-02-06 16:08 ` Marc-André Lureau
2019-02-06 16:29 ` Daniel P. Berrangé
2019-02-07 7:21 ` Pankaj Gupta
2019-02-07 9:11 ` Marc-André Lureau
2019-02-07 9:34 ` Daniel P. Berrangé
2019-02-07 10:13 ` Pankaj Gupta [this message]
2019-02-07 10:15 ` Marc-André Lureau
2019-02-07 10:24 ` Pankaj Gupta
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=1487450667.70375757.1549534386311.JavaMail.zimbra@redhat.com \
--to=pagupta@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xiaohli@redhat.com \
/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).