All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <naravamudan@digitalocean.com>
To: Farhan Ali <alifm@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	"open list:virtio-ccw" <qemu-s390x@nongnu.org>,
	Cornelia Huck <cohuck@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed
Date: Wed, 18 Jul 2018 11:52:02 -0700	[thread overview]
Message-ID: <20180718185202.GA24700@breakout> (raw)
In-Reply-To: <bdbb9588-a913-c449-415b-34a25fcbde9e@linux.ibm.com>

On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote:
> 
> 
> On 07/18/2018 09:42 AM, Farhan Ali wrote:
> > 
> > 
> > On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote:
> > > iiuc, this possibly implies AIO was not actually used previously on this
> > > guest (it might have silently been falling back to threaded IO?). I
> > > don't have access to s390x, but would it be possible to run qemu under
> > > gdb and see if aio_setup_linux_aio is being called at all (I think it
> > > might not be, but I'm not sure why), and if so, if it's for the context
> > > in question?
> > > 
> > > If it's not being called first, could you see what callpath is calling
> > > aio_get_linux_aio when this assertion trips?
> > > 
> > > Thanks!
> > > -Nish
> > 
> > 
> > Hi Nishant,
> > 
> >  From the coredump of the guest this is the call trace that calls
> > aio_get_linux_aio:
> > 
> > 
> > Stack trace of thread 145158:
> > #0  0x000003ff94dbe274 raise (libc.so.6)
> > #1  0x000003ff94da39a8 abort (libc.so.6)
> > #2  0x000003ff94db62ce __assert_fail_base (libc.so.6)
> > #3  0x000003ff94db634c __assert_fail (libc.so.6)
> > #4  0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x)
> > #5  0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x)
> > #6  0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x)
> > #7  0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x)
> > #8  0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x)
> > #9  0x000002aa20db3c34 aio_poll (qemu-system-s390x)
> > #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x)
> > #11 0x000003ff94f879a8 start_thread (libpthread.so.0)
> > #12 0x000003ff94e797ee thread_start (libc.so.6)
> > 
> > 
> > Thanks for taking a look and responding.
> > 
> > Thanks
> > Farhan
> > 
> > 
> > 
> 
> Trying to debug a little further, the block device in this case is a "host
> device". And looking at your commit carefully you use the
> bdrv_attach_aio_context callback to setup a Linux AioContext.
> 
> For some reason the "host device" struct (BlockDriver bdrv_host_device in
> block/file-posix.c) does not have a bdrv_attach_aio_context defined.
> So a simple change of adding the callback to the struct solves the issue and
> the guest starts fine.
> 
> 
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 28824aa..b8d59fb 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = {
>      .bdrv_refresh_limits = raw_refresh_limits,
>      .bdrv_io_plug = raw_aio_plug,
>      .bdrv_io_unplug = raw_aio_unplug,
> +    .bdrv_attach_aio_context = raw_aio_attach_aio_context,
> 
>      .bdrv_co_truncate       = raw_co_truncate,
>      .bdrv_getlength    = raw_getlength,
> 
> 
> 
> I am not too familiar with block device code in QEMU, so not sure if
> this is the right fix or if there are some underlying problems.

Oh this is quite embarassing! I only added the bdrv_attach_aio_context
callback for the file-backed device. Your fix is definitely corect for
host device. Let me make sure there weren't any others missed and I will
send out a properly formatted patch. Thank you for the quick testing and
turnaround!

-Nish

  reply	other threads:[~2018-07-18 18:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 17:25 [Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed Farhan Ali
2018-07-17 20:52 ` Nishanth Aravamudan
2018-07-18 13:42   ` Farhan Ali
2018-07-18 15:10     ` Farhan Ali
2018-07-18 18:52       ` Nishanth Aravamudan [this message]
2018-07-19  6:55         ` [Qemu-devel] [qemu-s390x] " Christian Borntraeger
2018-07-19 16:24           ` Nishanth Aravamudan

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=20180718185202.GA24700@breakout \
    --to=naravamudan@digitalocean.com \
    --cc=alifm@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=famz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=stefanha@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 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.