lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 17 Mar 2011 10:21:59 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Jean-Philippe Menil <jean-philippe.menil@...v-nantes.fr>
Cc:	netdev@...r.kernel.org, kvm@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: 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@...shire:~# 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ