Michael S. Tsirkin wrote: > On Sun, Jun 28, 2009 at 08:53:22AM -0400, Gregory Haskins wrote: > >> Michael S. Tsirkin wrote: >> >>> On Thu, Jun 25, 2009 at 09:28:27AM -0400, Gregory Haskins wrote: >>> >>> >>>> eventfd currently emits a POLLHUP wakeup on f_ops->release() to generate a >>>> "release" callback. This lets eventfd clients know if the eventfd is about >>>> to go away and is very useful particularly for in-kernel clients. However, >>>> until recently it is not possible to use this feature of eventfd in a >>>> race-free way. This patch utilizes a new eventfd interface to rectify >>>> the problem. >>>> >>>> Note that one final race is known to exist: the slow-work thread may race >>>> with module removal. We are currently working with slow-work upstream >>>> to fix this issue as well. Since the code prior to this patch also >>>> races with module_put(), we are not making anything worse, but rather >>>> shifting the cause of the race. Once the slow-work code is patched we >>>> will be fixing the last remaining issue. >>>> >>>> >>> By the way, why are we using slow-work here? Wouldn't a regular >>> workqueue do just as well, with less code, and avoid the race? >>> >>> >>> >> I believe it will cause a problem if you do a "flush_work()" from inside >> a work-item. I could be wrong, of course, but it looks like a recipe to >> deadlock. >> >> -Greg >> >> > > Sure, but the idea is to only flush on kvm close, never from work item. > > The point of the flush on the eventfd side is to make sure we synchronize with outstanding injects before we free the irqfd. -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
