Re: Bug inkvm_set_irq
On Thu, Mar 17, 2011 at 09:00:30AM +0100, Jean-Philippe Menil wrote: > >>Are you running a preemptible kernel? > >>Does the following help at all? > >> > >>diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c > >>index 2ca4535..cdf51c9 100644 > >>--- a/virt/kvm/eventfd.c > >>+++ b/virt/kvm/eventfd.c > >>@@ -90,7 +90,7 @@ irqfd_shutdown(struct work_struct *work) > >> * We know no new events will be scheduled at this point, so block > >> * until all previously outstanding events have completed > >> */ > >>- flush_work(&irqfd->inject); > >>+ flush_work_sync(&irqfd->inject); > >> > >>/* > >> * It is now safe to release the object's resources > >> > >Hi, > > > >thanks for the response. > > > >root@ayrshire:~# zcat /proc/config.gz | grep -i preempt > ># CONFIG_PREEMPT_RCU is not set > >CONFIG_PREEMPT_NOTIFIERS=y > >CONFIG_PREEMPT_NONE=y > ># CONFIG_PREEMPT_VOLUNTARY is not set > ># CONFIG_PREEMPT is not set > > > >It does not seem to be a preemptible kernel. > > > >I will test tour patch, and report the result. > > > >Regards. > > > Hi, > > i reboot the host with the "flush_work_sync", yesterday at lunchtime. > I haven't see "Eventfd bug detected" or "Wakeup bug detected" until now. > > The modification seem to do the trick. > > So, if my understand is correct, flush_work flush the last irqfd, > but in my case, antoher irqfd was still queued to a cpu? > Is that right? > > Regards. Yes, it says: * flush_work - wait for a work to finish executing the last queueing instance * @work: the work to flush * * Wait until @work has finished execution. This function considers * only the last queueing instance of @work. If @work has been * enqueued across different CPUs on a non-reentrant workqueue or on * multiple workqueues, @work might still be executing on return on * some of the CPUs from earlier queueing. * * If @work was queued only on a non-reentrant, ordered or unbound * workqueue, @work is guaranteed to be idle on return if it hasn't * been requeued since flush started. kvm uses the default workqueue which is non-reentrant. Thanks to Gleb for the suggestion! -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
On Wed, Mar 09, 2011 at 02:12:58PM +0100, Jean-Philippe Menil wrote:
> Le 09/03/2011 14:00, Michael S. Tsirkin a écrit :
> >On Wed, Mar 09, 2011 at 01:28:43PM +0100, Jean-Philippe Menil wrote:
> >>Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
> >>>On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
> Yes, it's a 2.6.37.2 kernel.
> >>>OK, here's a debugging patch.
> >>>Please run with slab debugging as previously until you see
> >>>'eventfd bug detected!' in dmesg or until there is a crash.
> >>>It might be also useful to enable timestampts on printk with
> >>> Symbol: PRINTK_TIME [=y]
> >>> │ Type : boolean
> >>> │ Prompt: Show timing information on printks
> >>>
> >>>once you see the error, please upload the
> >>>full dmesg output somewhere to we can track what
> >>>goes on.
> >>>
> >>>Hopefully there won't be an oops this time which
> >>>should make it easier for you to test (no need to
> >>>reboot).
> >>>
> >>>
> >>>diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> >>>index c1f1e3c..3cb679b 100644
> >>>--- a/virt/kvm/eventfd.c
> >>>+++ b/virt/kvm/eventfd.c
> >>>@@ -32,6 +32,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>>+#include
> >>>
> >>> #include "iodev.h"
> >>>
> >>>@@ -43,6 +44,8 @@
> >>> *
> >>> */
> >>>
> >>>+#define KVM_BAD_PTR ((void*)(long)(0x6b6b6b6b6b6b6b6bull))
> >>>+
> >>> struct _irqfd {
> >>> struct kvm *kvm;
> >>> struct eventfd_ctx *eventfd;
> >>>@@ -61,6 +64,13 @@ irqfd_inject(struct work_struct *work)
> >>> {
> >>> struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> >>> struct kvm *kvm = irqfd->kvm;
> >>>+ if (kvm == KVM_BAD_PTR) {
> >>>+ printk(KERN_ERR "Eventfd bug detected!\n");
> >>>+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p,gsi=%d)\n",
> >>>__func__,
> >>>+ work, irqfd, kvm, irqfd->gsi);
> >>>+ trigger_all_cpu_backtrace();
> >>>+ return;
> >>>+ }
> >>>
> >>> kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
> >>> kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
> >>>@@ -75,6 +85,8 @@ irqfd_shutdown(struct work_struct *work)
> >>> struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown);
> >>> u64 cnt;
> >>>
> >>>+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
> >>>+ work, irqfd, irqfd->kvm, irqfd->gsi);
> >>> /*
> >>>* Synchronize with the wait-queue and unhook ourselves to prevent
> >>>* further events.
> >>>@@ -91,6 +103,8 @@ irqfd_shutdown(struct work_struct *work)
> >>>* It is now safe to release the object's resources
> >>>*/
> >>> eventfd_ctx_put(irqfd->eventfd);
> >>>+ printk(KERN_ERR "kfree at %s(work=%p,irqfd=%p)\n", __func__,
> >>>+ work, irqfd);
> >>> kfree(irqfd);
> >>> }
> >>>
> >>>@@ -111,6 +125,8 @@ static void
> >>> irqfd_deactivate(struct _irqfd *irqfd)
> >>> {
> >>> BUG_ON(!irqfd_is_active(irqfd));
> >>>+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
> >>>+ irqfd, irqfd->kvm, irqfd->gsi);
> >>>
> >>> list_del_init(&irqfd->list);
> >>>
> >>>@@ -178,6 +194,8 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
> >>>
> >>> irqfd->kvm = kvm;
> >>> irqfd->gsi = gsi;
> >>>+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
> >>>+ irqfd, kvm, gsi);
> >>> INIT_LIST_HEAD(&irqfd->list);
> >>> INIT_WORK(&irqfd->inject, irqfd_inject);
> >>> INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
> >>>@@ -264,6 +282,8 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
> >>> struct _irqfd *irqfd, *tmp;
> >>> struct eventfd_ctx *eventfd;
> >>>
> >>>+ printk(KERN_ERR "%s(kvm=%p, gsi=%d)\n", __func__,
> >>>+ kvm, gsi);
> >>> eventfd = eventfd_ctx_fdget(fd);
> >>> if (IS_ERR(eventfd))
> >>> return PTR_ERR(eventfd);
> >>>@@ -305,6 +325,7 @@ void
> >>> kvm_irqfd_release(struct kvm *kvm)
> >>> {
> >>> struct _irqfd *irqfd, *tmp;
> >>>+ printk(KERN_ERR "%s(kvm=%p)\n", __func__, kvm);
> >>>
> >>> spin_lock_irq(&kvm->irqfds.lock);
> >>>
> >>>--
> >>>To unsubscribe from this list: send the line "unsubscribe netdev" in
> >>>the body of a message to majord...@vger.kernel.org
> >>>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>Hi,
> >>
> >>I boot the host with the patched kernel yesterday.
> >>No crach until now, but two "Eventfd bug detected!" in the log at
> >>"Mar 9 02:04:31" and "Mar 9 02:15:17"
> >>You can find part of the log at the following adress:
> >>http://filex.univ-nantes.fr/get?k=jL4Fe7yfSMN57toAH7V
> >>
> >>It a split file of the kern.log (1,4G), so if you need another part
> >>of the log, let me know.
> >>
> >>Thanks for all.
> >>
> >>Regards.
> >Downloading, it's big :)
> >What about some 1000 lines before and after Eventfd bug detected! line?
> >--
> >To unsubscribe from this list: send the line "unsubscribe kvm" in
> >the body of a mes
Re: Bug inkvm_set_irq
Le 09/03/2011 14:00, Michael S. Tsirkin a écrit :
On Wed, Mar 09, 2011 at 01:28:43PM +0100, Jean-Philippe Menil wrote:
Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
Yes, it's a 2.6.37.2 kernel.
OK, here's a debugging patch.
Please run with slab debugging as previously until you see
'eventfd bug detected!' in dmesg or until there is a crash.
It might be also useful to enable timestampts on printk with
Symbol: PRINTK_TIME [=y]
│ Type : boolean
│ Prompt: Show timing information on printks
once you see the error, please upload the
full dmesg output somewhere to we can track what
goes on.
Hopefully there won't be an oops this time which
should make it easier for you to test (no need to
reboot).
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index c1f1e3c..3cb679b 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "iodev.h"
@@ -43,6 +44,8 @@
*
*/
+#define KVM_BAD_PTR ((void*)(long)(0x6b6b6b6b6b6b6b6bull))
+
struct _irqfd {
struct kvm *kvm;
struct eventfd_ctx *eventfd;
@@ -61,6 +64,13 @@ irqfd_inject(struct work_struct *work)
{
struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
struct kvm *kvm = irqfd->kvm;
+ if (kvm == KVM_BAD_PTR) {
+ printk(KERN_ERR "Eventfd bug detected!\n");
+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p,gsi=%d)\n",
__func__,
+ work, irqfd, kvm, irqfd->gsi);
+ trigger_all_cpu_backtrace();
+ return;
+ }
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
@@ -75,6 +85,8 @@ irqfd_shutdown(struct work_struct *work)
struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown);
u64 cnt;
+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ work, irqfd, irqfd->kvm, irqfd->gsi);
/*
* Synchronize with the wait-queue and unhook ourselves to prevent
* further events.
@@ -91,6 +103,8 @@ irqfd_shutdown(struct work_struct *work)
* It is now safe to release the object's resources
*/
eventfd_ctx_put(irqfd->eventfd);
+ printk(KERN_ERR "kfree at %s(work=%p,irqfd=%p)\n", __func__,
+ work, irqfd);
kfree(irqfd);
}
@@ -111,6 +125,8 @@ static void
irqfd_deactivate(struct _irqfd *irqfd)
{
BUG_ON(!irqfd_is_active(irqfd));
+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ irqfd, irqfd->kvm, irqfd->gsi);
list_del_init(&irqfd->list);
@@ -178,6 +194,8 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
irqfd->kvm = kvm;
irqfd->gsi = gsi;
+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ irqfd, kvm, gsi);
INIT_LIST_HEAD(&irqfd->list);
INIT_WORK(&irqfd->inject, irqfd_inject);
INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
@@ -264,6 +282,8 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
struct _irqfd *irqfd, *tmp;
struct eventfd_ctx *eventfd;
+ printk(KERN_ERR "%s(kvm=%p, gsi=%d)\n", __func__,
+ kvm, gsi);
eventfd = eventfd_ctx_fdget(fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
@@ -305,6 +325,7 @@ void
kvm_irqfd_release(struct kvm *kvm)
{
struct _irqfd *irqfd, *tmp;
+ printk(KERN_ERR "%s(kvm=%p)\n", __func__, kvm);
spin_lock_irq(&kvm->irqfds.lock);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I boot the host with the patched kernel yesterday.
No crach until now, but two "Eventfd bug detected!" in the log at
"Mar 9 02:04:31" and "Mar 9 02:15:17"
You can find part of the log at the following adress:
http://filex.univ-nantes.fr/get?k=jL4Fe7yfSMN57toAH7V
It a split file of the kern.log (1,4G), so if you need another part
of the log, let me know.
Thanks for all.
Regards.
Downloading, it's big :)
What about some 1000 lines before and after Eventfd bug detected! line?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Yes, sorry about that.
I could have split my log into a smaller file.
I was a little afraid of not transmit enough informations, and i was a
bit wide.
I hope you can find usefull trace anyway.
Regards.
--
Jean-Philippe Menil - Pôle réseau Service IRTS
DSI Université de Nantes
jean-philippe.me...@univ-nantes.fr
Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09
--
Re: Bug inkvm_set_irq
On Wed, Mar 09, 2011 at 01:28:43PM +0100, Jean-Philippe Menil wrote:
> Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
> >On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
> >>Yes, it's a 2.6.37.2 kernel.
> >OK, here's a debugging patch.
> >Please run with slab debugging as previously until you see
> >'eventfd bug detected!' in dmesg or until there is a crash.
> >It might be also useful to enable timestampts on printk with
> > Symbol: PRINTK_TIME [=y]
> > │ Type : boolean
> > │ Prompt: Show timing information on printks
> >
> >once you see the error, please upload the
> >full dmesg output somewhere to we can track what
> >goes on.
> >
> >Hopefully there won't be an oops this time which
> >should make it easier for you to test (no need to
> >reboot).
> >
> >
> >diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> >index c1f1e3c..3cb679b 100644
> >--- a/virt/kvm/eventfd.c
> >+++ b/virt/kvm/eventfd.c
> >@@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> >+#include
> >
> > #include "iodev.h"
> >
> >@@ -43,6 +44,8 @@
> > *
> > */
> >
> >+#define KVM_BAD_PTR ((void*)(long)(0x6b6b6b6b6b6b6b6bull))
> >+
> > struct _irqfd {
> > struct kvm *kvm;
> > struct eventfd_ctx *eventfd;
> >@@ -61,6 +64,13 @@ irqfd_inject(struct work_struct *work)
> > {
> > struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> > struct kvm *kvm = irqfd->kvm;
> >+if (kvm == KVM_BAD_PTR) {
> >+printk(KERN_ERR "Eventfd bug detected!\n");
> >+printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p,gsi=%d)\n",
> >__func__,
> >+work, irqfd, kvm, irqfd->gsi);
> >+trigger_all_cpu_backtrace();
> >+return;
> >+}
> >
> > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
> > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
> >@@ -75,6 +85,8 @@ irqfd_shutdown(struct work_struct *work)
> > struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown);
> > u64 cnt;
> >
> >+printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
> >+ work, irqfd, irqfd->kvm, irqfd->gsi);
> > /*
> > * Synchronize with the wait-queue and unhook ourselves to prevent
> > * further events.
> >@@ -91,6 +103,8 @@ irqfd_shutdown(struct work_struct *work)
> > * It is now safe to release the object's resources
> > */
> > eventfd_ctx_put(irqfd->eventfd);
> >+printk(KERN_ERR "kfree at %s(work=%p,irqfd=%p)\n", __func__,
> >+ work, irqfd);
> > kfree(irqfd);
> > }
> >
> >@@ -111,6 +125,8 @@ static void
> > irqfd_deactivate(struct _irqfd *irqfd)
> > {
> > BUG_ON(!irqfd_is_active(irqfd));
> >+printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
> >+ irqfd, irqfd->kvm, irqfd->gsi);
> >
> > list_del_init(&irqfd->list);
> >
> >@@ -178,6 +194,8 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
> >
> > irqfd->kvm = kvm;
> > irqfd->gsi = gsi;
> >+printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
> >+ irqfd, kvm, gsi);
> > INIT_LIST_HEAD(&irqfd->list);
> > INIT_WORK(&irqfd->inject, irqfd_inject);
> > INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
> >@@ -264,6 +282,8 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
> > struct _irqfd *irqfd, *tmp;
> > struct eventfd_ctx *eventfd;
> >
> >+printk(KERN_ERR "%s(kvm=%p, gsi=%d)\n", __func__,
> >+ kvm, gsi);
> > eventfd = eventfd_ctx_fdget(fd);
> > if (IS_ERR(eventfd))
> > return PTR_ERR(eventfd);
> >@@ -305,6 +325,7 @@ void
> > kvm_irqfd_release(struct kvm *kvm)
> > {
> > struct _irqfd *irqfd, *tmp;
> >+printk(KERN_ERR "%s(kvm=%p)\n", __func__, kvm);
> >
> > spin_lock_irq(&kvm->irqfds.lock);
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majord...@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> Hi,
>
> I boot the host with the patched kernel yesterday.
> No crach until now, but two "Eventfd bug detected!" in the log at
> "Mar 9 02:04:31" and "Mar 9 02:15:17"
> You can find part of the log at the following adress:
> http://filex.univ-nantes.fr/get?k=jL4Fe7yfSMN57toAH7V
>
> It a split file of the kern.log (1,4G), so if you need another part
> of the log, let me know.
>
> Thanks for all.
>
> Regards.
Downloading, it's big :)
What about some 1000 lines before and after Eventfd bug detected! line?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
Yes, it's a 2.6.37.2 kernel.
OK, here's a debugging patch.
Please run with slab debugging as previously until you see
'eventfd bug detected!' in dmesg or until there is a crash.
It might be also useful to enable timestampts on printk with
Symbol: PRINTK_TIME [=y]
│ Type : boolean
│ Prompt: Show timing information on printks
once you see the error, please upload the
full dmesg output somewhere to we can track what
goes on.
Hopefully there won't be an oops this time which
should make it easier for you to test (no need to
reboot).
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index c1f1e3c..3cb679b 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "iodev.h"
@@ -43,6 +44,8 @@
*
*/
+#define KVM_BAD_PTR ((void*)(long)(0x6b6b6b6b6b6b6b6bull))
+
struct _irqfd {
struct kvm *kvm;
struct eventfd_ctx *eventfd;
@@ -61,6 +64,13 @@ irqfd_inject(struct work_struct *work)
{
struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
struct kvm *kvm = irqfd->kvm;
+ if (kvm == KVM_BAD_PTR) {
+ printk(KERN_ERR "Eventfd bug detected!\n");
+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p,gsi=%d)\n",
__func__,
+ work, irqfd, kvm, irqfd->gsi);
+ trigger_all_cpu_backtrace();
+ return;
+ }
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
@@ -75,6 +85,8 @@ irqfd_shutdown(struct work_struct *work)
struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown);
u64 cnt;
+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ work, irqfd, irqfd->kvm, irqfd->gsi);
/*
* Synchronize with the wait-queue and unhook ourselves to prevent
* further events.
@@ -91,6 +103,8 @@ irqfd_shutdown(struct work_struct *work)
* It is now safe to release the object's resources
*/
eventfd_ctx_put(irqfd->eventfd);
+ printk(KERN_ERR "kfree at %s(work=%p,irqfd=%p)\n", __func__,
+ work, irqfd);
kfree(irqfd);
}
@@ -111,6 +125,8 @@ static void
irqfd_deactivate(struct _irqfd *irqfd)
{
BUG_ON(!irqfd_is_active(irqfd));
+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ irqfd, irqfd->kvm, irqfd->gsi);
list_del_init(&irqfd->list);
@@ -178,6 +194,8 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
irqfd->kvm = kvm;
irqfd->gsi = gsi;
+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ irqfd, kvm, gsi);
INIT_LIST_HEAD(&irqfd->list);
INIT_WORK(&irqfd->inject, irqfd_inject);
INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
@@ -264,6 +282,8 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
struct _irqfd *irqfd, *tmp;
struct eventfd_ctx *eventfd;
+ printk(KERN_ERR "%s(kvm=%p, gsi=%d)\n", __func__,
+ kvm, gsi);
eventfd = eventfd_ctx_fdget(fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
@@ -305,6 +325,7 @@ void
kvm_irqfd_release(struct kvm *kvm)
{
struct _irqfd *irqfd, *tmp;
+ printk(KERN_ERR "%s(kvm=%p)\n", __func__, kvm);
spin_lock_irq(&kvm->irqfds.lock);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I boot the host with the patched kernel yesterday.
No crach until now, but two "Eventfd bug detected!" in the log at "Mar
9 02:04:31" and "Mar 9 02:15:17"
You can find part of the log at the following adress:
http://filex.univ-nantes.fr/get?k=jL4Fe7yfSMN57toAH7V
It a split file of the kern.log (1,4G), so if you need another part of
the log, let me know.
Thanks for all.
Regards.
--
Jean-Philippe Menil - Pôle réseau Service IRTS
DSI Université de Nantes
jean-philippe.me...@univ-nantes.fr
Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
> Yes, it's a 2.6.37.2 kernel.
OK, here's a debugging patch.
Please run with slab debugging as previously until you see
'eventfd bug detected!' in dmesg or until there is a crash.
It might be also useful to enable timestampts on printk with
Symbol: PRINTK_TIME [=y]
│ Type : boolean
│ Prompt: Show timing information on printks
once you see the error, please upload the
full dmesg output somewhere to we can track what
goes on.
Hopefully there won't be an oops this time which
should make it easier for you to test (no need to
reboot).
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index c1f1e3c..3cb679b 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "iodev.h"
@@ -43,6 +44,8 @@
*
*/
+#define KVM_BAD_PTR ((void*)(long)(0x6b6b6b6b6b6b6b6bull))
+
struct _irqfd {
struct kvm *kvm;
struct eventfd_ctx *eventfd;
@@ -61,6 +64,13 @@ irqfd_inject(struct work_struct *work)
{
struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
struct kvm *kvm = irqfd->kvm;
+ if (kvm == KVM_BAD_PTR) {
+ printk(KERN_ERR "Eventfd bug detected!\n");
+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p,gsi=%d)\n",
__func__,
+ work, irqfd, kvm, irqfd->gsi);
+ trigger_all_cpu_backtrace();
+ return;
+ }
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
@@ -75,6 +85,8 @@ irqfd_shutdown(struct work_struct *work)
struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown);
u64 cnt;
+ printk(KERN_ERR "%s(work=%p,irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ work, irqfd, irqfd->kvm, irqfd->gsi);
/*
* Synchronize with the wait-queue and unhook ourselves to prevent
* further events.
@@ -91,6 +103,8 @@ irqfd_shutdown(struct work_struct *work)
* It is now safe to release the object's resources
*/
eventfd_ctx_put(irqfd->eventfd);
+ printk(KERN_ERR "kfree at %s(work=%p,irqfd=%p)\n", __func__,
+ work, irqfd);
kfree(irqfd);
}
@@ -111,6 +125,8 @@ static void
irqfd_deactivate(struct _irqfd *irqfd)
{
BUG_ON(!irqfd_is_active(irqfd));
+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ irqfd, irqfd->kvm, irqfd->gsi);
list_del_init(&irqfd->list);
@@ -178,6 +194,8 @@ kvm_irqfd_assign(struct kvm *kvm, int fd, int gsi)
irqfd->kvm = kvm;
irqfd->gsi = gsi;
+ printk(KERN_ERR "%s(irqfd=%p,kvm=%p, gsi=%d)\n", __func__,
+ irqfd, kvm, gsi);
INIT_LIST_HEAD(&irqfd->list);
INIT_WORK(&irqfd->inject, irqfd_inject);
INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
@@ -264,6 +282,8 @@ kvm_irqfd_deassign(struct kvm *kvm, int fd, int gsi)
struct _irqfd *irqfd, *tmp;
struct eventfd_ctx *eventfd;
+ printk(KERN_ERR "%s(kvm=%p, gsi=%d)\n", __func__,
+ kvm, gsi);
eventfd = eventfd_ctx_fdget(fd);
if (IS_ERR(eventfd))
return PTR_ERR(eventfd);
@@ -305,6 +325,7 @@ void
kvm_irqfd_release(struct kvm *kvm)
{
struct _irqfd *irqfd, *tmp;
+ printk(KERN_ERR "%s(kvm=%p)\n", __func__, kvm);
spin_lock_irq(&kvm->irqfds.lock);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
Le 04/03/2011 10:35, Michael S. Tsirkin a écrit : On Fri, Mar 04, 2011 at 10:22:03AM +0100, Jean-Philippe Menil wrote: Le 03/03/2011 16:55, Michael S. Tsirkin a écrit : On Thu, Mar 03, 2011 at 04:26:11PM +0100, Jean-Philippe Menil wrote: Le 03/03/2011 15:47, Michael S. Tsirkin a écrit : On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote: so this time the bug is: [17882.612303] BUG: unable to handle kernel paging request at 2458 [17882.612342] IP: [] kvm_set_irq+0x30/0x140 [kvm] markup_oops give me this: root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2-dsiun-110105+ vmaoffset = 18446744072102621184 a0389871: 48 89 e5mov %rsp,%rbp a0389874: 41 57 push %r15 a0389876: 41 89 cfmov%ecx,%r15d | %r15 =>1 %ecx = 1 a0389879: 41 56 push %r14| %r14 =>a038aad0 a038987b: 41 55 push %r13 a038987d: 49 89 fdmov%rdi,%r13 | %edi = 0 %r13 =>0 a0389880: 41 54 push %r12| %r12 => 0 a0389882: 53 push %rbx a0389883: 89 d3 mov%edx,%ebx | %ebx => 1a a0389885: 48 81 ec a8 00 00 00sub$0xa8,%rsp a038988c: 8b 15 00 00 00 00 mov0x0(%rip),%edx # a0389892 a0389892: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | %esi = 0 a0389898: 85 d2 test %edx,%edx | %edx => 0 a038989a: 0f 85 d5 00 00 00 jnea0389975 *a03898a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax | %eax = 0 %r13 = 0<--- faulting instruction a03898a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx a03898ad: 73 61 jaea0389910 a03898af: 89 db mov%ebx,%ebx a03898b1: 48 8b 84 d8 30 01 00mov0x130(%rax,%rbx,8),%rax a03898b8: 00 a03898b9: 48 85 c0test %rax,%rax a03898bc: 74 52 je a0389910 a03898be: 48 8d 95 40 ff ff fflea-0xc0(%rbp),%rdx a03898c5: 31 db xor%ebx,%ebx a03898c7: 48 8b 08mov(%rax),%rcx a03898ca: 83 c3 01add$0x1,%ebx a03898cd: 0f 18 09prefetcht0 (%rcx) a03898d0: 48 8b 48 e0 mov-0x20(%rax),%rcx a03898d4: 48 89 0amov%rcx,(%rdx) a03898d7: 48 8b 48 e8 mov-0x18(%rax),%rcx a03898db: 48 89 4a 08 mov%rcx,0x8(%rdx) a03898df: 48 8b 48 f0 mov-0x10(%rax),%rcx a03898e3: 48 89 4a 10 mov%rcx,0x10(%rdx) a03898e7: 48 8b 48 f8 mov-0x8(%rax),%rcx a03898eb: 48 89 4a 18 mov%rcx,0x18(%rdx) wich correspond to offset 68a0 (from objdump): kvm_set_irq(): /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 68a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162 68a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx root@ayrshire:~# addr2line -e /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko 0x68a0 /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 So here kvm->irq_routing is null. How can it be? Regards. Not null, this seems to be invalid. I suspect use after free where the kvm pointer is pointing at some random memory. Use after free? Could you please try enabling a slab debugger, recompile and rerun the test? Hi, I'm not sure to activate the right thing. Is that what you want? CONFIG_SLAB=y CONFIG_SLABINFO=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y Regards. Yes, maybe disable SLAB_LEAK. -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.me...@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, so this time, here is what markup_oops says: root@ayrshire:~# cat oops-0403.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2.999-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2.999-dsiun-110105+ vmaoffset = 18446744072102948864 a03d9811:48 89 e5 mov%rsp,%rbp a03d9814:41 57push %r15 a0
Re: Bug inkvm_set_irq
On Fri, Mar 04, 2011 at 10:22:03AM +0100, Jean-Philippe Menil wrote: > Le 03/03/2011 16:55, Michael S. Tsirkin a écrit : > >On Thu, Mar 03, 2011 at 04:26:11PM +0100, Jean-Philippe Menil wrote: > >>Le 03/03/2011 15:47, Michael S. Tsirkin a écrit : > >>>On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote: > so this time the bug is: > > [17882.612303] BUG: unable to handle kernel paging request at > 2458 > [17882.612342] IP: [] kvm_set_irq+0x30/0x140 [kvm] > > markup_oops give me this: > > root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m > /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > /boot/vmlinuz-2.6.37.2-dsiun-110105+ > vmaoffset = 18446744072102621184 a0389871:48 89 e5 > mov > %rsp,%rbp > a0389874: 41 57 push %r15 > a0389876: 41 89 cfmov%ecx,%r15d | > %r15 > => 1 %ecx = 1 > a0389879: 41 56 push %r14| > %r14 > => a038aad0 > a038987b: 41 55 push %r13 > a038987d: 49 89 fdmov%rdi,%r13 | > %edi > = 0 %r13 => 0 > a0389880: 41 54 push %r12| > %r12 => 0 > a0389882: 53 push %rbx > a0389883: 89 d3 mov%edx,%ebx | > %ebx => 1a > a0389885: 48 81 ec a8 00 00 00sub$0xa8,%rsp > a038988c: 8b 15 00 00 00 00 mov0x0(%rip),%edx > # a0389892 > a0389892: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) > | > %esi = 0 > a0389898: 85 d2 test %edx,%edx | > %edx => 0 > a038989a: 0f 85 d5 00 00 00 jnea0389975 > > *a03898a0:49 8b 85 58 24 00 00mov > 0x2458(%r13),%rax | > %eax = 0 %r13 = 0<--- faulting instruction > a03898a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx > a03898ad: 73 61 jaea0389910 > > a03898af: 89 db mov%ebx,%ebx > a03898b1: 48 8b 84 d8 30 01 00mov > 0x130(%rax,%rbx,8),%rax > a03898b8: 00 > a03898b9: 48 85 c0test %rax,%rax > a03898bc: 74 52 je a0389910 > > a03898be: 48 8d 95 40 ff ff fflea-0xc0(%rbp),%rdx > a03898c5: 31 db xor%ebx,%ebx > a03898c7: 48 8b 08mov(%rax),%rcx > a03898ca: 83 c3 01add$0x1,%ebx > a03898cd: 0f 18 09prefetcht0 (%rcx) > a03898d0: 48 8b 48 e0 mov-0x20(%rax),%rcx > a03898d4: 48 89 0amov%rcx,(%rdx) > a03898d7: 48 8b 48 e8 mov-0x18(%rax),%rcx > a03898db: 48 89 4a 08 mov%rcx,0x8(%rdx) > a03898df: 48 8b 48 f0 mov-0x10(%rax),%rcx > a03898e3: 48 89 4a 10 mov%rcx,0x10(%rdx) > a03898e7: 48 8b 48 f8 mov-0x8(%rax),%rcx > a03898eb: 48 89 4a 18 mov%rcx,0x18(%rdx) > > wich correspond to offset 68a0 (from objdump): > > kvm_set_irq(): > /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 > 68a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax > /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162 > 68a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx > > root@ayrshire:~# addr2line -e > /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > 0x68a0 > /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 > > So here kvm->irq_routing is null. > > How can it be? > > Regards. > >>>Not null, this seems to be invalid. > >>>I suspect use after free where the kvm pointer is > >>>pointing at some random memory. Use after free? > >>>Could you please try enabling a slab debugger, > >>>recompile and rerun the test? > >>> > >>Hi, > >> > >>I'm not sure to activate the right thing. > >>Is that what you want? > >> > >>CONFIG_SLAB=y > >>CONFIG_SLABINFO=y > >>CONFIG_DEBUG_SLAB=y > >>CONFIG_DEBUG_SLAB_LEAK=y > >> > >>Regards. > >Yes, maybe disable SLAB_LEAK. > > > >>-- > >>Jean-Philippe Menil - Pôle réseau Service IRTS > >>DSI Université de Nantes > >>
Re: Bug inkvm_set_irq
Le 03/03/2011 16:55, Michael S. Tsirkin a écrit : On Thu, Mar 03, 2011 at 04:26:11PM +0100, Jean-Philippe Menil wrote: Le 03/03/2011 15:47, Michael S. Tsirkin a écrit : On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote: so this time the bug is: [17882.612303] BUG: unable to handle kernel paging request at 2458 [17882.612342] IP: [] kvm_set_irq+0x30/0x140 [kvm] markup_oops give me this: root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2-dsiun-110105+ vmaoffset = 18446744072102621184 a0389871: 48 89 e5mov %rsp,%rbp a0389874: 41 57 push %r15 a0389876: 41 89 cfmov%ecx,%r15d | %r15 => 1 %ecx = 1 a0389879: 41 56 push %r14| %r14 => a038aad0 a038987b: 41 55 push %r13 a038987d: 49 89 fdmov%rdi,%r13 | %edi = 0 %r13 => 0 a0389880: 41 54 push %r12| %r12 => 0 a0389882: 53 push %rbx a0389883: 89 d3 mov%edx,%ebx | %ebx => 1a a0389885: 48 81 ec a8 00 00 00sub$0xa8,%rsp a038988c: 8b 15 00 00 00 00 mov0x0(%rip),%edx # a0389892 a0389892: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | %esi = 0 a0389898: 85 d2 test %edx,%edx | %edx => 0 a038989a: 0f 85 d5 00 00 00 jnea0389975 *a03898a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax | %eax = 0 %r13 = 0<--- faulting instruction a03898a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx a03898ad: 73 61 jaea0389910 a03898af: 89 db mov%ebx,%ebx a03898b1: 48 8b 84 d8 30 01 00mov0x130(%rax,%rbx,8),%rax a03898b8: 00 a03898b9: 48 85 c0test %rax,%rax a03898bc: 74 52 je a0389910 a03898be: 48 8d 95 40 ff ff fflea-0xc0(%rbp),%rdx a03898c5: 31 db xor%ebx,%ebx a03898c7: 48 8b 08mov(%rax),%rcx a03898ca: 83 c3 01add$0x1,%ebx a03898cd: 0f 18 09prefetcht0 (%rcx) a03898d0: 48 8b 48 e0 mov-0x20(%rax),%rcx a03898d4: 48 89 0amov%rcx,(%rdx) a03898d7: 48 8b 48 e8 mov-0x18(%rax),%rcx a03898db: 48 89 4a 08 mov%rcx,0x8(%rdx) a03898df: 48 8b 48 f0 mov-0x10(%rax),%rcx a03898e3: 48 89 4a 10 mov%rcx,0x10(%rdx) a03898e7: 48 8b 48 f8 mov-0x8(%rax),%rcx a03898eb: 48 89 4a 18 mov%rcx,0x18(%rdx) wich correspond to offset 68a0 (from objdump): kvm_set_irq(): /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 68a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162 68a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx root@ayrshire:~# addr2line -e /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko 0x68a0 /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 So here kvm->irq_routing is null. How can it be? Regards. Not null, this seems to be invalid. I suspect use after free where the kvm pointer is pointing at some random memory. Use after free? Could you please try enabling a slab debugger, recompile and rerun the test? Hi, I'm not sure to activate the right thing. Is that what you want? CONFIG_SLAB=y CONFIG_SLABINFO=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y Regards. Yes, maybe disable SLAB_LEAK. -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.me...@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, so this time, here is what markup_oops says: root@ayrshire:~# cat oops-0403.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2.999-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2.999-dsiun-110105+ vmaoffset = 18446744072102948864 a03d9811:48 89 e5 mov%rsp,%rbp a03d9814:41 57push %r15 a03d9816:41 89 cf mov%ecx,%r15d | %r15 => 1 %ecx = 1 a03d9819:41 56
Re: Bug inkvm_set_irq
On Thu, Mar 03, 2011 at 04:26:11PM +0100, Jean-Philippe Menil wrote: > Le 03/03/2011 15:47, Michael S. Tsirkin a écrit : > >On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote: > >>so this time the bug is: > >> > >>[17882.612303] BUG: unable to handle kernel paging request at > >>2458 > >>[17882.612342] IP: [] kvm_set_irq+0x30/0x140 [kvm] > >> > >>markup_oops give me this: > >> > >>root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m > >>/lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > >>/boot/vmlinuz-2.6.37.2-dsiun-110105+ > >>vmaoffset = 18446744072102621184 a0389871: 48 89 e5mov > >>%rsp,%rbp > >> a0389874: 41 57 push %r15 > >> a0389876: 41 89 cfmov%ecx,%r15d | %r15 > >>=> 1 %ecx = 1 > >> a0389879: 41 56 push %r14| %r14 > >>=> a038aad0 > >> a038987b: 41 55 push %r13 > >> a038987d: 49 89 fdmov%rdi,%r13 | %edi > >>= 0 %r13 => 0 > >> a0389880: 41 54 push %r12| %r12 => 0 > >> a0389882: 53 push %rbx > >> a0389883: 89 d3 mov%edx,%ebx | %ebx => > >> 1a > >> a0389885: 48 81 ec a8 00 00 00sub$0xa8,%rsp > >> a038988c: 8b 15 00 00 00 00 mov0x0(%rip),%edx > >># a0389892 > >> a0389892: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | > >>%esi = 0 > >> a0389898: 85 d2 test %edx,%edx | %edx => 0 > >> a038989a: 0f 85 d5 00 00 00 jnea0389975 > >> > >>*a03898a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax | > >>%eax = 0 %r13 = 0<--- faulting instruction > >> a03898a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx > >> a03898ad: 73 61 jaea0389910 > >> > >> a03898af: 89 db mov%ebx,%ebx > >> a03898b1: 48 8b 84 d8 30 01 00mov0x130(%rax,%rbx,8),%rax > >> a03898b8: 00 > >> a03898b9: 48 85 c0test %rax,%rax > >> a03898bc: 74 52 je a0389910 > >> > >> a03898be: 48 8d 95 40 ff ff fflea-0xc0(%rbp),%rdx > >> a03898c5: 31 db xor%ebx,%ebx > >> a03898c7: 48 8b 08mov(%rax),%rcx > >> a03898ca: 83 c3 01add$0x1,%ebx > >> a03898cd: 0f 18 09prefetcht0 (%rcx) > >> a03898d0: 48 8b 48 e0 mov-0x20(%rax),%rcx > >> a03898d4: 48 89 0amov%rcx,(%rdx) > >> a03898d7: 48 8b 48 e8 mov-0x18(%rax),%rcx > >> a03898db: 48 89 4a 08 mov%rcx,0x8(%rdx) > >> a03898df: 48 8b 48 f0 mov-0x10(%rax),%rcx > >> a03898e3: 48 89 4a 10 mov%rcx,0x10(%rdx) > >> a03898e7: 48 8b 48 f8 mov-0x8(%rax),%rcx > >> a03898eb: 48 89 4a 18 mov%rcx,0x18(%rdx) > >> > >>wich correspond to offset 68a0 (from objdump): > >> > >>kvm_set_irq(): > >>/usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 > >> 68a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax > >>/usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162 > >> 68a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx > >> > >>root@ayrshire:~# addr2line -e > >>/lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > >>0x68a0 > >>/usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 > >> > >>So here kvm->irq_routing is null. > >> > >>How can it be? > >> > >>Regards. > >Not null, this seems to be invalid. > >I suspect use after free where the kvm pointer is > >pointing at some random memory. Use after free? > >Could you please try enabling a slab debugger, > >recompile and rerun the test? > > > Hi, > > I'm not sure to activate the right thing. > Is that what you want? > > CONFIG_SLAB=y > CONFIG_SLABINFO=y > CONFIG_DEBUG_SLAB=y > CONFIG_DEBUG_SLAB_LEAK=y > > Regards. Yes, maybe disable SLAB_LEAK. > -- > Jean-Philippe Menil - Pôle réseau Service IRTS > DSI Université de Nantes > jean-philippe.me...@univ-nantes.fr > Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
Le 03/03/2011 15:47, Michael S. Tsirkin a écrit : On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote: so this time the bug is: [17882.612303] BUG: unable to handle kernel paging request at 2458 [17882.612342] IP: [] kvm_set_irq+0x30/0x140 [kvm] markup_oops give me this: root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2-dsiun-110105+ vmaoffset = 18446744072102621184 a0389871: 48 89 e5mov %rsp,%rbp a0389874: 41 57 push %r15 a0389876: 41 89 cfmov%ecx,%r15d | %r15 => 1 %ecx = 1 a0389879: 41 56 push %r14| %r14 => a038aad0 a038987b: 41 55 push %r13 a038987d: 49 89 fdmov%rdi,%r13 | %edi = 0 %r13 => 0 a0389880: 41 54 push %r12| %r12 => 0 a0389882: 53 push %rbx a0389883: 89 d3 mov%edx,%ebx | %ebx => 1a a0389885: 48 81 ec a8 00 00 00sub$0xa8,%rsp a038988c: 8b 15 00 00 00 00 mov0x0(%rip),%edx # a0389892 a0389892: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | %esi = 0 a0389898: 85 d2 test %edx,%edx | %edx => 0 a038989a: 0f 85 d5 00 00 00 jnea0389975 *a03898a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax | %eax = 0 %r13 = 0<--- faulting instruction a03898a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx a03898ad: 73 61 jaea0389910 a03898af: 89 db mov%ebx,%ebx a03898b1: 48 8b 84 d8 30 01 00mov0x130(%rax,%rbx,8),%rax a03898b8: 00 a03898b9: 48 85 c0test %rax,%rax a03898bc: 74 52 je a0389910 a03898be: 48 8d 95 40 ff ff fflea-0xc0(%rbp),%rdx a03898c5: 31 db xor%ebx,%ebx a03898c7: 48 8b 08mov(%rax),%rcx a03898ca: 83 c3 01add$0x1,%ebx a03898cd: 0f 18 09prefetcht0 (%rcx) a03898d0: 48 8b 48 e0 mov-0x20(%rax),%rcx a03898d4: 48 89 0amov%rcx,(%rdx) a03898d7: 48 8b 48 e8 mov-0x18(%rax),%rcx a03898db: 48 89 4a 08 mov%rcx,0x8(%rdx) a03898df: 48 8b 48 f0 mov-0x10(%rax),%rcx a03898e3: 48 89 4a 10 mov%rcx,0x10(%rdx) a03898e7: 48 8b 48 f8 mov-0x8(%rax),%rcx a03898eb: 48 89 4a 18 mov%rcx,0x18(%rdx) wich correspond to offset 68a0 (from objdump): kvm_set_irq(): /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 68a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162 68a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx root@ayrshire:~# addr2line -e /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko 0x68a0 /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 So here kvm->irq_routing is null. How can it be? Regards. Not null, this seems to be invalid. I suspect use after free where the kvm pointer is pointing at some random memory. Use after free? Could you please try enabling a slab debugger, recompile and rerun the test? Hi, I'm not sure to activate the right thing. Is that what you want? CONFIG_SLAB=y CONFIG_SLABINFO=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y Regards. -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.me...@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote: > so this time the bug is: > > [17882.612303] BUG: unable to handle kernel paging request at > 2458 > [17882.612342] IP: [] kvm_set_irq+0x30/0x140 [kvm] > > markup_oops give me this: > > root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m > /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > /boot/vmlinuz-2.6.37.2-dsiun-110105+ > vmaoffset = 18446744072102621184 a0389871:48 89 e5mov > %rsp,%rbp > a0389874:41 57 push %r15 > a0389876:41 89 cfmov%ecx,%r15d | %r15 > => 1 %ecx = 1 > a0389879:41 56 push %r14| %r14 > => a038aad0 > a038987b:41 55 push %r13 > a038987d:49 89 fdmov%rdi,%r13 | %edi > = 0 %r13 => 0 > a0389880:41 54 push %r12| %r12 => 0 > a0389882:53 push %rbx > a0389883:89 d3 mov%edx,%ebx | %ebx => 1a > a0389885:48 81 ec a8 00 00 00sub$0xa8,%rsp > a038988c:8b 15 00 00 00 00 mov0x0(%rip),%edx > # a0389892 > a0389892:89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | > %esi = 0 > a0389898:85 d2 test %edx,%edx | %edx => 0 > a038989a:0f 85 d5 00 00 00 jnea0389975 > > *a03898a0:49 8b 85 58 24 00 00mov0x2458(%r13),%rax | > %eax = 0 %r13 = 0 <--- faulting instruction > a03898a7:3b 98 28 01 00 00 cmp0x128(%rax),%ebx > a03898ad:73 61 jaea0389910 > > a03898af:89 db mov%ebx,%ebx > a03898b1:48 8b 84 d8 30 01 00mov0x130(%rax,%rbx,8),%rax > a03898b8:00 > a03898b9:48 85 c0test %rax,%rax > a03898bc:74 52 je a0389910 > > a03898be:48 8d 95 40 ff ff fflea-0xc0(%rbp),%rdx > a03898c5:31 db xor%ebx,%ebx > a03898c7:48 8b 08mov(%rax),%rcx > a03898ca:83 c3 01add$0x1,%ebx > a03898cd:0f 18 09prefetcht0 (%rcx) > a03898d0:48 8b 48 e0 mov-0x20(%rax),%rcx > a03898d4:48 89 0amov%rcx,(%rdx) > a03898d7:48 8b 48 e8 mov-0x18(%rax),%rcx > a03898db:48 89 4a 08 mov%rcx,0x8(%rdx) > a03898df:48 8b 48 f0 mov-0x10(%rax),%rcx > a03898e3:48 89 4a 10 mov%rcx,0x10(%rdx) > a03898e7:48 8b 48 f8 mov-0x8(%rax),%rcx > a03898eb:48 89 4a 18 mov%rcx,0x18(%rdx) > > wich correspond to offset 68a0 (from objdump): > > kvm_set_irq(): > /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 > 68a0: 49 8b 85 58 24 00 00mov0x2458(%r13),%rax > /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162 > 68a7: 3b 98 28 01 00 00 cmp0x128(%rax),%ebx > > root@ayrshire:~# addr2line -e > /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > 0x68a0 > /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161 > > So here kvm->irq_routing is null. > > How can it be? > > Regards. Not null, this seems to be invalid. I suspect use after free where the kvm pointer is pointing at some random memory. Use after free? Could you please try enabling a slab debugger, recompile and rerun the test? -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug inkvm_set_irq
Le 01/03/2011 08:03, Michael S. Tsirkin a écrit : On Mon, Feb 28, 2011 at 11:34:16PM +0100, Jean-Philippe Menil wrote: Hi, here is another trace with kvm.ko compiled with debug flags. the bug: [12099.503414] BUG: unable to handle kernel paging request at 0b6635e9 [12099.503462] IP: [] kvm_set_irq+0x37/0x140 [kvm] [12099.503521] PGD 45d8d2067 PUD 45d58e067 PMD 0 [12099.503560] Oops: [#1] SMP [12099.503591] last sysfs file: /sys/devices/system/cpu/cpu11/cache/index2/shared_cpu_map [12099.503641] CPU 0 [12099.503648] Modules linked in: netconsole configfs vhost_net macvtap macvlan tun veth powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug tpm_tis i2c_nforce2 tpm i2c_core pcspkr evdev psmouse joydev tpm_bios processor ghes dcdbas hed button serio_raw thermal_sys xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses sd_mod enclosure megaraid_sas ohci_hcd lpfc scsi_transport_fc bnx2 scsi_tgt scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] [12099.504277] [12099.504302] Pid: 1742, comm: kworker/0:2 Not tainted 2.6.37.2-dsiun-110105+ #2 Dell Inc. PowerEdge M605/0K543T [12099.504373] RIP: 0010:[] [] kvm_set_irq+0x37/0x140 [kvm] [12099.50] RSP: 0018:88045e013d00 EFLAGS: 00010246 [12099.504474] RAX: 0b6634c1 RBX: 0018 RCX: 0001 [12099.504508] RDX: RSI: RDI: 880419b600c0 [12099.504541] RBP: 88045e013dd0 R08: 88045e012000 R09: [12099.504575] R10: R11: R12: 880419b600c0 [12099.504609] R13: 880419b600c0 R14: a03efaa0 R15: 0001 [12099.504643] FS: 7f3abaa05710() GS:88007f80() knlGS: [12099.504693] CS: 0010 DS: ES: CR0: 8005003b [12099.504724] CR2: 0b6635e9 CR3: 00045e2bc000 CR4: 06f0 [12099.504757] DR0: DR1: DR2: [12099.504791] DR3: DR6: 0ff0 DR7: 0400 [12099.504825] Process kworker/0:2 (pid: 1742, threadinfo ffkvm_set_irqff88045e012000, task 88045ffb0d60) [12099.504874] Stack: [12099.504897] 000119c0 000119c0 000119c0 88045ffb0d60 [12099.504953] 88045ffb1010 88045e013fd8 88045ffb1018 88045e012010 [12099.505009] 000119c0 88045e013fd8 000119c0 000119c0 [12099.505065] Call Trace: [12099.505099] [] ? common_interrupt+0xe/0x13 [12099.505145] [] ? irqfd_inject+0x0/0x50 [kvm] [12099.505145] [] irqfd_inject+0x2a/0x50 [kvm] [12099.505145] [] process_one_work+0x11b/0x450 [12099.505145] [] worker_thread+0x157/0x410 [12099.505145] [] ? __wake_up_common+0x59/0x90 [12099.505145] [] ? worker_thread+0x0/0x410 [12099.505145] [] kthread+0x96/0xa0 [12099.505145] [] kernel_thread_helper+0x4/0x10 [12099.505145] [] ? kthread+0x0/0xa0 [12099.505145] [] ? kernel_thread_helper+0x0/0x10 [12099.505145] Code: 55 49 89 fd 41 54 53 89 d3 48 81 ec a8 00 00 00 8b 15 a6 75 03 00 89 b5 3c ff ff ff 85 d2 0f 85 d5 00 00 00 49 8b 85 58 24 00 00<3b> 98 28 01 00 00 73 61 89 db 48 8b 84 d8 30 01 00 00 48 85 c0 [12099.505145] RIP [] kvm_set_irq+0x37/0x140 [kvm] [12099.505145] RSP [12099.505145] CR2: 0b6635e9 markup_oops result: root@ayrshire:~# cat bug.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2-dsiun-110105+ vmaoffset = 18446744072103034880 a03ee841: 48 89 e5mov %rsp,%rbp a03ee844: 41 57 push %r15 a03ee846: 41 89 cfmov%ecx,%r15d | %r15 => 1 %ecx = 1 a03ee849: 41 56 push %r14| %r14 => a03efaa0 a03ee84b: 41 55 push %r13 a03ee84d: 49 89 fdmov%rdi,%r13 | %edi = 880419b600c0 %r13 => 880419b600c0 a03ee850: 41 54 push %r12| %r12 => 880419b600c0 a03ee852: 53 push %rbx a03ee853: 89 d3 mov%edx,%ebx | %ebx => 18 a03ee855: 48 81 ec a8 00 00 00sub$0xa8,%rsp a03ee85c: 8b 15 00 00 00 00 mov0x0(%rip),%edx # a03ee862 a03ee862: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | %esi = 0 a03ee868: 85 d2 test %edx,%edx | %edx => 0 a03ee86a:
Re: Bug inkvm_set_irq
On Mon, Feb 28, 2011 at 11:34:16PM +0100, Jean-Philippe Menil wrote: > Hi, > > here is another trace with kvm.ko compiled with debug flags. > > the bug: > [12099.503414] BUG: unable to handle kernel paging request at > 0b6635e9 > [12099.503462] IP: [] kvm_set_irq+0x37/0x140 [kvm] > [12099.503521] PGD 45d8d2067 PUD 45d58e067 PMD 0 > [12099.503560] Oops: [#1] SMP > [12099.503591] last sysfs file: > /sys/devices/system/cpu/cpu11/cache/index2/shared_cpu_map > [12099.503641] CPU 0 > [12099.503648] Modules linked in: netconsole configfs vhost_net > macvtap macvlan tun veth powernow_k8 mperf cpufreq_userspace > cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table > cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter > ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state > iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp > nf_conntrack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache > dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack > nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore > snd_page_alloc shpchp pci_hotplug tpm_tis i2c_nforce2 tpm i2c_core > pcspkr evdev psmouse joydev tpm_bios processor ghes dcdbas hed > button serio_raw thermal_sys xfs exportfs dm_mod sg sr_mod cdrom > usbhid hid usb_storage ses sd_mod enclosure megaraid_sas ohci_hcd > lpfc scsi_transport_fc bnx2 scsi_tgt scsi_mod ehci_hcd [last > unloaded: scsi_wait_scan] > [12099.504277] > [12099.504302] Pid: 1742, comm: kworker/0:2 Not tainted > 2.6.37.2-dsiun-110105+ #2 Dell Inc. PowerEdge M605/0K543T > [12099.504373] RIP: 0010:[] [] > kvm_set_irq+0x37/0x140 [kvm] > [12099.50] RSP: 0018:88045e013d00 EFLAGS: 00010246 > [12099.504474] RAX: 0b6634c1 RBX: 0018 RCX: > 0001 > [12099.504508] RDX: RSI: RDI: > 880419b600c0 > [12099.504541] RBP: 88045e013dd0 R08: 88045e012000 R09: > > [12099.504575] R10: R11: R12: > 880419b600c0 > [12099.504609] R13: 880419b600c0 R14: a03efaa0 R15: > 0001 > [12099.504643] FS: 7f3abaa05710() GS:88007f80() > knlGS: > [12099.504693] CS: 0010 DS: ES: CR0: 8005003b > [12099.504724] CR2: 0b6635e9 CR3: 00045e2bc000 CR4: > 06f0 > [12099.504757] DR0: DR1: DR2: > > [12099.504791] DR3: DR6: 0ff0 DR7: > 0400 > [12099.504825] Process kworker/0:2 (pid: 1742, threadinfo > ffkvm_set_irqff88045e012000, task 88045ffb0d60) > [12099.504874] Stack: > [12099.504897] 000119c0 000119c0 000119c0 > 88045ffb0d60 > [12099.504953] 88045ffb1010 88045e013fd8 88045ffb1018 > 88045e012010 > [12099.505009] 000119c0 88045e013fd8 000119c0 > 000119c0 > [12099.505065] Call Trace: > [12099.505099] [] ? common_interrupt+0xe/0x13 > [12099.505145] [] ? irqfd_inject+0x0/0x50 [kvm] > [12099.505145] [] irqfd_inject+0x2a/0x50 [kvm] > [12099.505145] [] process_one_work+0x11b/0x450 > [12099.505145] [] worker_thread+0x157/0x410 > [12099.505145] [] ? __wake_up_common+0x59/0x90 > [12099.505145] [] ? worker_thread+0x0/0x410 > [12099.505145] [] kthread+0x96/0xa0 > [12099.505145] [] kernel_thread_helper+0x4/0x10 > [12099.505145] [] ? kthread+0x0/0xa0 > [12099.505145] [] ? kernel_thread_helper+0x0/0x10 > [12099.505145] Code: 55 49 89 fd 41 54 53 89 d3 48 81 ec a8 00 00 00 > 8b 15 a6 75 03 00 89 b5 3c ff ff ff 85 d2 0f 85 d5 00 00 00 49 8b 85 > 58 24 00 00 <3b> 98 28 01 00 00 73 61 89 db 48 8b 84 d8 30 01 00 00 > 48 85 c0 > [12099.505145] RIP [] kvm_set_irq+0x37/0x140 [kvm] > [12099.505145] RSP > [12099.505145] CR2: 0b6635e9 > > > markup_oops result: > > root@ayrshire:~# cat bug.txt | perl markup_oops.pl -m > /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko > /boot/vmlinuz-2.6.37.2-dsiun-110105+ > vmaoffset = 18446744072103034880 a03ee841:48 89 e5mov > %rsp,%rbp > a03ee844:41 57 push %r15 > a03ee846:41 89 cfmov%ecx,%r15d | %r15 > => 1 %ecx = 1 > a03ee849:41 56 push %r14| %r14 > => a03efaa0 > a03ee84b:41 55 push %r13 > a03ee84d:49 89 fdmov%rdi,%r13 | %edi > = 880419b600c0 %r13 => 880419b600c0 > a03ee850:41 54 push %r12| %r12 > => 880419b600c0 > a03ee852:53 push %rbx > a03ee853:89 d3 mov%edx,%ebx | %ebx => 18 > a03ee855:48 81 ec a8 00 00 00sub$0xa8,%rsp > a03ee85c:8b 15 00 00 00 00 mov0x0(%rip),%edx > # a03ee862 > a03ee862:89 b5 3c ff ff ff mov
Re: Bug inkvm_set_irq
Hi, here is another trace with kvm.ko compiled with debug flags. the bug: [12099.503414] BUG: unable to handle kernel paging request at 0b6635e9 [12099.503462] IP: [] kvm_set_irq+0x37/0x140 [kvm] [12099.503521] PGD 45d8d2067 PUD 45d58e067 PMD 0 [12099.503560] Oops: [#1] SMP [12099.503591] last sysfs file: /sys/devices/system/cpu/cpu11/cache/index2/shared_cpu_map [12099.503641] CPU 0 [12099.503648] Modules linked in: netconsole configfs vhost_net macvtap macvlan tun veth powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug tpm_tis i2c_nforce2 tpm i2c_core pcspkr evdev psmouse joydev tpm_bios processor ghes dcdbas hed button serio_raw thermal_sys xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses sd_mod enclosure megaraid_sas ohci_hcd lpfc scsi_transport_fc bnx2 scsi_tgt scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] [12099.504277] [12099.504302] Pid: 1742, comm: kworker/0:2 Not tainted 2.6.37.2-dsiun-110105+ #2 Dell Inc. PowerEdge M605/0K543T [12099.504373] RIP: 0010:[] [] kvm_set_irq+0x37/0x140 [kvm] [12099.50] RSP: 0018:88045e013d00 EFLAGS: 00010246 [12099.504474] RAX: 0b6634c1 RBX: 0018 RCX: 0001 [12099.504508] RDX: RSI: RDI: 880419b600c0 [12099.504541] RBP: 88045e013dd0 R08: 88045e012000 R09: [12099.504575] R10: R11: R12: 880419b600c0 [12099.504609] R13: 880419b600c0 R14: a03efaa0 R15: 0001 [12099.504643] FS: 7f3abaa05710() GS:88007f80() knlGS: [12099.504693] CS: 0010 DS: ES: CR0: 8005003b [12099.504724] CR2: 0b6635e9 CR3: 00045e2bc000 CR4: 06f0 [12099.504757] DR0: DR1: DR2: [12099.504791] DR3: DR6: 0ff0 DR7: 0400 [12099.504825] Process kworker/0:2 (pid: 1742, threadinfo ffkvm_set_irqff88045e012000, task 88045ffb0d60) [12099.504874] Stack: [12099.504897] 000119c0 000119c0 000119c0 88045ffb0d60 [12099.504953] 88045ffb1010 88045e013fd8 88045ffb1018 88045e012010 [12099.505009] 000119c0 88045e013fd8 000119c0 000119c0 [12099.505065] Call Trace: [12099.505099] [] ? common_interrupt+0xe/0x13 [12099.505145] [] ? irqfd_inject+0x0/0x50 [kvm] [12099.505145] [] irqfd_inject+0x2a/0x50 [kvm] [12099.505145] [] process_one_work+0x11b/0x450 [12099.505145] [] worker_thread+0x157/0x410 [12099.505145] [] ? __wake_up_common+0x59/0x90 [12099.505145] [] ? worker_thread+0x0/0x410 [12099.505145] [] kthread+0x96/0xa0 [12099.505145] [] kernel_thread_helper+0x4/0x10 [12099.505145] [] ? kthread+0x0/0xa0 [12099.505145] [] ? kernel_thread_helper+0x0/0x10 [12099.505145] Code: 55 49 89 fd 41 54 53 89 d3 48 81 ec a8 00 00 00 8b 15 a6 75 03 00 89 b5 3c ff ff ff 85 d2 0f 85 d5 00 00 00 49 8b 85 58 24 00 00 <3b> 98 28 01 00 00 73 61 89 db 48 8b 84 d8 30 01 00 00 48 85 c0 [12099.505145] RIP [] kvm_set_irq+0x37/0x140 [kvm] [12099.505145] RSP [12099.505145] CR2: 0b6635e9 markup_oops result: root@ayrshire:~# cat bug.txt | perl markup_oops.pl -m /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko /boot/vmlinuz-2.6.37.2-dsiun-110105+ vmaoffset = 18446744072103034880 a03ee841: 48 89 e5 mov%rsp,%rbp a03ee844: 41 57 push %r15 a03ee846: 41 89 cf mov%ecx,%r15d | %r15 => 1 %ecx = 1 a03ee849: 41 56 push %r14| %r14 => a03efaa0 a03ee84b: 41 55 push %r13 a03ee84d: 49 89 fd mov%rdi,%r13 | %edi = 880419b600c0 %r13 => 880419b600c0 a03ee850: 41 54 push %r12| %r12 => 880419b600c0 a03ee852: 53 push %rbx a03ee853: 89 d3 mov%edx,%ebx | %ebx => 18 a03ee855: 48 81 ec a8 00 00 00sub$0xa8,%rsp a03ee85c: 8b 15 00 00 00 00 mov0x0(%rip),%edx# a03ee862 a03ee862: 89 b5 3c ff ff ff mov%esi,-0xc4(%rbp) | %esi = 0 a03ee868: 85 d2 test %edx,%edx | %edx => 0 a03ee86a: 0f 85 d5 00 00 00 jnea03ee945 a03ee870: 49 8b 85 58 24 00 00 mov0x2458(%r13),%rax |
Re: Bug inkvm_set_irq
Le 28/02/2011 12:39, Michael S. Tsirkin a écrit : On Mon, Feb 28, 2011 at 11:40:43AM +0100, Jean-Philippe Menil wrote: Le 28/02/2011 11:11, Michael S. Tsirkin a écrit : On Mon, Feb 28, 2011 at 09:56:46AM +0100, Jean-Philippe Menil wrote: Le 27/02/2011 18:00, Michael S. Tsirkin a écrit : On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: Hi, Each time i try tou use vhost_net, i'm facing a kernel bug. I do a "modprobe vhost_net", and start guest whith vhost=on. Following is a trace with a kernel 2.6.37, but i had the same problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). 2.6.36 had a theorectical race that could explain this, but it should be ok in 2.6.37. The bug only occurs whith vhost_net charged, so i don't know if this is a bug in kvm module code or in the vhost_net code. It could be a bug in eventfd which is the interface used by both kvm and vhost_net. Just for fun, you can try 3.6.38 - eventfd code has been changed a lot in 2.6.38 and if it does not trigger there it's a hint that irqfd is the reason. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243100] BUG: unable to handle kernel paging request at 2458 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] Could you run markup_oops/ ksymoops on this please? As far as I can see kvm_set_irq can only get a wrong kvm pointer. Unless there's some general memory corruption, I'd guess You can also try comparing the irqfd->kvm pointer in kvm_irqfd_assign irqfd_wakeup and kvm_set_irq in virt/kvm/eventfd.c. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243556] Oops: [#1] SMP Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243692] last sysfs file: /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243820] Modules linked in: vhost_net macvtap macvlan tun powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand fre q_table cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp nf_connt rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore snd_page_alloc tpm_tis tpm ps mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses sd_mod enclosu re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Pid: 10, comm: kworker/0:1 Not tainted 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RIP: 0010:[] [] kvm_set_irq+0x2a/0x130 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RAX: RBX: 001a RCX: 0001 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RDX: RSI: RDI: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RBP: R08: 0001 R09: 880856a91e48 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R10: R11: R12: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R13: 0001 R14: R15: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] FS: 7f617986c710() GS:88007f80() knlGS: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CS: 0010 DS: ES: CR0: 8005003b Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CR2: 2458 CR3: 00045d197000 CR4: 06f0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR0: DR1: DR2: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR3: DR6: 0ff0 DR7: 0400 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Process kworker/0:1 (pid: 10, threadinfo 88045fc88000, task 88085fc53c30) Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack: Fe
Re: Bug inkvm_set_irq
On Mon, Feb 28, 2011 at 11:40:43AM +0100, Jean-Philippe Menil wrote: > Le 28/02/2011 11:11, Michael S. Tsirkin a écrit : > >On Mon, Feb 28, 2011 at 09:56:46AM +0100, Jean-Philippe Menil wrote: > >>Le 27/02/2011 18:00, Michael S. Tsirkin a écrit : > >>>On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: > Hi, > > Each time i try tou use vhost_net, i'm facing a kernel bug. > I do a "modprobe vhost_net", and start guest whith vhost=on. > > Following is a trace with a kernel 2.6.37, but i had the same > problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). > >>>2.6.36 had a theorectical race that could explain this, > >>>but it should be ok in 2.6.37. > >>> > The bug only occurs whith vhost_net charged, so i don't know if this > is a bug in kvm module code or in the vhost_net code. > >>>It could be a bug in eventfd which is the interface > >>>used by both kvm and vhost_net. > >>>Just for fun, you can try 3.6.38 - eventfd code has been changed > >>>a lot in 2.6.38 and if it does not trigger there > >>>it's a hint that irqfd is the reason. > >>> > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243100] BUG: unable to handle kernel paging request at > 2458 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] > >>>Could you run markup_oops/ ksymoops on this please? > >>>As far as I can see kvm_set_irq can only get a wrong > >>>kvm pointer. Unless there's some general memory corruption, > >>>I'd guess > >>> > >>>You can also try comparing the irqfd->kvm pointer in > >>>kvm_irqfd_assign irqfd_wakeup and kvm_set_irq in > >>>virt/kvm/eventfd.c. > >>> > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243556] Oops: [#1] SMP > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243692] last sysfs file: > /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU > 0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243820] Modules linked in: vhost_net macvtap macvlan tun > powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave > cpufreq_ondemand fre > q_table cpufreq_conservative fuse xt_physdev ip6t_LOG > ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp > xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp > nf_conntrack_ftp nf_connt > rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache > dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack > nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore > snd_page_alloc tpm_tis tpm ps > mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes > serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys > xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses > sd_mod enclosu > re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 > scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] Pid: 10, comm: kworker/0:1 Not tainted > 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RIP: 0010:[] [] > kvm_set_irq+0x2a/0x130 [kvm] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RAX: RBX: 001a RCX: > 0001 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RDX: RSI: RDI: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RBP: R08: 0001 R09: > 880856a91e48 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] R10: R11: R12: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] R13: 0001 R14: R15: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] FS: 7f617986c710() GS:88007f80() > knlGS: > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] CS: 0010 DS: ES: CR0: 8005003b > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] CR2: 2458 CR3: 00045d197000 CR4: > 06f0 > Feb 23 13:56:19
Re: Bug inkvm_set_irq
Le 28/02/2011 11:11, Michael S. Tsirkin a écrit : On Mon, Feb 28, 2011 at 09:56:46AM +0100, Jean-Philippe Menil wrote: Le 27/02/2011 18:00, Michael S. Tsirkin a écrit : On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: Hi, Each time i try tou use vhost_net, i'm facing a kernel bug. I do a "modprobe vhost_net", and start guest whith vhost=on. Following is a trace with a kernel 2.6.37, but i had the same problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). 2.6.36 had a theorectical race that could explain this, but it should be ok in 2.6.37. The bug only occurs whith vhost_net charged, so i don't know if this is a bug in kvm module code or in the vhost_net code. It could be a bug in eventfd which is the interface used by both kvm and vhost_net. Just for fun, you can try 3.6.38 - eventfd code has been changed a lot in 2.6.38 and if it does not trigger there it's a hint that irqfd is the reason. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243100] BUG: unable to handle kernel paging request at 2458 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] Could you run markup_oops/ ksymoops on this please? As far as I can see kvm_set_irq can only get a wrong kvm pointer. Unless there's some general memory corruption, I'd guess You can also try comparing the irqfd->kvm pointer in kvm_irqfd_assign irqfd_wakeup and kvm_set_irq in virt/kvm/eventfd.c. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243556] Oops: [#1] SMP Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243692] last sysfs file: /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243820] Modules linked in: vhost_net macvtap macvlan tun powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand fre q_table cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp nf_connt rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore snd_page_alloc tpm_tis tpm ps mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses sd_mod enclosu re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Pid: 10, comm: kworker/0:1 Not tainted 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RIP: 0010:[] [] kvm_set_irq+0x2a/0x130 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RAX: RBX: 001a RCX: 0001 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RDX: RSI: RDI: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RBP: R08: 0001 R09: 880856a91e48 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R10: R11: R12: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R13: 0001 R14: R15: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] FS: 7f617986c710() GS:88007f80() knlGS: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CS: 0010 DS: ES: CR0: 8005003b Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CR2: 2458 CR3: 00045d197000 CR4: 06f0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR0: DR1: DR2: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR3: DR6: 0ff0 DR7: 0400 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Process kworker/0:1 (pid: 10, threadinfo 88045fc88000, task 88085fc53c30) Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] 88045fc89fd8 000119c0 88045fc88010 ff
Re: Bug inkvm_set_irq
On Mon, Feb 28, 2011 at 09:56:46AM +0100, Jean-Philippe Menil wrote: > Le 27/02/2011 18:00, Michael S. Tsirkin a écrit : > >On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: > >>Hi, > >> > >>Each time i try tou use vhost_net, i'm facing a kernel bug. > >>I do a "modprobe vhost_net", and start guest whith vhost=on. > >> > >>Following is a trace with a kernel 2.6.37, but i had the same > >>problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). > >2.6.36 had a theorectical race that could explain this, > >but it should be ok in 2.6.37. > > > >>The bug only occurs whith vhost_net charged, so i don't know if this > >>is a bug in kvm module code or in the vhost_net code. > >It could be a bug in eventfd which is the interface > >used by both kvm and vhost_net. > >Just for fun, you can try 3.6.38 - eventfd code has been changed > >a lot in 2.6.38 and if it does not trigger there > >it's a hint that irqfd is the reason. > > > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.243100] BUG: unable to handle kernel paging request at > >>2458 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] > > > >Could you run markup_oops/ ksymoops on this please? > >As far as I can see kvm_set_irq can only get a wrong > >kvm pointer. Unless there's some general memory corruption, > >I'd guess > > > >You can also try comparing the irqfd->kvm pointer in > >kvm_irqfd_assign irqfd_wakeup and kvm_set_irq in > >virt/kvm/eventfd.c. > > > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.243556] Oops: [#1] SMP > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.243692] last sysfs file: > >>/sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.243820] Modules linked in: vhost_net macvtap macvlan tun > >>powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave > >>cpufreq_ondemand fre > >>q_table cpufreq_conservative fuse xt_physdev ip6t_LOG > >>ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp > >>xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp > >>nf_conntrack_ftp nf_connt > >>rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache > >>dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack > >>nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore > >>snd_page_alloc tpm_tis tpm ps > >>mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes > >>serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys > >>xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses > >>sd_mod enclosu > >>re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 > >>scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] Pid: 10, comm: kworker/0:1 Not tainted > >>2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] RIP: 0010:[] [] > >>kvm_set_irq+0x2a/0x130 [kvm] > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] RAX: RBX: 001a RCX: > >>0001 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] RDX: RSI: RDI: > >> > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] RBP: R08: 0001 R09: > >>880856a91e48 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] R10: R11: R12: > >> > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] R13: 0001 R14: R15: > >> > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] FS: 7f617986c710() GS:88007f80() > >>knlGS: > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] CS: 0010 DS: ES: CR0: 8005003b > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] CR2: 2458 CR3: 00045d197000 CR4: > >>06f0 > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] DR0: DR1: DR2: > >> > >>Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > >>685.246123] DR3: DR6: 0ff0 DR7: > >>0400 > >>Feb 23 13:56:19 ayrshire.u06.univ
Re: Bug inkvm_set_irq
Le 27/02/2011 18:00, Michael S. Tsirkin a écrit : On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: Hi, Each time i try tou use vhost_net, i'm facing a kernel bug. I do a "modprobe vhost_net", and start guest whith vhost=on. Following is a trace with a kernel 2.6.37, but i had the same problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). 2.6.36 had a theorectical race that could explain this, but it should be ok in 2.6.37. The bug only occurs whith vhost_net charged, so i don't know if this is a bug in kvm module code or in the vhost_net code. It could be a bug in eventfd which is the interface used by both kvm and vhost_net. Just for fun, you can try 3.6.38 - eventfd code has been changed a lot in 2.6.38 and if it does not trigger there it's a hint that irqfd is the reason. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243100] BUG: unable to handle kernel paging request at 2458 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] Could you run markup_oops/ ksymoops on this please? As far as I can see kvm_set_irq can only get a wrong kvm pointer. Unless there's some general memory corruption, I'd guess You can also try comparing the irqfd->kvm pointer in kvm_irqfd_assign irqfd_wakeup and kvm_set_irq in virt/kvm/eventfd.c. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243556] Oops: [#1] SMP Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243692] last sysfs file: /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243820] Modules linked in: vhost_net macvtap macvlan tun powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand fre q_table cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp nf_connt rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore snd_page_alloc tpm_tis tpm ps mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses sd_mod enclosu re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Pid: 10, comm: kworker/0:1 Not tainted 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RIP: 0010:[] [] kvm_set_irq+0x2a/0x130 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RAX: RBX: 001a RCX: 0001 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RDX: RSI: RDI: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RBP: R08: 0001 R09: 880856a91e48 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R10: R11: R12: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R13: 0001 R14: R15: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] FS: 7f617986c710() GS:88007f80() knlGS: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CS: 0010 DS: ES: CR0: 8005003b Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CR2: 2458 CR3: 00045d197000 CR4: 06f0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR0: DR1: DR2: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR3: DR6: 0ff0 DR7: 0400 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Process kworker/0:1 (pid: 10, threadinfo 88045fc88000, task 88085fc53c30) Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] 88045fc89fd8 000119c0 88045fc88010 88085fc53ee8 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] 88045fc89fd8 88085fc53ee0 f
Re: Bug inkvm_set_irq
On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: > Hi, > > Each time i try tou use vhost_net, i'm facing a kernel bug. > I do a "modprobe vhost_net", and start guest whith vhost=on. > > Following is a trace with a kernel 2.6.37, but i had the same > problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). 2.6.36 had a theorectical race that could explain this, but it should be ok in 2.6.37. > > The bug only occurs whith vhost_net charged, so i don't know if this > is a bug in kvm module code or in the vhost_net code. It could be a bug in eventfd which is the interface used by both kvm and vhost_net. Just for fun, you can try 3.6.38 - eventfd code has been changed a lot in 2.6.38 and if it does not trigger there it's a hint that irqfd is the reason. > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243100] BUG: unable to handle kernel paging request at > 2458 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] Could you run markup_oops/ ksymoops on this please? As far as I can see kvm_set_irq can only get a wrong kvm pointer. Unless there's some general memory corruption, I'd guess You can also try comparing the irqfd->kvm pointer in kvm_irqfd_assign irqfd_wakeup and kvm_set_irq in virt/kvm/eventfd.c. > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243556] Oops: [#1] SMP > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243692] last sysfs file: > /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243820] Modules linked in: vhost_net macvtap macvlan tun > powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave > cpufreq_ondemand fre > q_table cpufreq_conservative fuse xt_physdev ip6t_LOG > ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp > xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp > nf_conntrack_ftp nf_connt > rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache > dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack > nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore > snd_page_alloc tpm_tis tpm ps > mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes > serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys > xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses > sd_mod enclosu > re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 > scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] Pid: 10, comm: kworker/0:1 Not tainted > 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RIP: 0010:[] [] > kvm_set_irq+0x2a/0x130 [kvm] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RAX: RBX: 001a RCX: > 0001 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RDX: RSI: RDI: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RBP: R08: 0001 R09: > 880856a91e48 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] R10: R11: R12: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] R13: 0001 R14: R15: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] FS: 7f617986c710() GS:88007f80() > knlGS: > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] CS: 0010 DS: ES: CR0: 8005003b > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] CR2: 2458 CR3: 00045d197000 CR4: > 06f0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] DR0: DR1: DR2: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] DR3: DR6: 0ff0 DR7: > 0400 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] Process kworker/0:1 (pid: 10, threadinfo > 88045fc88000, task 88085fc53c30) > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack: > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] 88045fc89fd8 000119c0 88045fc88010 >
Re: Bug inkvm_set_irq
CCing Michael in case he missed this. On Fri, Feb 25, 2011 at 10:07:22AM +0100, Jean-Philippe Menil wrote: > Hi, > > Each time i try tou use vhost_net, i'm facing a kernel bug. > I do a "modprobe vhost_net", and start guest whith vhost=on. > > Following is a trace with a kernel 2.6.37, but i had the same > problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). > > The bug only occurs whith vhost_net charged, so i don't know if this > is a bug in kvm module code or in the vhost_net code. > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243100] BUG: unable to handle kernel paging request at > 2458 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243556] Oops: [#1] SMP > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243692] last sysfs file: > /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.243820] Modules linked in: vhost_net macvtap macvlan tun > powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave > cpufreq_ondemand fre > q_table cpufreq_conservative fuse xt_physdev ip6t_LOG > ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp > xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp > nf_conntrack_ftp nf_connt > rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache > dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack > nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore > snd_page_alloc tpm_tis tpm ps > mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes > serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys > xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses > sd_mod enclosu > re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 > scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] Pid: 10, comm: kworker/0:1 Not tainted > 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RIP: 0010:[] [] > kvm_set_irq+0x2a/0x130 [kvm] > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RAX: RBX: 001a RCX: > 0001 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RDX: RSI: RDI: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] RBP: R08: 0001 R09: > 880856a91e48 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] R10: R11: R12: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] R13: 0001 R14: R15: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] FS: 7f617986c710() GS:88007f80() > knlGS: > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] CS: 0010 DS: ES: CR0: 8005003b > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] CR2: 2458 CR3: 00045d197000 CR4: > 06f0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] DR0: DR1: DR2: > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] DR3: DR6: 0ff0 DR7: > 0400 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] Process kworker/0:1 (pid: 10, threadinfo > 88045fc88000, task 88085fc53c30) > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack: > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] 88045fc89fd8 000119c0 88045fc88010 > 88085fc53ee8 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] 88045fc89fd8 88085fc53ee0 88085fc53c30 > 000119c0 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] 000119c0 8137f7ce 88007f80df40 > > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] Call Trace: > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] [] ? common_interrupt+0xe/0x13 > Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ > 685.246123] [] ? irqfd_inject+0x0/
Bug inkvm_set_irq
Hi, Each time i try tou use vhost_net, i'm facing a kernel bug. I do a "modprobe vhost_net", and start guest whith vhost=on. Following is a trace with a kernel 2.6.37, but i had the same problem with 2.6.36 (cf https://lkml.org/lkml/2010/11/30/29). The bug only occurs whith vhost_net charged, so i don't know if this is a bug in kvm module code or in the vhost_net code. Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243100] BUG: unable to handle kernel paging request at 2458 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243250] IP: [] kvm_set_irq+0x2a/0x130 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243378] PGD 45d363067 PUD 45e77a067 PMD 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243556] Oops: [#1] SMP Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243692] last sysfs file: /sys/devices/pci:00/:00:0d.0/:05:00.0/:06:00.0/irq Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243777] CPU 0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.243820] Modules linked in: vhost_net macvtap macvlan tun powernow_k8 mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand fre q_table cpufreq_conservative fuse xt_physdev ip6t_LOG ip6table_filter ip6_tables ipt_LOG xt_multiport xt_limit xt_tcpudp xt_state iptable_filter ip_tables x_tables nf_conntrack_tftp nf_conntrack_ftp nf_connt rack_ipv4 nf_defrag_ipv4 8021q bridge stp ext2 mbcache dm_round_robin dm_multipath nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 kvm_amd kvm ipv6 snd_pcm snd_timer snd soundcore snd_page_alloc tpm_tis tpm ps mouse dcdbas tpm_bios processor i2c_nforce2 shpchp pcspkr ghes serio_raw joydev evdev pci_hotplug i2c_core hed button thermal_sys xfs exportfs dm_mod sg sr_mod cdrom usbhid hid usb_storage ses sd_mod enclosu re megaraid_sas ohci_hcd lpfc scsi_transport_fc scsi_tgt bnx2 scsi_mod ehci_hcd [last unloaded: scsi_wait_scan] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Pid: 10, comm: kworker/0:1 Not tainted 2.6.37-dsiun-110105 #17 0K543T/PowerEdge M605 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RIP: 0010:[] [] kvm_set_irq+0x2a/0x130 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RSP: 0018:88045fc89d30 EFLAGS: 00010246 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RAX: RBX: 001a RCX: 0001 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RDX: RSI: RDI: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] RBP: R08: 0001 R09: 880856a91e48 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R10: R11: R12: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] R13: 0001 R14: R15: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] FS: 7f617986c710() GS:88007f80() knlGS: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CS: 0010 DS: ES: CR0: 8005003b Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] CR2: 2458 CR3: 00045d197000 CR4: 06f0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR0: DR1: DR2: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] DR3: DR6: 0ff0 DR7: 0400 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Process kworker/0:1 (pid: 10, threadinfo 88045fc88000, task 88085fc53c30) Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Stack: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] 88045fc89fd8 000119c0 88045fc88010 88085fc53ee8 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] 88045fc89fd8 88085fc53ee0 88085fc53c30 000119c0 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] 000119c0 8137f7ce 88007f80df40 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] Call Trace: Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] [] ? common_interrupt+0xe/0x13 Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] [] ? irqfd_inject+0x0/0x50 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] [] ? irqfd_inject+0x27/0x50 [kvm] Feb 23 13:56:19 ayrshire.u06.univ-nantes.prive kernel: [ 685.246123] [] ? irqfd_inject+0x0/0x50 [kvm] Feb 23 13:5
