All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jason Wang <jasowang@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Laura Abbott <labbott@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Christoph Hellwig <hch@lst.de>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest
Date: Thu, 23 Mar 2017 15:22:15 +0100	[thread overview]
Message-ID: <20170323142215.GA30988@lst.de> (raw)
In-Reply-To: <e042635f-e30e-45e8-f4a5-b03b9228eec2@redhat.com>

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
>
>
> On 2017年03月23日 08:30, Laura Abbott wrote:
>> Hi,
>>
>> Fedora has received multiple reports of crashes when running
>> 4.11 as a guest
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1430297
>> https://bugzilla.redhat.com/show_bug.cgi?id=1434462
>> https://bugzilla.kernel.org/show_bug.cgi?id=194911
>> https://bugzilla.redhat.com/show_bug.cgi?id=1433899
>>
>> The crashes are not always consistent but they are generally
>> some flavor of oops or GPF in virtio related code. Multiple people
>> have done bisections (Thank you Thorsten Leemhuis and
>> Richard W.M. Jones) and found this commit to be at fault
>>
>> 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507 is the first bad commit
>> commit 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507
>> Author: Christoph Hellwig <hch@lst.de>
>> Date:   Sun Feb 5 18:15:19 2017 +0100
>>
>>      virtio_pci: use shared interrupts for virtqueues
>>           This lets IRQ layer handle dispatching IRQs to separate handlers 
>> for the
>>      case where we don't have per-VQ MSI-X vectors, and allows us to greatly
>>      simplify the code based on the assumption that we always have interrupt
>>      vector 0 (legacy INTx or config interrupt for MSI-X) available, and
>>      any other interrupt is request/freed throught the VQ, even if the
>>      actual interrupt line might be shared in some cases.
>>           This allows removing a great deal of variables keeping track of 
>> the
>>      interrupt state in struct virtio_pci_device, as we can now simply walk the
>>      list of VQs and deal with per-VQ interrupt handlers there, and only treat
>>      vector 0 special.
>>           Additionally clean up the VQ allocation code to properly unwind 
>> on error
>>      instead of having a single global cleanup label, which is error prone,
>>      and in this case also leads to more code.
>>           Signed-off-by: Christoph Hellwig <hch@lst.de>
>>      Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> :040000 040000 79a8267ffb73f9d244267c5f68365305bddd4696 8832a160b978710bbd24ba6966f462b3faa27fcc M	drivers
>>
>> It doesn't revert cleanly so we haven't been able to do a clean
>> test. Any ideas?
>>
>> Thanks,
>> Laura
>
> Hello:
>
> Can you try the attached patch to see if it solves the problem? (At least 
> it silent KASan warnings for me).

This looks like a correct fix to me, independent of fixing the original
bug or not:

Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jason Wang <jasowang@redhat.com>
Cc: Laura Abbott <labbott@redhat.com>, Christoph Hellwig <hch@lst.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest
Date: Thu, 23 Mar 2017 15:22:15 +0100	[thread overview]
Message-ID: <20170323142215.GA30988@lst.de> (raw)
In-Reply-To: <e042635f-e30e-45e8-f4a5-b03b9228eec2@redhat.com>

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
>
>
> On 2017年03月23日 08:30, Laura Abbott wrote:
>> Hi,
>>
>> Fedora has received multiple reports of crashes when running
>> 4.11 as a guest
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1430297
>> https://bugzilla.redhat.com/show_bug.cgi?id=1434462
>> https://bugzilla.kernel.org/show_bug.cgi?id=194911
>> https://bugzilla.redhat.com/show_bug.cgi?id=1433899
>>
>> The crashes are not always consistent but they are generally
>> some flavor of oops or GPF in virtio related code. Multiple people
>> have done bisections (Thank you Thorsten Leemhuis and
>> Richard W.M. Jones) and found this commit to be at fault
>>
>> 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507 is the first bad commit
>> commit 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507
>> Author: Christoph Hellwig <hch@lst.de>
>> Date:   Sun Feb 5 18:15:19 2017 +0100
>>
>>      virtio_pci: use shared interrupts for virtqueues
>>           This lets IRQ layer handle dispatching IRQs to separate handlers 
>> for the
>>      case where we don't have per-VQ MSI-X vectors, and allows us to greatly
>>      simplify the code based on the assumption that we always have interrupt
>>      vector 0 (legacy INTx or config interrupt for MSI-X) available, and
>>      any other interrupt is request/freed throught the VQ, even if the
>>      actual interrupt line might be shared in some cases.
>>           This allows removing a great deal of variables keeping track of 
>> the
>>      interrupt state in struct virtio_pci_device, as we can now simply walk the
>>      list of VQs and deal with per-VQ interrupt handlers there, and only treat
>>      vector 0 special.
>>           Additionally clean up the VQ allocation code to properly unwind 
>> on error
>>      instead of having a single global cleanup label, which is error prone,
>>      and in this case also leads to more code.
>>           Signed-off-by: Christoph Hellwig <hch@lst.de>
>>      Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> :040000 040000 79a8267ffb73f9d244267c5f68365305bddd4696 8832a160b978710bbd24ba6966f462b3faa27fcc M	drivers
>>
>> It doesn't revert cleanly so we haven't been able to do a clean
>> test. Any ideas?
>>
>> Thanks,
>> Laura
>
> Hello:
>
> Can you try the attached patch to see if it solves the problem? (At least 
> it silent KASan warnings for me).

This looks like a correct fix to me, independent of fixing the original
bug or not:

Reviewed-by: Christoph Hellwig <hch@lst.de>

  reply	other threads:[~2017-03-23 14:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23  0:30 [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest Laura Abbott
2017-03-23  5:13 ` Jason Wang
2017-03-23  5:13   ` Jason Wang
2017-03-23 14:22   ` Christoph Hellwig [this message]
2017-03-23 14:22     ` Christoph Hellwig
2017-03-23 15:19   ` Richard W.M. Jones
2017-03-23 15:19     ` Richard W.M. Jones
2017-03-23 16:41     ` Michael S. Tsirkin
2017-03-23 16:41       ` Michael S. Tsirkin
2017-03-23 17:15       ` Thorsten Leemhuis
2017-03-23 17:15       ` Thorsten Leemhuis

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=20170323142215.GA30988@lst.de \
    --to=hch@lst.de \
    --cc=jasowang@redhat.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.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.