qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Straub <lukasstraub2@web.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel Berrange" <berrange@redhat.com>,
	qemu-block <qemu-block@nongnu.org>,
	"Juan Quintela" <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>
Subject: Re: [PATCH v2 1/4] Introduce yank feature
Date: Fri, 19 Jun 2020 18:26:20 +0200	[thread overview]
Message-ID: <20200619182620.4e8736ed@luklap> (raw)
In-Reply-To: <20200617143936.GJ1728005@stefanha-x1.localdomain>

[-- Attachment #1: Type: text/plain, Size: 4141 bytes --]

On Wed, 17 Jun 2020 15:39:36 +0100
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Thu, May 21, 2020 at 04:48:06PM +0100, Daniel P. Berrangé wrote:
> > On Thu, May 21, 2020 at 05:42:41PM +0200, Lukas Straub wrote:  
> > > On Thu, 21 May 2020 16:03:35 +0100
> > > Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >   
> > > > On Wed, May 20, 2020 at 11:05:39PM +0200, Lukas Straub wrote:  
> > > > > +void yank_generic_iochannel(void *opaque)
> > > > > +{
> > > > > +    QIOChannel *ioc = QIO_CHANNEL(opaque);
> > > > > +
> > > > > +    qio_channel_shutdown(ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
> > > > > +}
> > > > > +
> > > > > +void qmp_yank(strList *instances, Error **errp)
> > > > > +{
> > > > > +    strList *tmp;
> > > > > +    struct YankInstance *instance;
> > > > > +    struct YankFuncAndParam *entry;
> > > > > +
> > > > > +    qemu_mutex_lock(&lock);
> > > > > +    tmp = instances;
> > > > > +    for (; tmp; tmp = tmp->next) {
> > > > > +        instance = yank_find_instance(tmp->value);
> > > > > +        if (!instance) {
> > > > > +            error_set(errp, ERROR_CLASS_DEVICE_NOT_FOUND,
> > > > > +                      "Instance '%s' not found", tmp->value);
> > > > > +            qemu_mutex_unlock(&lock);
> > > > > +            return;
> > > > > +        }
> > > > > +    }
> > > > > +    tmp = instances;
> > > > > +    for (; tmp; tmp = tmp->next) {
> > > > > +        instance = yank_find_instance(tmp->value);
> > > > > +        assert(instance);
> > > > > +        QLIST_FOREACH(entry, &instance->yankfns, next) {
> > > > > +            entry->func(entry->opaque);
> > > > > +        }
> > > > > +    }
> > > > > +    qemu_mutex_unlock(&lock);
> > > > > +}    
> > > > 
> > > > From docs/devel/qapi-code-gen.txt:
> > > > 
> > > >   An OOB-capable command handler must satisfy the following conditions:
> > > > 
> > > >   - It terminates quickly.  
> > > Check.
> > >   
> > > >   - It does not invoke system calls that may block.  
> > > brk/sbrk (malloc and friends):
> > > The manpage doesn't say anything about blocking, but malloc is already used while handling the qmp command.
> > > 
> > > shutdown():
> > > The manpage doesn't say anything about blocking, but this is already used in migration oob qmp commands.  
> > 
> > It just marks the socket state in local kernel side. It doesn't involve
> > any blocking roundtrips over the wire, so this is fine.
> >   
> > > 
> > > There are no other syscalls involved to my knowledge.
> > >   
> > > >   - It does not access guest RAM that may block when userfaultfd is
> > > >     enabled for postcopy live migration.  
> > > Check.
> > >   
> > > >   - It takes only "fast" locks, i.e. all critical sections protected by
> > > >     any lock it takes also satisfy the conditions for OOB command
> > > >     handler code.  
> > > 
> > > The lock in yank.c satisfies this requirement.
> > > 
> > > qio_channel_shutdown doesn't take any locks.  
> > 
> > Agreed, I think the yank code is compliant with all the points
> > listed above.  
> 
> The code does not document this in any way. In fact, it's an interface
> for registering arbitrary callback functions which execute in this
> special environment.
> 
> If you don't document this explicitly it will break when someone changes
> the code, even if it works right now.
> 
> Please document this in the yank APIs and also in the implementation.

Hi,
It is documented in yank.h:

/**
 * yank_register_function: Register a yank function
 *
 * This registers a yank function. All limitations of qmp oob commands apply
 * to the yank function as well.
 *
 * This function is thread-safe.
 *
 * @instance_name: The name of the instance
 * @func: The yank function
 * @opaque: Will be passed to the yank function
 */

Thanks,
Lukas Straub

> For example, QemuMutex yank has the priority inversion problem: no other
> function may violate the oob rules while holding the mutex, otherwise
> the oob function will hang while waiting for the lock when the other
> function is blocked.
> 
> Stefan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-19 16:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 21:05 [PATCH v2 0/4] Introduce 'yank' oob qmp command to recover from hanging qemu Lukas Straub
2020-05-20 21:05 ` [PATCH v2 1/4] Introduce yank feature Lukas Straub
2020-05-20 22:48   ` Paolo Bonzini
2020-05-21 15:03   ` Stefan Hajnoczi
2020-05-21 15:42     ` Lukas Straub
2020-05-21 15:48       ` Daniel P. Berrangé
2020-06-17 14:39         ` Stefan Hajnoczi
2020-06-19 16:26           ` Lukas Straub [this message]
2020-05-20 21:05 ` [PATCH v2 2/4] block/nbd.c: Add " Lukas Straub
2020-05-20 21:05 ` [PATCH v2 3/4] chardev/char-socket.c: " Lukas Straub
2020-05-20 21:05 ` [PATCH v2 4/4] migration: " Lukas Straub
2020-05-21 15:44   ` Lukas Straub
2020-05-20 23:15 ` [PATCH v2 0/4] Introduce 'yank' oob qmp command to recover from hanging qemu no-reply
2020-05-20 23:21 ` no-reply

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=20200619182620.4e8736ed@luklap \
    --to=lukasstraub2@web.de \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@gmail.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).