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

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]

Message-ID: <4A26D4CC.4040504@novell.com>
Date:	Wed, 03 Jun 2009 15:53:48 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	davidel@...ilserver.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] epoll - send POLLHUP on ->release

Andrew Morton wrote:
> On Wed, 03 Jun 2009 15:20:26 -0400
> Gregory Haskins <ghaskins@...ell.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@...ilserver.org>
>>>   
>>>       
>> Tested-by: Gregory Haskins <ghaskins@...ell.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

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