Re: [patch] epoll - send POLLHUP on ->release

[Gregory Haskins <ghaskins@novell.com>]

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

Andrew Morton wrote:
> On Wed, 03 Jun 2009 15:20:26 -0400
> Gregory Haskins <ghaskins@novell.com> wrote:
>
>   
>> Davide Libenzi wrote:
>>     
>>> The following patch allows waiters to be notified about the eventfd file* 
>>> going away, and give them a change to unregister from the wait queue.
>>> This is turn allows eventfd users to use the eventfd file* w/out 
>>> holding a live reference to it.
>>> After the eventfd user callbacks returns, any usage of the eventfd file* 
>>> should be dropped. The eventfd user callback can acquire sleepy locks 
>>> since it is invoked lockless.
>>>
>>>
>>>
>>> Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
>>>   
>>>       
>> Tested-by: Gregory Haskins <ghaskins@novell.com>
>>     
>
> Confused.  Did you test this with some new kernel patch, or with some
> existing kernel code?
>
>   
Hi Andrew,

Davide created this patch in response to a problem we were trying to
solve in kvm.git.  I took this patch in question, and combined it with a
proposed patch for KVM and tested it out.  You can find the thread here:

http://lkml.org/lkml/2009/6/2/276

I built a test harness and verified that calling close() on an eventfd
does indeed generate a POLLHUP wakeup, and that my code properly cleans
up when it gets the POLLHUP

Acceptance of my kvm optimization is predicated on Davide's patch going
in first, so I asked him to submit it formally.  I figured I should
chime in my findings in case it matters for upstream acceptance. 
(Apologies if this is not the normal/acceptable "tested-by"
protocol...tested-by tag noob here ;)


> If the latter, what code are we talking about here and what was the test
> case and what went wrong when using the current mainline
> implementation?
>
>   

Its not what went wrong per se.  Its more of a case of eliminating the
need for an awkward work-around I had to do when eventfd didn't provide
a release notification.  You can find the details in my patch 2/2
header, available here for your convenience:

http://lkml.org/lkml/2009/6/2/278

Regards,
-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]