On 20.07.2018 [15:11:14 -0400], Farhan Ali wrote:
> I am seeing another issue pop up, in a different test. Even though it's a
> different assertion, it might be related based on the call trace.
Just to be clear, this does not happen if you revert the original patch
(i.e., the one you bisected to b
Hi Christian,
On 19.07.2018 [08:55:20 +0200], Christian Borntraeger wrote:
>
>
> On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote:
> > On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote:
> >>
> >>
> >> On 07/18/2018 09:42 AM, Farhan Ali wrote:
> >> I am not too familiar with block device code
In ed6e2161 ("linux-aio: properly bubble up errors from initialzation"),
I only added a bdrv_attach_aio_context callback for the bdrv_file
driver. There are several other drivers that use the shared
aio_plug callback, though, and they will trip the assertion added to
aio_get_linux_aio because they
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 t
On 17.07.2018 [13:25:53 -0400], Farhan Ali wrote:
> Hi,
>
> I am seeing some strange QEMU assertion failures for qemu on s390x,
> which prevents a guest from starting.
>
> Git bisecting points to the following commit as the source of the error.
>
> commit ed6e2161715c527330f936d44af4c547f25f687e
laio_init() can fail for a couple of reasons, which will lead to a NULL
pointer dereference in laio_attach_aio_context().
To solve this, add a aio_setup_linux_aio() function which is called
early in raw_open_common. If this fails, propagate the error up. The
signature of aio_get_linux_aio() was no
On 22.06.2018 [11:02:06 +0200], Kevin Wolf wrote:
> Am 22.06.2018 um 04:25 hat Fam Zheng geschrieben:
> > On Thu, 06/21 15:21, Nishanth Aravamudan wrote:
> > > When the AioContext changes, we need to associate a LinuxAioState with
> > > the new AioContext. Use the bdrv_attach_aio_context callback a
On 22.06.2018 [10:21:19 +0800], Fam Zheng wrote:
> On Thu, 06/21 15:21, Nishanth Aravamudan wrote:
> > laio_init() can fail for a couple of reasons, which will lead to a NULL
> > pointer dereference in laio_attach_aio_context().
> >
> > To solve this, add a aio_setup_linux_aio() function which is
laio_init() can fail for a couple of reasons, which will lead to a NULL
pointer dereference in laio_attach_aio_context().
To solve this, add a aio_setup_linux_aio() function which is called
early in raw_open_common. If this fails, propagate the error up. The
signature of aio_get_linux_aio() was no
laio_init() can fail for a couple of reasons, which will lead to a NULL
pointer dereference in laio_attach_aio_context(), called from
aio_get_linux_aio().
Test case 1:
Set /proc/sys/fs/max-aio-nr to 0. Start a guest with an aio=native
disk.
Result: laio_init() returns NULL due to not
When the AioContext changes, we need to associate a LinuxAioState with
the new AioContext. Use the bdrv_attach_aio_context callback and call
the new aio_setup_linux_aio(), which will allocate a new AioContext if
needed, and return errors on failures. If it fails for any reason,
fallback to threaded
ishanth Aravamudan geschrieben:
> > > > > On 19.06.2018 [15:35:57 -0700], Nishanth Aravamudan wrote:
> > > > > > On 19.06.2018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> > > > > > > On 19.06.2018 [14:35:33 -0500], Eric Bla
018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> > > > > On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> > > > > > On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > > >
> > > >
> > > >
> > > >
35:33 -0500], Eric Blake wrote:
> > > > > On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > >
> > >
> > >
> > > > > > } else if (s->use_linux_aio) {
> > > > > > +int rc;
&g
On 19.06.2018 [15:35:57 -0700], Nishanth Aravamudan wrote:
> On 19.06.2018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> > On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> > > On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
>
>
>
>
On 19.06.2018 [13:14:51 -0700], Nishanth Aravamudan wrote:
> On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> > On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > > } else if (s->use_linux_aio) {
> > > +
On 19.06.2018 [14:35:33 -0500], Eric Blake wrote:
> On 06/15/2018 12:47 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > laio_init() can fail for a couple of reasons, which will lead to a NULL
> > pointer dereference in laio_attach_aio_context().
> >
> > To solve this
laio_init() can fail for a couple of reasons, which will lead to a NULL
pointer dereference in laio_attach_aio_context().
To solve this, add a aio_setup_linux_aio() function which is called
before aio_get_linux_aio() where it is called currently, and which
propogates setup errors up. The signature
Hi Kevin,
On 15.06.2018 [10:41:26 +0200], Kevin Wolf wrote:
> Am 15.06.2018 um 01:21 hat Nishanth Aravamudan geschrieben:
> > laio_init() can fail for a couple of reasons, which will lead to a NULL
> > pointer dereference in laio_attach_aio_context().
> >
> > To solve this, add a aio_linux_aio_se
laio_init() can fail for a couple of reasons, which will lead to a NULL
pointer dereference in laio_attach_aio_context().
To solve this, add a aio_linux_aio_setup() path which is called where
aio_get_linux_aio() is called currently, but can propogate errors up.
virtio-block and virtio-scsi call t
On Wed, May 23, 2018 at 10:53 AM, John Snow wrote:
>
>
>
> On 05/22/2018 06:01 PM, Nishanth Aravamudan via Qemu-devel wrote:
> > Hi!
> >
>
> Hi! CCing qemu-bl...@nongnu.org;
>
> > I'm tracking an error case in the native AIO path, and was wondering if
Hi!
I'm tracking an error case in the native AIO path, and was wondering if
there was a latent (albeit possibly hard to hit) bug. Specifically
util/async.c::aio_get_linux_aio:
#ifdef CONFIG_LINUX_AIO
LinuxAioState *aio_get_linux_aio(AioContext *ctx)
{
if (!ctx->linux_aio) {
ctx->linux
22 matches
Mail list logo
