Re: [KVM PATCH v5 3/4] KVM: Fix races in irqfd using new eventfd_kref_get interface

[Gregory Haskins <ghaskins@novell.com>]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]