linux-kernel - Re: [KVM PATCH 2/3] eventfd: add a notifier mechanism

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <49F0E7B4.90702@novell.com>
Date:	Thu, 23 Apr 2009 18:12:04 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	kvm@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	avi@...hat.com
Subject: Re: [KVM PATCH 2/3] eventfd: add a notifier mechanism

Davide Libenzi wrote:
> On Thu, 23 Apr 2009, Gregory Haskins wrote:
>
>   
>> Davide Libenzi wrote:
>>     
>>> On Thu, 23 Apr 2009, Gregory Haskins wrote:
>>>
>>>   
>>>       
>>>> This allows synchronous notifications to register with the eventfd
>>>> infrastructure.  Unlike traditional vfs based eventfd readers, notifiees
>>>> do not implictly clear the counter on reception.  However, the clearing
>>>> is primarily important to allowing threads to block waiting for events
>>>> anyway, so its an acceptable trade-off since blocking doesn't apply to
>>>> notifiers.
>>>>     
>>>>         
>>> Do you really need to add a notifier? Eventfd already has a wait queue, 
>>> and we support callback-based wakeups, so is there any reason we shouldn't 
>>> use those and rely on the already existing wakeups?
>>>   
>>>       
>> Well, IIUC the issue is that a wait queue implies that you are in fact
>> waiting...which we may not. :)
>>
>> The target in this particular application with kvm-irqfd is a vcpu
>> context, which *may* be sleeping in something like a HLT, but it also
>> could be in a number of other states such as non-root (guest) mode, it
>> could be running in the kernel, it could be up in userspace, etc.
>>
>> That said: I am not married to the concept that this has to be a
>> notifier callback, but I do want to be able to meet the target
>> application.  So if there is some way to do that within the existing
>> wait-queue contstruct, I am open to suggestions.
>>     
>
> Take a look at init_waitqueue_func_entry(), in particula at that "func" 
> parameter. Then look at how __wake_up_common() does its thing.
> You don't need to be "waiting" for our wakeup system to work. Callbacks 
> works just fine, otherwise things like epoll could not work at all.
>   

Yeah, I was looking at that this afternoon after you mentioned it.  That
makes sense.

As of right now the wqh is embedded in the eventfd, accessible only by
the .read() vtable entry.  In order to do this as you suggest, I imagine
I need to slightly modify the eventfd interface to allow waiters other
than the embedded readers to join the wait-queue.  How would you like to
see that interface look?

Thanks Davide,
-Greg




Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)